(57)【要約】【課題】高パフォーマンス及び低電力散逸のために最適化された処理要素を有するマルチプロセッサシステムと、関連する上記処理要素をプログラミングする方法との、様々な実施形態が開示される。【解決手段】各処理要素は、フェッチユニットと、複数のアドレス生成器ユニットと、複数のパイプライン化されたデータ経路とを備えてよい。フェッチユニットは、マルチパート命令を受信するよう構成されてよく、このマルチパート命令は複数のフィールドを含む。第１のアドレス生成器ユニットは、複数のフィールドのうちの第１のフィールドに応じた算術演算を実施するよう構成されてよい。第２のアドレス生成器ユニットは、複数のアドレスのうちの少なくとも１つのアドレスを生成するよう構成されてよく、各アドレスは、複数のフィールドそれぞれに依存する。並列アセンブリ言語を用いて、複数のアドレス生成器ユニット及び複数のパイプライン化されたデータ経路を制御してよい。【選択図】図２０
2019145172.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数の実行ユニット。
命令ストリームから第１および第２のマルチパート命令をフェッチするように構成されるフェッチユニットであって、前記第１および第２のマルチパート命令は、それぞれ複数のフィールドを含み、前記命令ストリームにおいて、前記第２のマルチパート命令は、前記第１のマルチパート命令の後に続く、フェッチユニット、
複数のアドレス生成ユニット、
を備えた装置であって、
前記複数のアドレス生成ユニットのうちの第１のアドレス生成ユニットは、
前記第１のマルチパート命令の第１のフィールドに基づいて、そこから第１のデータを取り出すアドレスを生成するように構成され、
前記第１のデータは、前記第１のマルチパート命令の第２のフィールドによって指定される動作のための、前記実行ユニットへの入力オペランドであり、
前記複数のアドレス生成ユニットのうちの第２のアドレス生成ユニットは、
前記第１のマルチパート命令の第３のフィールドに基づいて、そこから第２のデータを取り出すアドレスを生成するように構成され、
前記第２のデータは、前記第２のマルチパート命令のフィールドによって指定される動作のための、前記実行ユニットへの入力オペランドである、
装置。
【請求項２】
第３のマルチパート命令のために、前記第１のアドレス生成ユニットおよび前記第２のアドレス生成ユニットは、
前記第３のマルチパート命令のそれぞれのフィールドに基づいて、前記１つまたは複数の実行ユニットによって実行される１つまたは複数の動作の入力オペランドのデータを取り出すアドレスを生成するように構成され、
前記１つまたは複数の実行ユニットによって実行される１つまたは複数の動作は、前記第３のマルチパート命令の１つまたは複数のフィールドによって指定される
請求項１に記載の装置。
【請求項３】
第４のマルチパート命令のために、前記第１のアドレス生成ユニットおよび前記第２のアドレス生成ユニットは、
前記第４のマルチパート命令のそれぞれのフィールドに基づいて、前記１つまたは複数の実行ユニットによって実行される１つまたは複数の動作の入力オペランドのデータを取り出すアドレスを生成するように構成され、
前記１つまたは複数の実行ユニットによって実行される１つまたは複数の動作は、前記第４のマルチパート命令の１つまたは複数のフィールドによって指定される
請求項１に記載の装置。
【請求項４】
前記第１のデータおよび前記第２のデータは、異なる実行スレッドに対する入力オペランドである、
請求項１に記載の装置。
【請求項５】
前記第１のアドレス生成ユニットは、
第６のマルチパート命令に基づいて、算術演算を実行し、
算術演算の結果を、前記第６のマルチパート命令に続く命令のフィールドに基づいて、前記複数のアドレス生成ユニットのうちの１つによって実行されるアドレス生成動作への入力として使用するために、アドレスレジスタに格納するように構成される、
請求項１に記載の装置。 
【請求項６】
前記装置は、
前記１つまたは複数の実行ユニットのための入力オペランドを格納するように構成される複数のデータパスレジスタを備え、
前記装置は、
前記第２のマルチパート命令が、実行ユニットに到達するまで、前記複数のデータパスレジスタのうちの１つに、前記第２のデータを格納するように構成される
請求項１記載の装置。
【請求項７】
前記実行ユニットは、
前記複数のデータパスレジスタのうちの１つに格納するために結果オペランドを転送するように構成される、請求項６に記載の装置。
【請求項８】
前記１つまたは複数の実行ユニットは、
マルチパート命令の異なるフィールドに基づいて独立して動作を実行するように構成される複数の算術論理ユニットを備える、
請求項１に記載の装置。
【請求項９】
前記第１のアドレス生成ユニットは、
前記実行ユニットによって生成される結果オペランドを格納するアドレスを生成するように構成される、請求項１に記載の装置。
【請求項１０】
プロセッサのフェッチユニットによって、
命令ストリームから第１および第２のマルチパート命令をフェッチするステップであって、前記第１および第２のマルチパート命令は、それぞれ複数のフィールドを含み、前記命令ストリームにおいて、前記第２のマルチパート命令は、前記第１のマルチパート命令の後に続く、ステップと、
前記プロセッサの第１のアドレス生成ユニットによって、
前記第１のマルチパート命令の第１のフィールドに基づいて、そこから第１のデータを検索するためのアドレスを生成するステップであって、前記第１のデータは、前記第１のマルチパート命令の第２のフィールドによって指定される動作のための、前記プロセッサの実行ユニットへの入力オペランドである、ステップと、
プロセッサの第２のアドレス生成ユニットによって、
第１のマルチパート命令の第３のフィールドに基づいて、そこから第２のデータを検索するためのアドレスを生成するステップであって、前記第２のデータは、第２のマルチパート命令のフィールドによって指定される動作のための、前記実行ユニットへの入力オペランドである、ステップと
を含む方法。
【請求項１１】
前記第１のデータおよび前記第２のデータは、異なる実行スレッドのための入力オペランドである、請求項１０に記載の方法。
【請求項１２】
第３のマルチパート命令に基づいて、前記第１のアドレス生成ユニットによって、算術演算を実行すること、
算術演算の結果を、前記第３のマルチパート命令に続く命令のフィールドに基づいて、前記プロセッサのアドレス生成ユニットによって実行されるアドレス生成動作への入力として使用するために、アドレスレジスタに格納すること
をさらに含む請求項１０に記載の方法。
【請求項１３】
前記第２のマルチパート命令が前記実行ユニットに到達するまで、前記実行ユニットの特定の入力のオペランドを提供する、前記プロセッサの複数のデータパスレジスタのうちの１つに、前記第２のデータを格納すること、
をさらに含む請求項１０に記載の方法。
【請求項１４】
前記実行ユニットによって、前記複数のデータパスレジスタのうちの１つに格納するための結果オペランドを転送すること、
をさらに含む請求項１３に記載の方法。
【請求項１５】
前記プロセッサの２つ以上の実行ユニットによって、マルチパート命令の異なるフィールドに基づいて、第１および第２のそれぞれの数学演算を独立して実行すること
をさらに含む請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はマルチプロセッサシステムに関し、より詳細には、プロセッサ動作及び実行の
改善、並びにこのようなシステムを標的にしたソフトウェアの開発に関する。
【背景技術】
【０００２】
一般的なハードウェアシステムの主たる目的は、完全なプログラム可能性を保持したま
ま、特定用途向け（非プログラマブル）ハードウェアパフォーマンスを達成することであ
る。従来、これら２つの概念は対極にある。特定用途向けハードウェアは、可能な限り最
も効率のよい方法で特定の機能を実施する、固定型ハードウェアソリューションである。
これは通常、機能あたりのエネルギ又は１つ若しくは複数の演算あたりのエネルギに関し
て、及び製品の部分コストに関連し得る（回路）面積あたりの機能に関して、測定される
。コスト及び市場ダイナミクスにより、この目的を満たそうという試みのための革新が推
進されてきた。チップ製品のコストは、ダイ面積及び最終パッケージを含む多くの因子で
構成される。コストはまた、製品を開発するための全体的なエコシステムも考慮しなけれ
ばならない。このエコシステムのコストは、特定の用途を特定のハードウェアソリューシ
ョンに還元するための時間、システム全体を構成するために必要な特定のハードウェアソ
リューションの個数、並びにカスタマイズされた通信及びメモリ構造によって全ての特定
のハードウェアソリューションを集積するためにかかる時間で構成される。従って、多数
の特定ハードウェアソリューションの全てをそのカスタム相互接続によってサポートする
ために、完全に集積されたソリューションが必要となり、これにより単一チップダイに関
して極めて大きな面積が必要となる。従来このプロセスは、面積、エネルギ及び市場に出
るまでの時間に関して効率的でないソリューションの原因となっていた。
【０００３】
プログラム可能性の世界及び標的のハードウェアの概念を考慮すると、ハードウェアア
ーキテクチャ及びソフトウェア開発スタイルの視点からの市場又は展望は：Ｉｎｔｅｌ、
ＡＭＤ（Ｉｎｔｅｌ又はＡｒｍ命令セットベース）、ＡＲＭ等の企業が提供する汎用プロ
セッサ（ＧＰＰ）；ｎＶｉｄｉａ及びＡＭＤ（以前はＡＴＩであり、２００６年にＡＭＤ
により買収）等からのグラフィカルプロセッシングユニット（ＧＰＵ）；ＴＩ及びＡｎａ
ｌｏｇＤｅｖｉｃｅｓからのデジタル信号プロセッサ（ＤＳＰ）；Ｘｉｌｉｎｘ、Ａｌｔ
ｅｒａ等からのフィールドプログラマブルゲートアレイ（ＦＰＧＡ）；Ｃａｖｉｕｍ及び
Ｔｉｌｅｒａからのマルチコア／メニーコアプロセッサ；特定用途向け集積回路（ＡＳＩ
ＣＳ）又はシステムオンチップ（ＳｏＣ）によって提示される。
【０００４】
汎用プロセッサ（ＧＰＰ）
ＧＰＰは、４０年以上に亘って考えられてきた、極めて古いものの検証はされているハ
ードウェアアーキテクチャに基づく、汎用処理のためのものであり、即ち「何でも屋（ａ
ｊａｃｋ  ｏｆ  ａｌｌ  ｔｒａｄｅｓ）」になろうとしている。ＧＰＰの主要な目的
は、ユーザインタフェース（ＵＩ）と、ＭＳＷｏｒｄ、Ｅｘｃｅｌ、ｅメール等の、高度
にインタラクティブなＵＩ集約型アプリケーションとを、これらをサポートするオペレー
ティングシステム（例えばＷｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標））によ
って駆動することである。電力散逸に大きな影響を及ぼすハードウェア特性は、マルチレ
ベルキャッシュ、複雑なハードウェアメモリ管理ユニット、大型のバス、大型のクロック
生成構造である。要するにこれらは、そのタスクを実施するために多くの電力を散逸する
。ソフトウェア開発の視点から、これは、標的とするのが最も簡単なソフトウェアプログ
ラミングモデルであると考えられる。これは、ユーザが、連続して又は順次実行される単
一のスレッドを開発しているという視点からのものである。並列処理又は複数ハードウェ
アスレッド（約４スレッド超）を導入する場合、これらを効率的にプログラムする能力は
大幅に困難となる。これは、このアーキテクチャが根本的に並列スレッド演算をサポート
するように開発されておらず、従ってハードウェアアーキテクチャは途方も無い量のオー
バヘッド及び複雑さを管理する必要があるという事実による。ソフトウェアプログラミン
グモデルは、複数ソフトウェアスレッドの定義をサポートするためにＡＰＩ又は言語拡張
の導入を必要とする。これは必ずしも複雑でないものの、残念ながら現行のＧＰＰハード
ウェアアーキテクチャはこのような複雑さを必要とする。
【０００５】
高次において、世界中の全てのスーパコンピュータでＣ、Ｃ＋＋、Ｆｏｒｔｒａｎ等を
用いて長年に亘って広く使用されてきたＡＰＩは、ＭＰＩ（メッセージ受け渡しインタフ
ェース）ＡＰＩであり、これは１９９０年代初頭から業界標準である。これは極めて単純
な、よく理解されている、ハードウェア実装経路を制限しないＡＰＩである。ＭＰＩ  Ａ
ＰＩは、ハードウェア非依存性様式での、ソフトウェアスレッド及び通信の定義を可能と
する。これはＯｐｅｎＭＰ、ＣｏａｒｒａｙＦｏｒｔｒａｎ、ＯｐｅｎＣＬ等、及び仮定
された下層のハードウェアモデルを本来的に記述する他の言語／ＡＰＩとは異なっており
、従って解釈の柔軟性を制限し、前方互換性の問題を引き起こす。換言すると、これらの
言語／ＡＰＩを用いる場合、プログラマは、標的とする全ての新規のハードウェアプラッ
トフォームのためにプログラムを書き直す必要がある。
【０００６】
グラフィカルプロセッシングユニット（ＧＰＵ）
ＧＰＵは従来、データを処理して表示することを標的として開発されてきた。これらは
、そのコア外（外部）メモリモデル要件及び内部コアメモリモデル要件により、ハードウ
ェアアーキテクチャ的に制約されている。コア外メモリは、ＧＰＰに、データをＧＰＵメ
モリ空間に配置するよう要求する。続いてＧＰＵはそのデータを引き込み、そのデータに
対してパイプライン様式で動作して、上記データを外部メモリ空間に戻す。ここからデー
タをディスプレイに送信でき、又はＧＰＰは、汎用処理下での動作において更に使用／記
憶するために、データをＧＰＵメモリ空間外に移動させる必要がある。ハードウェアの非
効率性は、（１）コア外ハードウェア制約をサポートするためにデータを移動させるため
に必要なサポート、及び（２）深いパイプライン構造のＳＩＭＤ機械と同様の、能率化さ
れたパイプラインにおいて処理されるよう、データが制約を受ける、内部コアメモリ構造
によるものである。その結果、データを処理するためのハードウェアの非効率性により、
電力が高くなる。使用されるソフトウェアプログラミングモデルは、極めてハードウェア
中心的なものであり、ＯｐｅｎＣＬ、ＣＵＤＡ等であり、従って、効率性を達成するには
複雑であり、移植可能性があまり高くなく、新規のハードウェア標的プラットフォームに
移動させようとする際には、コードを書き直して再構成しなければならない。
【０００７】
デジタル信号プロセッサ（ＤＳＰ）
ＤＳＰは、一般的な信号処理のために削減及び標的化された命令セットを有するＧＰＰ
として考えることができる。これらは、その兄弟／姉妹ＧＰＰと同一のキャッシュ、ＭＭ
Ｕ及びバスからの悪影響を受ける。Ｖｉｔｅｒｂｉ／Ｔｕｒｂｏ復号化又は動作推定等の
、いずれの実際に高スループットの処理機能は、通常は市場における特定の規格の限定的
なセットをサポートするだけの、限定された能力を有するＡＳＩＣ加速器へと削減されて
いる。プログラミングモデルは、単一のハードウェアスレッドを標的とする場合のＧＰＰ
と同様であるが、実行ユニットハードウェアにおける信号処理命令アプローチにより、い
ずれの高効率を達成するには、複数の機能のハンドアセンブリ、又はＤＳＰ製造企業のラ
イブラリの使用を必要とする。上述の並列ＧＰＰと同様に、多数の並列ＤＳＰアーキテク
チャを生成する際、問題は更に悪化する。
【０００８】
フィールドプログラマブルゲートアレイ（ＦＰＧＡ）
ＦＰＧＡは完全に異なるハードウェアアプローチであり、この場合機能性の定義はビッ
トレベルで実施でき、論理機能間の通信はプログラム可能な配線構造を通して実施される
。このハードウェアアプローチは、途方も無い量のオーバヘッド及び複雑さを導入する。
これにより、効率的なプログラミングが、Ｖｅｒｉｌｏｇ又はＶＨＤＬ等のハードウェア
プログラミング言語で実施される。コンパイルプロセスは、ＡＳＩＣ／ＳＯＣにおいて必
要とされるものと同様であるものの、構造化された配線ファブリックを有する、プログラ
ム可能な配線及びプログラム可能な論理導入タイミング収束障害により、遥かに複雑とな
る。ＦＰＧＡはそのＦＰＧＡがプログラムされた目的の機能そのもののみを実施し、それ
以外を一切実施しないため、１度に１つの機能のみを比較する場合、特定の機能に関する
電力散逸及びパフォーマンススループットは、ＧＰＰ又はＧＰＵより明らかに遥かに良好
である。しかしながら、ＧＰＰの能力の全てをＦＰＧＡに実装しようとした場合、ＧＰＰ
よりも明らかに悪くなる。ハードウェアレベルにおけるプログラミングの困難さは明らか
である（例えばタイミング収束）。ＦＰＧＡのプログラミングは実際には「プログラミン
グ」ではなく、論理／ハードウェア設計であり、またＶＨＤＬ／Ｖｅｒｉｌｏｇはプログ
ラミング言語ではなく、論理／ハードウェア設計言語である。
【０００９】
マルチコア／メニーコア
殆ど全てのマルチコア／メニーコアアーキテクチャは、ハードウェアの視点から、コア
プロセッサ、キャッシュ、ＭＭＵ、バス、全ての関連する論理を採用し、これらを、その
周囲の通信バス／ファブリックによってダイ上で複製している。マルチコアアーキテクチ
ャの例はＩＢＭのＣｅｌｌ、Ｉｎｔｅｌ及びＡＭＤのクアッドコア及びＮマルチコア、Ｃ
ａｖｉｕｍ及びＴｉｌｅｒａの製品、多数のカスタムＳｏＣ等である。更に、マルチコア
アーキテクチャにおいて達成される電力の低減は主に取るに足らないものである。この明
らかな結果は、マルチコアアプローチがＧＰＵアプローチを単に複製するという事実に由
来する。マルチコアアーキテクチャにおける唯一の実際の電力節約は、以前は別個のダイ
上にあったコアが追加の通信バスに接続されることにより、もはや不要となったＩＯドラ
イバの削減である。従って、マルチコアアプローチは電力のいずれの低下につながらない
。第２に、ソフトウェアプログラミングモデルは上述のＧＰＰから改善されない。
【００１０】
特定用途向け集積回路（ＡＳＩＣ）又はシステムオンチップ（ＳｏＣ）
他のアプローチに関して識別される事項のリストは、特定の市場に関して、パフォーマ
ンス効率及びコスト目標を達成するための唯一の方法が、特定のＧＰＰ、ＤＳＰ及びＡＳ
ＩＣ加速器を有するカスタムチップを開発してＳｏＣを形成することであると考えられる
ことが多い理由である。ＳｏＣは、必要な場合はプログラム可能性と、電力散逸とコスト
との間のバランスを取るための特定の機能に関するＡＳＩＣ性能とを提供する。しかしな
がら現在、ソフトウェアプログラミングモデルは、上述のプログラム可能なハードウェア
ソリューションのもとで議論されたものよりも更に複雑である。更にＳｏＣは、完全にプ
ログラム可能なソリューションと関連する柔軟性の損失につながり得る。
【００１１】
これらのプログラム可能なハードウェアソリューション全てに共通なのは、現在市場に
おいて提示されているソフトウェアプログラミングモデルが、その標的化をより効率的に
サポートするために、実行モデル及び下層のハードウェアアーキテクチャを外挿すること
に焦点を合わせている点である。実行モデルの特徴をソフトウェアプログラミングモデル
に外挿することは、より一般的な並列プログラミング言語のうちのいくつかの重要な特徴
を見ると観察できる。現在使用されているアプローチを示すいくつかの例は、ＯｐｅｎＭ
Ｐ、ＯｐｅｎＣＬ、ＭＰＩである。
【００１２】
ＯｐｅｎＭＰ
ＯｐｅｎＭＰ（オープンマルチプロセッシング）は、共有メモリマルチプロセッシング
プログラミングをサポートする業界標準のＡＰＩである。ＯｐｅｎＭＰは、コンパイラ指
示文、ライブラリルーチン、及びランタイム挙動に影響を与える環境変数のセットを含む
。これは、並列化方法によるマルチスレッディングをサポートし、これによって親スレッ
ド（連続して実行される一連の命令）は特定の数のスレーブスレッドに分岐し、タスクが
これらの間で分割される。そしてこれらのスレッドは同時に実行され、ランタイム環境は
スレッドを、利用法、機械負荷及び他の因子に応じて異なるリソース又はプロセッサに割
り当てる。スレッドの数は、ランタイム環境によって、環境変数に基づいて、又は関数を
使用するコード内に割り当てることができる。従って、並列に実行されることが意図され
たコードのセクションは、このセクションの実行前にスレッドを形成させるプリプロセッ
サ指示文によってマークされる。Ｃ／Ｃ＋＋では、これは＃ｐｒｏｇｒａｍｓの使用によ
る。デフォルトでは、各スレッドはコードの並列化されたセクションを独立して実行する
。タスクの並列処理及びデータの並列処理の両方を達成できる。並列化されたコードの実
行後、複数のスレッドは親スレッドへ連結され、これはプログラムの最後まで進み続ける
。図１は、ＯｐｅｎＭＰを利用したマルチスレッディングを示しており、ここで親スレッ
ドは、コードの複数のブロックを並列に実行する多数のスレッドに分岐する。スレッド間
通信をサポートするために、ＯｐｅｎＭＰの拡張、又は別の異なる業界標準ＡＰＩ（例え
ばＭＰＩ（メッセージ受け渡しインタフェース））を使用してよい。
【００１３】
ＯｐｅｎＣＬ
オープン計算言語（ＯｐｅｎＣＬ）は、中央演算処理装置（ＣＰＵ）グラフィカルプロ
セッシングユニット（ＧＰＵ）、デジタル信号プロセッサ（ＤＳＰ）、フィールドプログ
ラマブルゲートアレイ（ＦＰＧＡ）及び他のプロセッサを備える異質な複数のプラットフ
ォームに亘る実行を可能とすることを目的として、プログラムを記述するためのフレーム
ワークである。これは抽象化が限定されたクロース・トゥ・ハードウェアインタフェース
をサポートするよう設計されている。このため、ＯｐｅｎＣＬベースのプログラムは一般
に、満足できるパフォーマンスを達成するために、下層のハードウェアに関する高度な知
識を必要とする。ＯｐｅｎＣＬプログラムはまた、異なるハードウェアアーキテクチャを
再標的化する際にリファクタリングを必要とする。図２に示すように、ＯｐｅｎＣＬは、
厳密な処理モデル、制御モデル、メモリモデル、通信モデル階層をサポートする。
【００１４】
ＯｐｅｎＣＬは、何らかの制限及び追加を伴って、ＡＮＳＩ  Ｃプログラミング言語を
用いてカーネルを記述することをサポートする。これは、関数へのポインタ、再帰、ビッ
トフィールド、可変長配列、標準ヘッダファイルの使用を可能としない。複数のベクタタ
イプ及び演算を伴う並列処理、同期化、並びに複数のワークアイテム／グループを伴う作
業を行うための関数をサポートするよう、上記言語を拡張する。アプリケーションプログ
ラミングインタフェース（ＡＰＩ）を用いて、プラットフォームを定義して制御する。Ｏ
ｐｅｎＣＬは、コースレベルにおいて、タスクベース及びデータベースの並列処理を用い
た並列計算をサポートする。
【００１５】
ＭＰＩ
メッセージ受け渡しインタフェース（ＭＰＩ）は、標準化された、言語非依存の、スケ
ーラブルな、移植可能な、メッセージ受け渡し通信プロトコルＡＰＩである。ＭＰＩ  Ａ
ＰＩは、言語特異性構文を用いて、言語非依存性の方法で、（ノード／サーバ／コンピュ
ータインスタンスに対してマッピングされた）プロセスのセット間の、必須の仮想トポロ
ジ、同期化、及び通信機能を提供する（バインディング）。ＭＰＩ  ＡＰＩ規格は、様々
な挙動を定義できるポイントツーポイント及び集合／同報通信送受信動作並びにプロセス
の同期のためのサポートを含む、ライブラリルーチンのコアの構文及び意味規則を定義す
る。ＭＰＩは今日のハイパフォーマンス計算において使用される主要なモデルであり続け
ている。
【００１６】
ＭＰＩ  ＡＰＩは、最もハードウェア非依存性のアプローチであり、従って提示された
例の基礎として使用される。
【００１７】
マルチプロセッサシステム上での並列実行のためのソフトウェアアプリケーションの開
発の、従来技術によるアプローチは、一般に、開発の容易さと並列実行の効率性との間の
トレードオフを必要とする。換言すると、一般に、プログラマにとって開発プロセスが容
易であればあるほど、結果として得られる実行可能なプログラムをハードウェア上で同時
に実行する効率が低くなり、また反対に、より効率的な並列実行は一般に、プログラマに
よる相当に多大な努力を必要とし、即ち非効率的な処理を回避するために、及び標的ハー
ドウェアの、効率増進性特徴を使用するために、プログラムを更に詳細に設計する必要が
ある。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
従って、ソフトウェアプログラミングモデルを駆動するためのアプリケーションのソフ
トウェア記述又はシステムレベルビューと、実行モデル及び下層ハードウェアアーキテク
チャを標的化するためのこれらの後の使用とを促進するための、改善されたシステム及び
方法が望まれている。また、このプロセスを通してアプリケーションの効率的かつプログ
ラム可能な実装を可能とする機構を提供する改善も望まれている。
【課題を解決するための手段】
【００１９】
高パフォーマンス及び低電力散逸のために最適化された処理要素を有するマルチプロセ
ッサシステムと、関連する上記処理要素をプログラミングする方法との、様々な実施形態
が開示される。
【００２０】
第１の実施形態は、フェッチユニット及び複数のアドレス生成器ユニットを備えるプロ
セッサ装置に関する。フェッチユニットはマルチパート命令を受信するよう構成され、マ
ルチパート命令は複数のフィールドを含む。第１のアドレス生成器ユニットは、複数のフ
ィールドのうちの第１のフィールドに応じた算術演算を実施するよう構成される。第２の
アドレス生成器ユニットは、複数のアドレスのうち少なくとも１つのアドレスを生成する
よう構成され、各アドレスは、複数のフィールドそれぞれに依存する。
【００２１】
多数のデータ経路を制御することに関する第２の実施形態は、フェッチユニット及び実
行ユニットを備えるプロセッサ装置を伴う。フェッチユニットはマルチパート命令を受信
するよう構成され、マルチパート命令は複数のフィールドを含む。実行ユニットは複数の
パイプラインユニットを含み、実行ユニットは：１）複数のフィールドのうちの第１のフ
ィールドに応じて、複数のパイプラインユニットのうちの所定のパイプラインユニットを
用いて第１の演算を実施するよう；及び２）複数のフィールドのうちの第２のフィールド
に応じて、複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニット
を並列に用いて第２の演算を実施するよう、構成される。
【００２２】
累算の転送に関する第３の実施形態は、フェッチユニット及び実行ユニットを備えるプ
ロセッサ装置を伴う。フェッチユニットは命令を受信するよう構成される。実行ユニット
は複数のパイプラインユニットを含み、上記複数のパイプラインユニットの各パイプライ
ンユニットはアキュムレータユニットを含み、実行ユニットは：１）受信した命令に応じ
て、複数のパイプラインユニットのうちの第１のパイプラインユニットを用いて第１の演
算を実施して、ある結果を生成するよう；２）複数のパイプラインユニットのうちの第１
のパイプラインユニットのアキュムレータユニットに上記結果を保存するよう；及び３）
複数のパイプラインユニットのうちの第１のパイプラインユニットのアキュムレータユニ
ットに保存された結果を、プロセッサのアキュムレータユニットに転送するよう、構成さ
れる。
【００２３】
アドレス生成器ユニットの連結に関する第４の実施形態は、フェッチユニット及び複数
のアドレス生成器ユニットを備えるプロセッサ装置を伴う。フェッチユニットはマルチパ
ート命令を受信するよう構成され、マルチパート命令は複数のフィールドを含む。第１の
アドレス生成器ユニットは、複数のフィールドのうちの第１のフィールドに応じて第１の
演算を実施して、第１の結果を生成するよう構成される。第２のアドレス生成器ユニット
は、複数のフィールドのうちの第２のフィールド及び上記第１の結果に応じて第２の演算
を実施するよう構成される。
【００２４】
第５の実施形態は、単一パート／マルチパート決定を伴う命令を受信できるプロセッサ
装置に関する。プロセッサ装置は、命令を受信するよう構成されたフェッチユニットと、
実行ユニットとを備えてよい。実行ユニットは、複数のパイプラインユニットを備えてよ
い。実行ユニットは：１）命令がマルチパート命令であることの決定に応答して、複数の
パイプラインユニットのうちの第１のパイプラインユニットを用いて第１の演算を実施す
るよう（ここでマルチパート命令は複数のフィールドを含み、第１の演算は複数のフィー
ルドのうちの第１のフィールドに依存する）；及び２）複数のフィールドのうちの第２の
フィールドに応じて、複数のパイプラインユニットのうちの少なくとも２つのパイプライ
ンユニットを並列に用いて第２の演算を実施するよう、構成してよい。
【００２５】
第６の実施形態は、反復ループ中にプロセッサの未使用部分をパワーダウンさせること
ができる、プロセッサ装置に関する。このプロセッサ装置は、フェッチユニット及び実行
ユニットを備えてよい。フェッチユニットは、複数の命令を受信して、受信した複数の命
令に基づいて少なくとも１つの反復命令シーケンスを識別するよう構成される。上記少な
くとも１つの反復命令シーケンスは、複数の命令のうちの少なくとも１つを含む。実行ユ
ニットは複数のパイプラインユニットを含み、実行ユニットは：１）識別された反復命令
シーケンスに基づく少なくとも第１のサイクルに関する、複数のパイプラインユニットの
第１のサブセットを選択的に無効化するよう；及び２）識別された反復命令シーケンスに
応じた第２のサイクルに関する、複数のパイプラインユニットの第２のサブセットを選択
的に無効化するよう、構成される。
【００２６】
マルチプロセッサシステム上での並列実行のために標的化されたソフトウェアを開発す
るための方法の実施形態を提示する。
【００２７】
例えばマルチプロセッサシステム上での展開及び実行のために標的化されたアプリケー
ションの、所望のシステムの複数のビューを指定する入力を受信してよい。各ビューは、
システムの各態様を提示又は指定してよく、またこれらビューは総体として、効率的な並
列実行のためにマルチプロセッサシステムが展開できる実行可能なプログラムを生成する
ためにコンパイラ（又は他のソフトウェアツール）が使用できる情報を提供してよい。
【００２８】
この入力は、様々な形態のいずれで、また様々なツールのいずれを介して受信されてよ
い。例えばいくつかの実施形態では、入力はユーザによって提供されてよく、即ちユーザ
入力であってよい。他の実施形態では、入力は所望に応じて別のシステム又はプロセス、
ストレージ媒体等から受信されてよい。更に入力はローカルに提供されてよく、又はロー
カルエリアネットワーク（ＬＡＮ）若しくはインターネット等の広域ネットワーク（ＷＡ
Ｎ）を介して受信されてよい。例示的な一実施形態では、ユーザはスプレッドシート中で
ビューを指定してよい。別の例示的実施形態では、ユーザはウィザード、即ちグラフィカ
ルユーザインタフェース（ＧＵＩ）への入力を行ってよく、これは指定プロセスを通して
、例えばプロンプト、有用な提案等によってユーザをリードする。更なる実施形態では、
ユーザは入力／指定プロセスを管理するためにチェックリストを使用してよく、指定され
る各アイテム、例えばビュー、サブビュー等がチェックリストに挙げられており、チェッ
クリストは各チェックリストアイテムが指定されているか（されていないか）を示す。別
の例示的実施形態では、１つ又は複数のテンプレート又はフォームを提供してよく、ユー
ザはビューを指定する情報で上記テンプレート又はフォームを埋めてよい。
【００２９】
各ビューは、アプリケーションの動作又は実行の各態様を含むか又はその表現となって
よい。多数のビューはメモリビュー、通信ビュー、制御ビュー、処理ビューを含んでよい
。他のビューも所望に応じて定義又は指定してよい。一実施形態では、各ビューは、ビュ
ーの更に詳細な属性を指定する複数のサブビュー（又は「ファセット（ｆａｃｅｔ）」）
を含むか又は指定してよい。例えば各ビューは、サイズ、挙動及びアクセシビリティサブ
ビュー（又はファセット）を含んでよく、各サブビューは、各サブビューがその一部とな
っているビューに関連する特定の意味を有してよい。
【００３０】
従って例えば、メモリビューは：アプリケーションによる使用に必要な又は利用可能な
メモリのサイズ（又は量）、即ちデータを処理するためにアプリケーションが使用するメ
モリ構造サイズ；メモリの挙動、即ちメモリ構造が所定のタイミングで挙動する様式；並
びにメモリのアクセシビリティ、即ち例えばアプリケーション及び／又はシステムによる
メモリ構造のアクセシビリティを指定してよい。
【００３１】
同様に、入力は：通信ビュー（通信ビューの各サブビュー、例えば通信サイズ、挙動、
アクセシビリティを定義することを含む）；制御ビュー（制御サイズ、挙動、アクセシビ
リティを含む）；並びに処理ビュー（処理サイズ、挙動、アクセシビリティを含む）を定
義又は指定してよい。
【００３２】
いくつかの実施形態では、ビュー又はサブビューのうちのいくつかは、他のサブビュー
又はビューの指定によって、例えば同一の又は異なるビューのサブビューによって、自動
的に定義又は指定され得ることに留意されたい。従って例えば、メモリサイズ、挙動及び
アクセシビリティが指定されると、通信挙動が自動的に指定され得る。別の様式で考える
と、いくつかの実施形態では、ビューは、方程式の数が変数の数を超える線形方程式の優
決定系と同様に、「過剰に指定される」か又は「過剰に決定される」場合がある。
【００３３】
本出願で使用される特定の用語又は標識は単なる例示であること、並びに所望に応じて
本出願で開示される新規の構成要素、情報及びプロセスに対していずれの名称を使用して
よいことに留意されたい。例えば所望に応じて、ビュー又は態様はモデル等と呼ばれる場
合もあり、本出願で開示されるサブビューはサブモデル、ファセット、プロパティ等と呼
ばれる場合もある。
【００３４】
システムのビューが指定又は定義されると、これらのビューを表す情報は、アプリケー
ションのソースコード内に含まれ得る。この包含は、広範な方法のうちのいずれにおいて
実施され得る。例えばいくつかの実施形態では、情報はアプリケーションの１つ又は複数
のヘッダファイルに含まれ得る。他の実施形態では、情報は、アプリケーションプログラ
ム要素又は構成要素の中でとりわけ、１つ又は複数の動的リンクライブラリ（ＤＬＬ）又
はマクロ定義に含まれ得る。より一般には、ビューを表す情報は、所望に応じていずれの
様式及びいずれの形態でアプリケーションソースコードに組み込まれてよい。
【００３５】
ソースコードは例えば、コンパイラ又は他のツールによって処理でき、これはシステム
に関して指定又は定義された複数のビューを表す情報を分析することを含む。例えば一実
施形態では、コンパイラは、アプリケーションソースコード内の複数のビューを表す情報
を認識するよう構成してよく、またこの情報を抽出及び分析してよい。他の実施形態では
、コンパイラは情報を原位置で分析してよい。
【００３６】
実行可能なプログラムは上記処理に基づいて生成してよく、ここで上記実行可能なプロ
グラムは、効率的な並列実行のためにマルチプロセッサシステムに展開可能である。換言
すると、コンパイラは、指定されたビューの分析を含む上記処理に基づいて、実行可能な
プログラムを生成してよい。
【００３７】
従って、本技術の実施形態は、上述のようなソフトウェア開発への従来技術のアプロー
チの様々な欠点に対処でき、これによってユーザは、システムの動作、例えばマルチプロ
セッサシステム上でのアプリケーションの動作に関する様々な要件又は制約を指定でき、
これら指定された要件又は制約をコンパイラ（又は他のツール）が使用して、システム上
で効率的に実行できる実行可能なコードを生成してよい。
【図面の簡単な説明】
【００３８】
【図１】図１は、ＯｐｅｎＭＰを利用したマルチスレッディングを示し、親スレッドはコードのブロックを並列に実行する多数のスレッドに分岐する。
【図２】図２は、ＯｐｅｎＣＬの厳密処理モデル、制御モデル、メモリモデル、通信モデル階層を示す。
【図３】図３は、マルチプロセッサシステム（ＭＰＳ）の一実施形態を示すブロック図である。
【図４】図４は、ＭＰＳ接続スキームの一実施形態を示すブロック図である。
【図５】図５は、ＭＰＳファブリックの一実施形態を示す更に詳細な図である。
【図６】図６は、図５のアーキテクチャ例に従ってＤＭＲ（円）と共に均一に分散させたＰＥ（正方形）からなる、例示的なＭＰＳを示す。
【図７】図７は、動的に構成可能なプロセッサ（ＰＥ）の一実施形態を示すブロック図である。
【図８】図８は、一実施形態による、マルチプロセッサシステム上での並列実行のために標的化されたアプリケーションソフトウェアを開発するための方法のフローチャートである。
【図９Ａ】図９Ａは、一般的な２Ｄフィルタリング組織スキームを示す。
【図９Ｂ】図９Ｂは、別の一般的な２Ｄフィルタリング組織スキームを示す。
【図１０】図１０は、単一のプロセッサによる画像フィルタリングのブロック図を示す。
【図１１】図１１は、多数のプロセッサによる画像フィルタリングのブロック図を示す。
【図１２】図１２は、例示的なビデオ２Ｄフィルタシステムのための、ＭＰＳ上での２つの異なるリソースレイアウトを示す。
【図１３】図１３は、単一のプロセッサを用いたＦＩＲフィルタを示すブロック図である。
【図１４】図１４は、多数のプロセッサを用いたＦＩＲフィルタを示すブロック図である。
【図１５】図１５は、サンプルバッファに関するメモリ構造を示す。
【図１６】図１６は、メモリ通信挙動に関する経時的構造を示す。
【図１７】図１７は、ＦＩＲフィルタの一部に関する、メモリ通信挙動に関する経時的構造を示す。
【図１８】図１８は、９ステージＰＥパイプラインの一実施形態のパイプラインステージを示す。
【図１９】図１９は、単一ＰＥデータ経路アーキテクチャ及び改善されたＰＥデータ経路アーキテクチャの実施形態のブロック図を示す。
【図２０】図２０は、データ経路の一実施形態を示すブロック図である。
【図２１】図２１は、アキュムレータ転送を実施する２つのＰＥの一実施形態を示すブロック図である。
【図２２】図２２は、ＰＥのアドレス生成論理の一実施形態を示すブロック図である。
【図２３】図２３は、アドレス生成ユニット（ＡＧＵ）の一実施形態を示すブロック図である。
【図２４】図２４は、循環バッファの一実施形態の概念図である。
【図２５】図２５は、図２４の循環バッファの制御の一実施形態を示すブロック図である。
【図２６】図２６は、従来のプログラミングモデル及びＨｙｐｅｒＯｐプログラミングモデルを示す２つのブロック図を示す。
【図２７】図２７は、ＨｙｐｅｒＯｐ命令の一実施形態を示す。
【図２８】図２８は、命令フェッチ及び復号化ユニットの一実施形態を示すブロック図である。
【図２９】図２９は、マルチパート命令を受信及び実行する第１の実施形態を示すフローチャートである。
【図３０】図３０は、マルチパート命令を受信及び実行する第１の実施形態を示すフローチャートである。
【図３１】図３１は、プロセッサによる演算の実施の一実施形態を示すフローチャートである。
【図３２】図３２は、プロセッサによる演算の実施の一実施形態を示すフローチャートである。
【図３３】図３３は、プロセッサを動作させる一実施形態を示すフローチャートである。
【図３４】図３４は、複数のパイプラインユニットを有するプロセッサを動作させる第１の実施形態を示すフローチャートである。
【発明を実施するための形態】
【００３９】
本開示は様々な修正及び代替形態を許容するものであるが、その具体的な実施形態を例
として図面に示し、また本明細書で詳細に説明する。しかしながら、上記具体的実施形態
の図及び詳細な説明は、図示されている特定の形態に開示を限定することを意図したもの
ではなく、反対に、添付の請求項によって定義されるような本開示の精神及び範囲内にあ
る全ての修正例、均等物及び代替例を包含することを意図したものであることを理解され
たい。本明細書において使用されている見出しは、単に組織化を目的としたものであり、
これらの使用は本説明の範囲の限定を意味しない。本出願全体を通して使用される単語「
してよい／し得る／できる（ｍａｙ）」は、許容の意味で（即ち「可能性がある」ことを
意味して）使用されており、強制の意味で（即ち「しなければならない」ことを意味して
）使用されるものではない。同様に、単語「含む（ｉｎｃｌｕｄｅ／ｉｎｃｌｕｄｉｎｇ
／ｉｎｃｌｕｄｅｓ）」は、ある対象を含むもののそれに限定されないことを意味する。
【００４０】
様々なユニット、回路又はその他の構成部品は、１つ又は複数のタスクを実施する「よ
う構成される（ｃｏｎｆｉｇｕｒｅｄ  ｔｏ）」として記載され得る。このような文脈に
おいて「よう構成される」は、動作中に上記１つ又は複数のタスクを実施する「回路構成
を有する」ことを一般に意味する、構造の広範な説明である。従ってユニット／回路／構
成部品は、ユニット／回路／構成部品が現在オンでなくても上記タスクを実施するよう構
成できる。一般に「よう構成される」に対応する構造を形成する回路構成は、ハードウェ
ア回路を含んでよい。同様に、記載を簡略化するために、様々なユニット／回路／構成部
品は、１つ又は複数のタスクを実施するとして記載され得る。このような記載は「よう構
成される」という語句を含むものとして解釈されるものとする。１つ又は複数のタスクを
実施するよう構成されるユニット／回路／構成部品の列挙は、これらユニット／回路／構
成部品に関して米国特許法第１１２条第６段落の解釈を援用しないことを明示的に意図し
たものである。より一般には、いずれの要素の列挙は、「…のための手段（ｍｅａｎｓ  
ｆｏｒ）」又は「…のためのステップ（ｓｔｅｐ  ｆｏｒ）」という語句が具体的に使用
されていない限り、上記要素に関して米国特許法第１１２条第６段落の解釈を援用しない
ことを明示的に意図したものである。
【００４１】
参照による援用
Ｍｉｃｈａｅｌ  Ｂ．Ｄｏｅｒｒ、Ｗｉｌｌｉａｍ  Ｈ．Ｈａｌｌｉｄｙ、Ｄａｖｉｄ
Ａ．Ｇｉｂｓｏｎ、Ｃｒａｉｇ  Ｍ．Ｃｈａｓｅを発明者とする、発明の名称「Ｐｒｏ
ｃｅｓｓｉｎｇ  Ｓｙｓｔｅｍ  Ｗｉｔｈ  Ｉｎｔｅｒｓｐｅｒｓｅｄ  Ｓｔａｌｌ  Ｐ
ｒｏｐａｇａｔｉｎｇ  Ｐｒｏｃｅｓｓｏｒｓ  Ａｎｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  
Ｅｌｅｍｅｎｔｓ」の米国特許第７４１５５９４号は、その全体を参照することにより、
本明細書においてその全体が完全に論述されているかのように、本明細書に援用されるも
のとする。
【００４２】
用語
コンピュータシステム‐用語「コンピュータシステム」は、パーソナルコンピュータシ
ステム（ＰＣ）、メインフレームコンピュータシステム、ワークステーション、ネットワ
ーク家電、インターネット家電、パーソナルデジタルアシスタント（ＰＤＡ）、テレビジ
ョンシステム、グリッドコンピューティングシステム若しくはその他のデバイス又はデバ
イスの組み合わせを含む、様々なタイプの計算又は処理システムのいずれかを指す。一般
に、用語「コンピュータシステム」は、メモリ媒体からの命令を実行する少なくとも１つ
のプロセッサを有するいずれのデバイス（又は複数のデバイスの組み合わせ）を包含する
ものとして広く定義できる。
【００４３】
ソフトウェアアプリケーション‐用語「ソフトウェアアプリケーション」（本出願では
単に「アプリケーション」とも呼ぶ）は、その一般的な意味の全範囲を有することを意図
したものであり、１つ又は複数のメモリに記憶でき、かつ１つ又は複数のプロセッサが実
行できる、あらゆるタイプのプログラム命令、コード、スクリプト及び／又はデータ又は
これらの組み合わせを含む。例示的なソフトウェアアプリケーションは、Ｃ、Ｃ＋＋、Ｆ
ＯＲＴＲＡＮ、Ｊａｖａ（登録商標）、アセンブリ言語等のテキストベースプログラム言
語で書かれたプログラム；グラフィックプログラム（グラフィックプログラム言語で書か
れたプログラム）；アセンブリ言語プログラム；機械言語にコンパイルされたプログラム
；スクリプト；並びに他のタイプの実行可能なソフトウェアを含む。一般にプログラムは
、１つ又は複数のデータ構造を指定し、またこれらの構造内のデータに対して取るべき手
順のステップを指定して１つ又は複数の機能を実施する、命令のセットである。プログラ
ムは、特定の機械アーキテクチャに関して標的化される場合が多い。更に抽象的には、プ
ログラムの手順のステップは、上記プログラムのアルゴリズムと呼ばれる場合がある。
【００４４】
アプリケーションは、マルチプロセッサシステム（ＭＰＳ）の１つ又は複数のプロセッ
サ上で実行でき、ＭＰＳのローカルメモリのうちの１つ若しくは複数からデータを読み出
すことができ、及び／又はＭＰＳのローカルメモリのうちの１つ若しくは複数にデータを
書き込むことができる。アプリケーションは、１つ又は複数の計算タスクを含んでよく、
ここで各タスクは典型的にはＭＰＳの単一のプロセッサ上で実行され、１つ又は複数のア
プリケーションからの１つ又は複数のタスクと上記プロセッサを共有してよい。アプリケ
ーションは、特定の機能又は演算を実施してよい。アプリケーションが２つ以上のタスク
を含む場合、これらタスクは互いに通信して上記機能又は演算を実施してよい。
【００４５】
ＭＰＳは複数のアプリケーションを同時に実行してよく、例えばこれらアプリケーショ
ンは互いに並列に実行される。アプリケーションは互いに通信してよく、これらアプリケ
ーションが実施する各機能又は演算は、より大きい又はより高いレベルの機能又は演算を
実施するために互いを利用してよい。
【００４６】
ソフトウェアプログラミングモデル‐ソフトウェアプログラミングモデルは、簡単に言
うと、ユーザの、機械及びその動作環境のビューである。ソフトウェアプログラミングモ
デルは、アプリケーションを記述できる１つ又は複数の言語、並びに上記１つ又は複数の
言語で直接表現できるものを超えた抽象化及びプセル化された機能性を提供するライブラ
リを含む。ソフトウェアプログラミングはまた、それを通してアプリケーションがその外
部のエンティティ（Ｉ／Ｏ、拡張メモリ等）と相互作用する、及びそれを通して上記アプ
リケーションに関するメタ情報（例えばパフォーマンス制約又は要件）が表現される、機
構も含む。プログラミングモデルの２つの主要な部分は、並列処理がアプリケーション内
でどのように表現されるか又はアプリケーションからどのように引き出されるかを示す制
御モデル、及びアプリケーションの並列のエンティティがどのように情報を共有するかを
示す通信モデルである。
【００４７】
ソフトウェアプログラミングモデルは、実際の制御及びデータフロー及びアプリケーシ
ョンが最終的に実行された場合に発生することになる通信の、「理想化された」ビューを
提示する。演算の意味規則は、下層の実装がソフトウェアプログラミングモデルにおいて
記述された通りに正確に実施されているかのようになるものであり、同一の効果（答え）
が得られる限り、実際に行われるステップは重要ではない。実際の実装ステップは、コー
ドの効率及び／又はデータサイズ、速度、電力消費等の理由により異なり得る。
【００４８】
ソフトウェアプログラミングモデルの考慮すべき重要な事柄は、ツールセット（コンパ
イラ等）による、及びそれに続く実行モデル下でのアプリケーションの正確かつ効率的な
処理をサポートするために十分な情報もキャプチャしながら、便利かつ自然でユーザにと
って直感的な用語でのアプリケーションの表現をサポートする機構を、ソフトウェアプロ
グラミングモデルがユーザに同時に提供することである。
【００４９】
ハードウェアプログラミング／実行モデル‐ハードウェアプログラミングモデル又は実
行モデルは、アプリケーションがどのように実行されるかを表す。これは、アプリケーシ
ョンの論理及びデータオブジェクトに対応する情報のセットがどのように表現されるか、
並びにその情報が経時的にどのように処理されて、アプリケーションによって指定された
機能が達成されるかを定義する。システムツール（コンパイラ、並列処理抽出器、配置配
線（ｐｌａｃｅ‐ａｎｄ‐ｒｏｕｔｅ）等）の目的は、アプリケーションをそのソフトウ
ェアプログラミングモデル表現から対応する実行モデル表現に変換することである。実行
モデルは、（例えばライブラリを通して）ソフトウェアプログラミングモデルによって記
述された機能性をサポートし、（例えばＯ／Ｓを通して）ハードウェアの使用を監視、調
停、管理するために必要な機構を含む。
【００５０】
実行モデルは、ソフトウェアプログラミングモデルと極めて密接に対応してよく、又は
完全に異なっていてよい。ソフトウェアプログラミングモデルの異なる複数の態様は、実
行モデルへの異なる直接的対応度を有してよい。対応のレベルは、下層のハードウェアア
ーキテクチャが、元々の（ソフトウェア）プログラミングモデルとどの程度類似している
かに関連する。類似性が高いほど対応性が高い。
【００５１】
下層のハードウェアアーキテクチャ‐下層のハードウェアアーキテクチャは、計算が実
行される物理デバイスのアーキテクチャである。このレベルでは、全ての動作はデバイス
が実行する物理的動作に直接対応する。下層のハードウェアアーキテクチャを記述できる
抽象のレベルは、（設計空間開発中の評価、シミュレーション、特性決定、トレードオフ
分析に有用な）高次概念アーキテクチャから、（製作されるデバイスの物理的設計の実施
に有用な）低次実装アーキテクチャに変化し得る。実装レベルにおいてさえ、下層のハー
ドウェアアーキテクチャの異なる複数の例は、能力又は性能において異なり得る。例えば
ある例は１０×１０グリッドの処理ユニットを実装してよく、その一方で別の例はたった
６×６グリッドしか実装しなくてよい。これらはそれぞれ能力が異なるものの、下層のハ
ードウェアアーキテクチャとの整合性を保持している。
【００５２】
自動的に（ａｕｔｏｍａｔｉｃａｌｌｙ）：その作用又は動作を直接指定又は実施する
ユーザ入力を必要とせずに、コンピュータシステム（例えばコンピュータシステムが実行
するソフトウェア）又はデバイス（例えば回路構成、プログラム可能なハードウェア要素
、ＡＳＩＣ等）が実施する動作又は操作について用いる。従って用語「自動的に」は、ユ
ーザが手動で実施又は指定する操作（ここでユーザが操作を直接実施するために入力を提
供する）と対照的なものである。自動処理は、ユーザが提供する入力によって開始される
場合があるが、これに続く「自動的に」実施される動作は、ユーザが指定するものではな
く、即ち「手動で」実施される（ユーザが各動作の実施を指定する）ものではない。例え
ばユーザが、各フィールドを選択し、（例えば情報をタイピングすることによって、チェ
ックボックスを選択することによって、無線選択によって等で）情報を指定する入力を提
供することによって、電子フォームを埋める場合、仮にコンピュータシステムがユーザの
動作に応答して上記フォームを更新しなければならないとしても、これは上記フォームを
手動で埋めたことになる。このようなフォームはコンピュータシステムによって自動で埋
めることができ、この場合コンピュータシステム（例えばコンピュータシステム上で実行
されるソフトウェア）は、フォームのフィールドを分析して、フィールドへの回答を指定
するいずれのユーザ入力を必要とせずにフォームを埋める。上述のように、ユーザはフォ
ームを自動で埋める動作を発動する場合はあるが、実際にフォームを埋める動作には関わ
らない（例えばユーザはフィールドへの回答を手動で指定せず、回答は自動的に完了する
）。本明細書は、ユーザが行う動作に応答して自動的に実施される操作の様々な例を提供
する。
【００５３】
ＭＰＳシステムの概要
マルチプロセッサシステム（ＭＰＳ）及び関連する方法の様々な実施形態を説明する。
マルチプロセッサシステム（ＭＰＳ）は、複数の処理要素（ＰＥ）を含むシステムとして
定義できる。ＭＰＳは、これらＰＥ間に散在する複数のメモリを有してよく、あるいは単
一の共有メモリを有してよい。本明細書で使用される場合、用語「処理要素（ｐｒｏｃｅ
ｓｓｉｎｇ  ｅｌｅｍｅｎｔ）」は、プロセッサ若しくはＣＰＵ（中央演算処理装置）、
マイクロプロセッサ又はプロセッサコアを指す。ＭＰＳは２つ以上のいずれの個数のＰＥ
を含んでよいが、いくつかのＭＰＳは、典型的には汎用プロセッサ（ＧＰＰ）を１つのみ
、又は数個のＧＰＰのみを含む従来のコンピュータシステムよりも有意に多い個数のＰＥ
を含んでよいことに留意されたい。例えばいくつかのＭＰＳは、４、８、１６、３２又は
６４個のＰＥを含んでよい（他の例は例えば数ダース、数百個又は数千個ものＰＥを含む
）。いくつかの実施形態では、大型ＭＰＳに好適なＰＥは、低電力消費を目的とした特別
な構成により、従来のコンピュータシステムによって使用される汎用プロセッサよりもエ
ネルギ効率が高いものであってよい。
【００５４】
ＭＰＳはまた、ＰＥ及び／又はメモリを相互接続する相互接続ネットワーク（ＩＮ）も
含んでよい。ＰＥ及びメモリは、円形次元（例えばループ又はリング）を含む１、２、３
又は４以上の次元で相互接続してよい。より高い次元のＭＰＳは、より低い次元のファブ
リケーション媒体上にマッピングできる。例えば４次元（４Ｄ）超立方体の形状を有する
ＭＰＳは、シリコン集積回路（ＩＣ）チップの３Ｄスタック上に、又は単一の２Ｄチップ
上に、又は計算ユニットの１Ｄの線上にさえ、マッピングできる。低次元のＭＰＳをより
高次元の媒体にマッピングすることもできる。例えば計算ユニットの１Ｄの線を、ＩＣチ
ップの２Ｄ平面上に曲がりくねった形状で展開でき、又はチップの３Ｄ積層体へと巻くこ
とができる。ＭＰＳは複数のタイプの計算ユニットと、プロセッサ及びメモリが散在する
構成とを含んでよい。広い意味でのＭＰＳには、ＭＰＳの階層又は入れ子構成、特に相互
接続されたＩＣチップからなるＭＰＳも含まれ、この場合ＩＣチップは１つ又は複数のＭ
ＰＳを含み、これらＭＰＳもまた更に深い階層構造を有してよい。
【００５５】
本出願において使用される用語ＭＰＳは、複数のプロセッサの比較的均一なセットと、
いわゆる「プラットフォームＩＣ」チップ上に集積された汎用プロセッサ及び特殊化され
たプロセッサの異種集団との両方を包含する。プラットフォームＩＣチップは数個〜多数
のプロセッサを含んでよく、これらは典型的には共有メモリによって相互接続され、場合
によってはオンチップネットワークによって相互接続される。ＭＰＳと「プラットフォー
ムＩＣ」チップとの間には違いがあってもなくてもよい。しかしながら「プラットフォー
ムＩＣ」チップは、特定の垂直的市場における特定の技術要件に対処するために市販され
ているものであってよい。
【００５６】
一般に、ＭＰＳのためのメモリは階層として組織してよく、この階層は頂部に高速なメ
モリを有し、階層を１段ずつ下がるにつれてより低速であるがより大容量のメモリを有す
る。ＭＰＳ中において、階層の頂部の補助メモリは、各ＰＥの近傍に位置してよい。各補
助メモリは、最適な命令又は最適なデータを保持するよう特殊化できる。特定のＰＥのた
めの補助メモリは、そのＰＥ専用のものであっても、又は他のＰＥと共用であってもよい
。
【００５７】
メモリ階層を更に下がると、各ＰＥに隣接する補助メモリの何倍も大きいビット容量を
有する半導体同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ）等の、比較的大型
の共有メモリが存在してよい。ＳＤＲＡＭは、その製作を特定化するために、ＰＥ及び補
助メモリとは分離された１つ又は複数のＩＣチップ上に位置してよい。メモリ階層を更に
下がると、フラッシュメモリ、磁気ディスク及び光学ディスク等の他のタイプのメモリが
存在してよい。
【００５８】
ＭＰＳは、特定の機能を達成できるよう、ソフトウェアプログラムを用いてプログラム
されてよい。各機能は、ＭＰＳ中のＰＥのうちの１つ又は複数によって実行されてよい。
しばしば、ＭＰＳ上で複数のプログラムを同時に実行してよい。プログラムは、より複雑
な機能を実施するために、及び並列処理技術を採用することによってより単純な機能をよ
り迅速に実施するために、共に実行され、互いに通信してよい。ＰＥ間のこのような協調
を、本出願では連携処理と呼ぶ。
【００５９】
ＭＰＳは、関連するデータ及びコマンドのソースが入力データ及びコマンドを提供する
よりも早くこれらを受信でき、無視できる程度に十分に低いレイテンシで結果を提供でき
るよう、十分な速さでアプリケーション又はプログラムを実行できる。このようなアプリ
ケーションは、遅延なくリアルタイムで動作する、即ち「リアルタイムアプリケーション
」と呼ばれる。関連する入力データ（又はコマンド）は「リアルタイムデータ」（又は「
リアルタイムコマンド」）と呼ばれる。例えばＭＰＳは入力信号を介してリアルタイムデ
ータを受信してよい。アプリケーション、プログラム又は機能のうちの１つ又は複数は入
力信号を処理してよく、場合によっては、１つ又は複数のプログラムに基づいて修正され
た又は追加のリアルタイムデータを伴う出力信号を生成してよい。
【００６０】
図３‐ＭＰＳブロック図及び概要
図３は、マルチプロセッサシステム（ＭＰＳ）の一実施形態を示すブロック図である。
図示されている実施形態では、ＭＰＳ１０は複数の処理要素（ＰＥ）及び複数のデータメ
モリルータ（ＤＭＲ）を含み、ＤＭＲは、データ及び命令を互いに通信するよう連結され
た、動的に構成可能な通信器、又は動的に構成可能な通信要素と呼ぶこともできる。本出
願で使用される場合、ＰＥはＰＥノードとも呼ばれる場合があり、またＤＭＲはＤＭＲノ
ードとも呼ばれる場合がある。
【００６１】
処理システム（ＭＰＳ）１０は、ＧＰＭＣ、ＤＳＰ、ＦＰＧＡ又はＡＳＩＣが現在使用
されている様々なシステム及びアプリケーションのいずれにおいて使用してよい。従って
例えば、処理システム１０は、様々なタイプのコンピュータシステム又は計算を必要とす
る他のデバイスのいずれにおいて使用してよい。１つの考えられる実施形態では、処理シ
ステム１０を、デジタルビデオディスプレイシステムの信号処理デバイスとして使用する
。
【００６２】
一実施形態では、ＰＥは、データを操作するために構成された１つ又は複数の算術論理
ユニット（ＡＬＵ）、ＡＬＵを制御するために構成された１つ又は複数の命令処理ユニッ
ト（ＩＰＵ）、命令又はデータを保持するよう構成された１つ又は複数のメモリ、並びに
様々な種類の多重化装置及び復号器を含んでよい。このような実施形態は多数のポート（
「プロセッサポート」）を含んでよく、これらのうちのいくつかはＤＭＲに接続されるよ
う構成されてよく、残りは他のＰＥに接続されるよう構成されてよい。図７はＰＥの一実
施形態のブロック図であり、これについて以下に更に説明する。
【００６３】
一実施形態では、ＤＭＲは、データ及び命令を保持するよう構成された１つ又は複数の
ランダムアクセスメモリ（ＲＡＭ）、構成可能なコントローラ、クロスバースイッチ等の
ネットワークスイッチ、レジスタ並びに多重化装置を含んでよい。このような実施形態は
多数のポートを含んでよく、これらのうちのいくつかはＰＥに接続されるよう構成されて
よく（本出願ではＰＥタイプポートと呼ばれる）、残りはＤＭＲに接続されるよう構成さ
れてよい（本出願ではＤＭＲタイプポートと呼ばれる）。ＤＭＲ又はＰＥのいずれに又は
いずれから接続されるように構成されているかにかかわらず、いずれの所定のポートに関
して、このような所定のポートを通して特定のクロックサイクル内に伝送可能なデータの
量は、様々な実施形態において変化し得ることに留意されたい。例えば一実施形態では、
所定のポートは、１クロックサイクルにつき１データ語を伝送するよう構成されてよく、
その一方で別の実施形態では、所定のポートは１クロックサイクルにつき複数のデータ語
を伝送するよう構成されてよい。更に別の実施形態では、所定のポートは、時分割多重化
等の技術を採用して、複数のクロックサイクルに亘って１つのデータ語を伝送してよく、
これによってポートを含む物理的接続の個数を削減できる。
【００６４】
ＭＰＳ１０の一実施形態では、各ＰＥは、命令のために予約された小型ローカルメモリ
を含んでよく、ローカルデータストレージを極めて僅かしか有しなくてよい。このような
実施形態では、各ＰＥに近接するＤＭＲは、所定のＰＥにオペランドを提供するよう構成
されてよい。特定の実施形態では、多数のＰＥ命令に関して、１クロックサイクル中に、
所定のＰＥが近隣のＤＭＲからオペランドを読み出し、ＡＬＵ演算を実行し、ＡＬＵ結果
を所定の近隣のＤＭＲに保存してよい。これにより、１つのＰＥからのＡＬＵ結果を、そ
のクロックサイクル中に、実行の直後に複数の他のＰＥにとって利用可能とすることがで
きる。このようにして結果を生成することにより、近隣のＰＥの実行を密接に連携したも
の、即ち「緊密に連結されたもの」とすることができる。
【００６５】
本出願で使用される場合、所定のＤＭＲ又はＰＥの視点から、近隣のＤＭＲ又はＰＥは
、特定のレイテンシ範囲内で上記所定のＤＭＲ又はＰＥからアクセスできるＤＭＲ又はＰ
Ｅを指す。いくつかの実施形態では、近接関係の程度を定義するレイテンシは、例えばク
ロック速度等の因子に応じて変化し得る。更にいくつかの実施形態では、近接の複数の度
合いを定義してよく、これらの度合いは、異なる複数のアクセスレイテンシに対応してよ
い。例えば一実施形態では、「最も近い近接」は、データが要求されたクロックサイクル
と同一のクロックサイクル中にこのデータを供給できるデバイスとして定義してよく、「
次に近い近接」は、データが要求された後、１クロックサイクル以内にこのデータを供給
できるデバイスとして定義してよく、これ以降も同様である。他の実施形態では、近接関
係を定量化するために他のメトリクスを使用してよいことも考えられる。
【００６６】
所定のＭＰＳ実施形態では、いくつかのＤＭＲ及びＰＥは、他のＤＭＲ及びＰＥと論理
的に隣接してよい。本出願で使用される場合、「論理的に隣接する」は、あるデバイスの
１つ又は複数のポートが、他のデバイスの各ポートに、介在するＤＭＲ又はＰＥを通過せ
ずに直接接続されるような、あるＤＭＲ及び別のＤＭＲ又はあるＤＭＲ及びあるＰＥとい
った２つのデバイス間の関係を指す。更に所定のＭＰＳの実施形態では、いくつかのＤＭ
Ｒ及びＰＥは、他のＤＭＲ及びＰＥと物理的に隣接してよい。本出願で使用される場合、
「物理的に隣接する」は、あるＤＭＲ及び別のＤＭＲ又はあるＤＭＲ及びあるＰＥといっ
た２つのデバイス間に他のいずれのＤＭＲ又はＰＥも物理的に位置していないような、こ
れら２つのデバイス間の関係を指す。
【００６７】
いくつかのＭＰＳの実施形態では、論理的及び／又は物理的に隣接するＤＭＲ及びＰＥ
等のデバイスは、近接している又は近隣のデバイスでもある。しかしながらいくつかの実
施形態では、所定のデバイス間の論理的及び／又は物理的な隣接は、これら所定のデバイ
ス間に、近接関係又は特定の度合いの近接関係を伴わないことに留意されたい。例えば一
実施形態では、あるＤＭＲは、相当な距離だけ離れて位置する別のＤＭＲに直接接続され
てよい。このようなペアは論理的には隣接しているものの物理的には隣接していない場合
があり、一方のＤＭＲから他方のＤＭＲへの信号伝播時間は、近接のレイテンシ要件を満
たすには長過ぎるものとなり得る。同様に一実施形態では、あるＤＭＲは別のＤＭＲと物
理的には隣接しているものの直接接続されておらず、従って論理的には隣接していない場
合がある。一方のＤＭＲから他方のＤＭＲへのアクセスは、１つ又は複数の中間ノードを
横断し得、結果として発生する通過遅延は、近接のレイテンシ要件を満たすには大き過ぎ
るものとなり得る。
【００６８】
ＭＰＳ１０の所定の実施形態の技術及び実装形態に応じて、ＤＭＲの複数のポートの具
体的な数及びＤＭＲのメモリのサイズは、全体としてのＤＭＲの所望の実行速度及びサイ
ズとバランスを取ってよい。例えばあるＤＭＲの実施形態は、４つのＰＥタイプポート、
４つのＤＭＲタイプポート、４Ｋ語のメモリを含んでよい。このようなＤＭＲの実施形態
は、ダイレクトメモリアクセス（ＤＭＡ）機構を提供するよう構成されてよい。ＤＭＡ機
構により、ＰＥが結果を計算している間に、所定のＤＭＲが、他のＤＭＲへ若しくは他の
ＤＭＲから、又はＭＰＳ１０の外部の位置へ若しくはＭＰＳ１０の外部の位置から、効率
的にデータをコピーできるようになる。
【００６９】
ＭＰＳ１０の一実施形態では、データ及び命令は、複数の異なる方法のうちの１つによ
ってＤＭＲ間で伝送されてよい。シリアルバスはＭＰＳ１０内の全てのメモリに供給され
てよく、このようなバスは、外部メモリからＭＰＳ１０を初期化するために、又はＭＰＳ
データ構造の試験をサポートするために使用できる。短距離伝送に関して、所定のＰＥは
、その近隣のＤＭＲへ又は近隣のＤＭＲからデータを直接移動させるようプログラムされ
てよい。データ又は命令を更に長距離に亘って伝送するために、ＤＭＲのネットワーク内
において通信経路を動的に生成及び破壊してよい。
【００７０】
このような比較的長距離のデータ伝送のために、ＭＰＳ１０内の相互接続されたＤＭＲ
のネットワークは、通信経路用のスイッチドルーティングファブリック（ＳＲＦ）を構成
してよい。このような実施形態では、ＳＲＦ内の通信経路を管理するために少なくとも２
つの方法が存在し得る。第１の方法はグローバルプログラミングによるものであり、経路
はソフトウェア制御によって（例えば人であるプログラマによって又はルーティング能力
を有するコンパイラによって）選択でき、命令をＤＭＲ構成コントローラにコードしてク
ロスバーを適切にプログラムできる。経路を生成するために、その経路に沿った全てのＤ
ＭＲを、特定のルーティング機能によって明白にプログラムしてよい。経路が頻繁に生成
及び破壊される動的な環境において、多数のクロスバー構成コードが必要となり得、これ
らのストレージは潜在的に限定されたＤＭＲ  ＲＡＭリソースを消費し得る。
【００７１】
通信経路を管理するための第２の方法は、「ワームホールルーティング」と呼ばれる。
ワームホールルーティングを実装するために、各ＤＭＲは、ステアリング機能のセットと
、メッセージと呼ばれる語のシーケンスの、ＳＲＦを通る進行を停止及び再開させる機構
とを含んでよい。全ての通信経路がステアリング機能を共通して使用及び再使用してよい
ため、ＤＭＲ  ＲＡＭを占有し得る構成コードの量は、上述のグローバルプログラミング
法よりも大幅に小さくなり得る。ワームホールルーティング法に関して、ここでもまたソ
フトウェア制御を使用して、経路が使用する特定のリンクを選択してよいが、経路生成（
本出願ではセットアップとも呼ぶ）及び破壊／リンク解放（本出願ではティアダウンとも
呼ぶ）のプロセスは、最小のソフトウェア介入を伴ってハードウェア内に実装できる。
【００７２】
経路上でのデータ語の潜在的な損失を防止するために、ＭＰＳ１０の実施形態は、経路
に沿った受信器と伝送器との間のフロー制御を実装してよい。フロー制御は、対応する受
信器がそれ以上データを受信できない場合に伝送器を停止させることができ、また対応す
る受信器がデータを受信する準備ができた状態となった場合に伝送器を再開させることが
できる機構を指す。経路上でのデータのフローの停止及び再開は、ワームホールルーティ
ングにおけるメッセージの進行の停止及び再開と多くの類似点を有し、これら２つは統合
されたスキーム内で組み合わせることができる。
【００７３】
一実施形態では、ＭＰＳ１０は複数のＰＥ及びＤＭＲを含んでよく、これらＰＥは同一
であってよく、これらＤＭＲは同一であってよく、均一なアレイ内で接続されてよい。均
一なアレイにおいて、ＰＥの大半は同一であってよく、ＰＥの大半はそれぞれ、ＤＭＲへ
の同一数の接続を有してよい。また均一なアレイにおいて、ＤＭＲの大半は同一であって
よく、ＤＭＲの大半はそれぞれ、他のＤＭＲ及びＰＥへの同数の接続を有してよい。ＭＰ
Ｓの一実施形態のＰＥ及びＤＭＲは、実質的に均一な様式で散在していてよい。本出願で
使用される場合、「実質的に均一な散在」は、ＤＭＲに対するＰＥの比が、アレイの複数
の部分領域の大半に亘って一貫している構成を指す。
【００７４】
実質的に均一な様式で配設された均一なアレイは、予測可能な相互接続パターンを提供
する、アレイ全体に亘ってソフトウェアモジュールを再使用できるようにする等、特定の
有利な特徴を有し得る。一実施形態では、均一なアレイにより、少数のＰＥ及びＤＭＲの
例を設計及び試験できる。システムは、１つのＤＭＲ及び１つのＰＥを備えるユニットを
製作し、このユニットを複数回反復する、即ち「タイルリングする（ｔｉｌｉｎｇ）」こ
とによって、組み立てることができる。このようなアプローチは、共通のシステム要素の
再使用により、設計及び試験コストを低下させることができる。
【００７５】
また、ＰＥ及びＤＭＲの構成可能な性質により、物理的に均一なアレイ上で極めて広範
な不均一挙動が発生するようにプログラムできるようにすることができることに留意され
たい。しかしながら代替実施形態では、ＭＰＳ１０は不均一なＤＭＲ及びＰＥユニットで
形成してもよく、これらユニットは、規則的な若しくは不規則なアレイに、又はランダム
にさえ接続してよい。一実施形態では、ＰＥ及びＤＭＲの相互接続は、例えば集積回路（
ＩＣ）、セラミック基材又はプリント回路基板（ＰＣＢ）上の回路トレースとして実装し
てよい。しかしながら代替実施形態では、このような相互接続は、例えば電磁エネルギ（
即ち電波若しくは光学エネルギ）、無線（即ち無誘導）エネルギ、粒子（電子ビーム等）
、又は分子上の電位のための導波路といった様々な細密通信リンクのいずれであってよい
。
【００７６】
ＭＰＳ１０は単一の集積回路上に実装してよい。一実施形態では、複数のＭＰＳ集積回
路を組み合わせて、より大型のシステムを生成してよい。ＭＰＳ１０の所定の実施形態は
、シリコン集積回路（Ｓｉ‐ＩＣ）技術を用いて実装してよく、またこのような技術の固
有の特徴の原因となる様々な特徴部分を採用してよい。例えばＳｉ‐ＩＣチップ上の回路
は薄い平面内に制限され得る。これに対応して、ＭＰＳ１０の所定の実施形態は、図３に
示すようなＰＥ及びＤＭＲの２次元アレイを採用してよい。しかしながら、ＰＥ及びＤＭ
Ｒの異なる構成を含む、ＭＰＳの代替実施形態が考えられる。
【００７７】
更に、Ｓｉ‐ＩＣチップ上で使用可能な配線密度は、このようなチップ間でのものより
遥かに高くてよく、各チップは、オンチップ信号とオフチップ信号とをインタフェース接
続するために特別な入力／出力（Ｉ／Ｏ）回路の周縁部を有してよい。これに対応して、
ＭＰＳ１０の所定の実施形態は、チップのコアにあるＰＥ及びＤＭＲの均一なアレイと、
チップの周縁部に沿った修正されたＰＥ／ＤＭＲユニットとで構成された、若干不均一な
アレイを採用してよい。しかしながら、均一なＰＥ／ＤＭＲユニットと修正されたＰＥ／
ＤＭＲユニットとの異なる構成及び組み合わせを含む、ＭＰＳの代替実施形態が考えられ
る。
【００７８】
また、Ｓｉ‐ＩＣ回路によって実施される計算動作により熱が生成される場合があり、
これはＩＣパッケージングによって除去できる。ＩＣパッケージングの増大には追加の空
間が必要となり得、ＩＣパッケージングを通る、及びＩＣパッケージングの周囲の相互接
続は、経路の長さに比例する遅延を招き得る。従って上述のように、極めて大型のＭＰＳ
は、多数のチップを相互接続することによって構成してよい。このような多チップＭＰＳ
実施形態のプログラミングは、チップ間信号遅延がチップ内遅延より遥かに長いことを考
慮したものであってよい。
【００７９】
所定のＳｉ‐ＩＣ  ＭＰＳ１０の実施形態では、単一のチップ上に実装できるＰＥ及び
ＤＭＲの最大数は、所定のＳｉ‐ＩＣ技術によって可能な小型化、並びに各ＰＥ及びＤＭ
Ｒの複雑さによって決定できる。このようなＭＰＳの実施形態では、ＰＥ及びＤＭＲの回
路複雑性は、標的レベルの計算スループットを達成することを条件として最小化できる。
このように最小化されたＰＥ及びＤＭＲを、本出願では「合理化された（ｂｅｉｎｇ  ｓ
ｔｒｅａｍｌｉｎｅｄ）」と呼ぶ場合がある。ＭＰＳ１０の一実施形態では、ＰＥに関す
るスループットの標的レベルは、同一のＳｉ‐ＩＣ技術において作製される最良のデジタ
ル信号プロセッサ（ＤＳＰ）の算術実行ユニットのスループットの標的レベルに匹敵する
ものであってよい。しかしながら、標的ＰＥスループットに関する代替的な基準を使用し
てよい他のＭＰＳの実施形態が考えられる。
【００８０】
いくつかの実施形態では、ＭＰＳ１０は、ＤＳＰ及びＦＰＧＡアーキテクチャの最良の
特徴を採用してよい。ＤＳＰと同様、ＭＰＳ１０は、多数の処理ユニット及びオンチップ
メモリを有するプログラム可能なチップであってよい。しかしながらＤＳＰに対して、Ｍ
ＰＳ処理ユニットは合理化されてよく、個数が多くてよく、またＭＰＳ処理ユニット間の
データ移動並びにオンチップ及びオフチップのデータ移動の帯域幅を最大化するために、
新規の方法で相互接続されてよい。ＤＳＰより多くの処理ユニットを有することにより、
ＭＰＳ１０は、単位時間あたりに更に多くの多重化を実施でき、合理化された処理ユニッ
トはエネルギ使用を最小化できる。内部並列処理を行う多くのＤＳＰは、バス指向性アー
キテクチャであってよい。いくつかの実施形態では、ＭＰＳ１０はバスを含まなくてよく
、ＳＲＦ内に埋め込まれた、例えばＤＭＲ内で近接した共有ローカルメモリを含んでよく
、これにより、バス指向性アーキテクチャより有意に高い総帯域幅を提供できる。
【００８１】
ＦＰＧＡアプローチと比べて、いくつかのＭＰＳの実施形態はより粗粒化されていてよ
い。例えばＭＰＳの一実施形態では、演算は自然語長（例えば１６ビット）を有してよく
、自然語長の倍数のデータを用いて実施した場合、計算はより効率的となり得る。いくつ
かのＭＰＳの実施形態では、ＰＥ及びＤＭＲは、ＦＰＧＡにおいて実現される同等の構造
よりも密であってよく、これにより、比較的短い平均配線長、低い配線抵抗、少ないエネ
ルギ使用を得ることができる。ＦＰＧＡ実装形態とは対照的に、いくつかのＭＰＳの実施
形態では、ＭＰＳ内の全てのＡＬＵはプロセッサの一部（即ちＰＥ）であってよく、これ
は、オペランドのフェッチ、及びＤＭＲ内にある周囲の迅速なメモリへの結果のライトバ
ック（ｗｒｉｔｅ  ｂａｃｋ）を促進できる。ＡＬＵ、フェッチ及びライトバック動作に
関するタイミング及びクロックスキューの問題は、ＩＣチップの設計中に一度に解決でき
、またＦＰＧＡ実装形態において典型的であるように、新規のアプリケーションそれぞれ
において再度解決する必要はない。
【００８２】
ＭＰＳトポロジ及び通信
図３に示すＭＰＳ１０は、図示したようにＰＥ間にＤＭＲを散在させることによって、
迅速なメモリへの十分な接続をＰＥに提供できる。このような構成は、分離型（即ち非散
在型）構成に対して、所定のＰＥがＤＭＲ内のメモリにアクセスするために必要な時間を
削減でき、本出願ではこれを散在型グリッド構成と呼ぶ場合がある。図３の実施形態では
、ＰＥとＤＭＲとの比はおおよそ１：１である。しかしながら、異なるＰＥとＤＭＲとの
比を含んでよい他のＭＰＳの実施形態が考えられる。
【００８３】
ＤＭＲとＰＥとの間の接続は、図３には明示されていない。というのは、異なるタイプ
及び数の接続を用いる、多数の可能な接続スキームが存在し得るためである。
【００８４】
図４‐ＭＰＳ接続スキーム
図４は、ＭＰＳ接続スキームの一実施形態を示すブロック図である。ＭＰＳ接続スキー
ム２０は、複数のＤＭＲ及びＰＥを含み、図３のＭＰＳの一部分を説明するものであり得
る。ＭＰＳ接続スキーム２０では、各ＰＥは４つの近隣のＤＭＲに接続され、各ＤＭＲは
４つの近隣のＰＥ及び４つの近隣のＤＭＲに接続される。従ってＭＰＳ接続スキーム２０
は、上述のＰｌａｎａｒＡ接続スキームを説明するものであり得る。
【００８５】
ＭＰＳ接続スキーム２０において高帯域幅ポートをサポートするために、ポート間（Ｐ
Ｅ‐ＤＭＲ間又はＤＭＲ‐ＤＭＲ間）の接続は短くてよく（即ち近隣に限定されてよく）
、また語の幅であってよい（これは、接続のデータ部分の導電体（ライン）の数が、ＡＬ
Ｕオペランド中で使用されるビット数と同一であり得ることを意味する）。ＰＥ‐ＤＭＲ
間接続はアドレスラインを含んでよい。ＤＭＲ‐ＤＭＲ間接続は必ずしもアドレスライン
を有しなくてよいが、フロー制御用ラインを有してよい。
【００８６】
ＰＥノードを簡素なまま維持することによって、大型アレイ（例えばＭＰＳの一実施形
態では、１６行×１６列＝２５６個のＰＥ）を、単一のＶＬＳＩ  ＩＣ上に、それほど高
くないコストで配置できる。好適なＶＬＳＩ技術は、シリコン又は他の半導体内に双極ト
ランジスタを有する又は有しない、相補型金属酸化膜半導体（ＣＭＯＳ）電界効果トラン
ジスタを含んでよいが、これに限定されない。
【００８７】
いくつかのＭＰＳの実施形態では、ノード間の通信はプログラマの制御下であってよい
。ＭＰＳにおいて、各ＰＥは近隣のＤＭＲとデータ／命令を通信してよく、また任意にこ
れらのＤＭＲを通して他のＤＭＲ及びＰＥへと通信してよい。これは、短距離に亘る少量
のデータの伝送に関して非常に効率的である。しかしながら、より大きなデータのブロッ
ク又はより長い距離に関しては、ＤＭＡエンジンを用いてデータを移動させることにより
、ＰＥを、ＡＬＵ演算を実施できるよう自由にすると、より効率的である。
【００８８】
比較的長距離のブロックの移動に関して、いくつかのＭＰＳの実施形態は、ＰＥを関与
させずにＤＭＲ間でメモリ‐メモリ間伝送を行うための手段を提供できる。ＰＥは、近隣
のＤＭＲのＤＭＲタイプポートに、このようなポートと関連する特別なＳＭアドレスによ
って、間接的にアクセスできる。これにより、ＰＥは、メッセージを送信するための新規
の経路を生成して、後にこの経路をティアダウンし、あるいはメッセージを受信してよい
。ＰＥはまた、伝送されるデータのブロックを近隣のＤＭＲのＳＭバッファ内に保存して
よく、続いてこの近隣のＤＭＲに、ＤＭＡの動作を、上記動作と関連する特別なＳＭアド
レスによって開始させるよう指示してよい。これによりＰＥは、近隣のＤＭＲがデータの
ＤＭＡ伝送を調整している間に他のタスクを進めることができるようになる。
【００８９】
ＭＰＳの様々な実施形態は、有用なアルゴリズムを実行するための有利な環境を提供で
きる。（例えば画像データを分析するための）関心対象となるアルゴリズムは、ＡＬＵの
フロー図へと分解できる。各フロー図はＭＰＳアレイ上にツリー、格子又は多数のフィー
ドバック／フィードフォワード経路を含むいずれの任意のネットワークとしてマッピング
できる。１つのＡＬＵの有限精度は、複数のＰＥ及びＤＭＲを組み合わせることによって
多数の語の正確な結果を得られるように拡張されてよい。フロー図をＭＰＳにマッピング
する際、ノード間の距離に比例するＰＥ／ＤＭＲノード間の通信遅延は上昇し得る。また
、通信キューが大きい場合又は再構成が頻繁に行われる場合、マッピングは各ノードにお
いてより多くのメモリを必要とし得る。これらの因子は、通信遅延、キュー及び再構成を
考慮に入れることができる綿密なプログラミングによって補償できる。
【００９０】
シストリックアルゴリズムは、ＭＰＳの様々な実施形態に対して特に効率的にマッピン
グを行うことができるアルゴリズムのクラスを表す。シストリックアルゴリズムは、行列
演算、画像処理、信号処理における幅広い応用のために開発された。シストリックアルゴ
リズムでは、多数のプロセッサが同期して協働し、困難な計算を実施できる。理想的なア
ルゴリズム実装形態では、各プロセッサは、アルゴリズムが必要とされる限り、同一の演
算（又は複数の演算の短いループ）を何度も何度も実施でき、データは、データ語のバラ
ンスの取れた生成及び消費を伴って、近隣の接続によって、プロセッサのネットワークを
通って流れることができる。生成される各中間結果データ語が後続の計算によって即座に
消費される場合、必要なメモリの量を最小化できる。シストリックアルゴリズムの利点は
、合理化されたプロセッサを使用でき、メモリ要件を最小化でき、標準的な低コストのＶ
ＬＳＩ技術を使用して高い算術演算速度を達成できる能力を含んでよい。
【００９１】
ＭＰＳのある実施形態は、１つのチップ及びＭＩＭＤアーキテクチャ全体につき多数の
プロセッサを有してよく、上記ＭＩＭＤアーキテクチャは、ＳＩＭＤシステム及び分散型
ＭＩＭＤシステムといった他のクラスのシステムの演算をエミュレートするよう構成され
てよい。いくつかの実施形態では、ＭＰＳはチップの異なる領域で異なるアルゴリズムを
同時に実行できる。またいくつかの実施形態では、電力を節約するために、プログラマは
、少なくともいくつかのＰＥ及びＤＭＲへのクロックを選択的に有効化及び無効化できる
。従って、使用されていないＰＥ及びＤＭＲを無効化できる。
【００９２】
ＰＥ／ＤＭＲファブリック
図５は、ＭＰＳファブリックの一実施形態を示す更に詳細な図である。図５では、各Ｐ
Ｅは４つのＤＭＲに取り囲まれ、これを用いて各ＰＥはメモリ要求及びメッセージを通信
できる。各ＤＭＲは、ファブリックの縁部に近い場所を除いて、４つの他のＤＭＲに取り
囲まれ、上記縁部では各ＤＭＲはチップＩ／Ｏポートに隣接してよい。各ＤＭＲは近隣の
ＤＭＲ又はチップＩ／Ｏポートと通信して、通信経路をセットアップし、上記通信経路上
でメッセージを送受信できる。
【００９３】
ＭＰＳの演算
図６は、図５に示すアーキテクチャ例に従って、９×９のＤＭＲ（円）のアレイと共に
均一に散在する８×８のＰＥ（正方形）のアレイからなる、例示的なＭＰＳを示す。プロ
グラムは、ＰＥに割り当てられるタスクへとコンパイルできる。第１の例示的なプログラ
ムは、タスクＩＤの＝６２でコンパイルされており、アレイの左上隅の特定のＰＥに割り
当てられている。変数ｕ、ｖ、ｗは、プログラムソースコード中の宣言された通信変数で
あり、隣接するＤＭＲの特定のメモリアドレスに割り当てられる。ｕ、ｖはＩ／Ｏポート
のためのバッファであり、ｗは、関連するＤＭＲとのオンチップネットワーク通信のため
のバッファである。第２の例示的なプログラムは、タスクＩＤ＝７１でコンパイルされて
おり、アレイの内部の特定のＰＥに割り当てられている。変数ｘは宣言された通信変数で
あり、図示されているＤＭＲに割り当てられている。変数ｘに関連する通信経路は、ｘが
割り当てられたＤＭＲから、他のＤＭＲを通って、最上行のＩ／Ｏポートへと続く。図示
したように、これら２つの例示的なプログラムは互いに通信しないが、これらは、タスク
７１に別の通信変数を追加し、タスク７１のＤＭＲと、タスク６２に隣接するＤＭＲの変
数ｗとの間に経路を追加することによって、容易に通信させることができる。
【００９４】
動的に構成可能なプロセッサ
図７は、動的に構成できる処理要素（ＰＥ）の例を示すブロック図である。ＰＥ３００
は、図３〜６に示す動的に構成可能なプロセッサ（ＤＣＰ）を説明するものであってよい
。ＰＥ３００は、その命令メモリを再プログラムする方法を有しているため、動的に構成
可能である。図７ではこれは、シリアルバスインタフェースからのロード経路を通して行
われる。シリアルバスは、全てのＤＭＲ及びＰＥメモリをバスコントローラと接続する、
２次相互接続ネットワークであってよく、バスコントローラは１つ又は複数のＰＥによっ
て及びチップＩ／Ｏポートによってアクセスできる。ＰＥを再プログラムするためには、
ＰＥを待機状態にしてよく、続いて命令メモリを新規のプログラムで上書きし、プログラ
ムカウンタを設定し、その後ＰＥを待機状態から解放して上記新規のプログラムの実行を
開始させてよい。ＰＥ３００は、少なくとも１つの算術論理ユニット（ＡＬＵ）３２０を
制御するために連結された命令処理ユニット（ＩＰＵ）３１０を含む。ＰＥ３００はまた
、複数の多重化装置（本出願ではｍｕｘとも呼ばれる）に連結された複数のデータ入力ポ
ート３０１も含み、上記多重化装置は、ＡＬＵ３２０のための少なくとも第１及び第２の
オペランド入力を選択するために連結される。ＰＥ３００は更に、ＡＬＵ３２０から結果
データを受信するためにｍｕｘを介して連結された複数のデータ出力ポート３０２と、命
令処理ユニット３１０からアドレスデータを受信するために連結された複数のアドレスポ
ート３０３とを含む。
【００９５】
アドレスポート３０３は、近隣のＤＭＲのメモリに対する読み書きを行うためにアドレ
スを搬送するよう構成されてよい。データ入力ポート３０１及びデータ出力ポート３０２
は、近隣のＤＭＲから及び近隣のＤＭＲへデータを搬送するよう構成されてよい。図示さ
れているＰＥ３００の実施形態では、データ入力ポート３０１、データ出力ポート３０２
、アドレスポート３０３はそれぞれ４つのポートを含み、これは図５の例示的なアーキテ
クチャと一致する。
【００９６】
図７の例では、米国特許第７４１５５９４号に記載されているような従来技術において
典型的である、単一のＡＬＵ３２０が示されている。しかしながら、１つのＰＥにつき更
に多くのＡＬＵが存在し、これによってＰＥが遥かに高い処理スループットのための潜在
能力を有する、代替実施形態が考えられる。その例を本明細書中のこれ以降において示し
、議論する。
【００９７】
ＰＥ３００は、データ語に対する算術／論理ユニット演算を実施するよう構成され、選
択される演算は、ＩＰＵ３１０が処理している現在の命令に依存する。柔軟なプログラミ
ングをサポートするために、ＩＰＵ３１０は、複数のアドレス指定可能な位置を含む少な
くとも１つの命令メモリ３１２、命令復号器３１４、アドレス生成器３１６を含んでよく
、これらはそれぞれ様々な相互接続機構を介して相互接続される。他の実施形態では、Ｉ
ＰＵ３１０は２つ以上の命令メモリを含んでよいこと、又は追加の機能性を含んでよいこ
とが考えられる。他の実施形態では更に、ＩＰＵ３１０に示した機能性を異なるタイプの
複数のユニットに分割してよいこと、又は単一の機能ユニットで実装してよいことも考え
られる。
【００９８】
ＩＰＵ３１０は、データ入力ポート３０１に連結されたプログラムロード経路を介して
、命令メモリ３１２内での保存のためにプログラムデータを受信するよう構成されてよい
。命令メモリ３１２はまた、グローバルシリアルバス（図示せず）を介して読み書きして
よい。命令復号器３１４による特定の命令の復号化に応じて、ＩＰＵ３１０は、データ入
力ポート３０１及びデータ出力ポート３０２に連結された様々なｍｕｘを制御して、近隣
のＤＭＲへ及び近隣のＤＭＲからデータを案内するよう構成されてよい。ＩＰＵ３１０は
更に、アドレス生成器３１６が生成したアドレスを、アドレスポート３０３を介して近隣
のＤＭＲへと搬送することによって、例えばそこに位置するＲＡＭに対して読み出し又は
書き込みを行うよう構成されてよい。アドレス生成器３１６はまた、命令メモリ３１２か
らフェッチされ、命令復号器３１４によって復号化される、次の命令アドレスを生成する
よう構成された、プログラムカウンタレジスタ（図示せず）も含んでよい。
【００９９】
一実施形態では、ＰＥ３００はデータレジスタファイル、データキャッシュ、又はデー
タオペランド若しくは結果データ用のいずれのローカルストレージを含まなくてよい。こ
のような実施形態では、ＰＥ３００は、データオペランドの読み出し及び結果データの書
き込みを行うことができる迅速なストレージ媒体としてＰＥ３００が直接接続されている
ＤＭＲに含まれるメモリを利用するよう構成されてよい。いくつかの実施形態では、所定
のＰＥは異なる近隣のＤＭＲから同時に又は異なる時点に異なるデータを得ることができ
る。以下に更に詳細に説明するように、いくつかの実施形態では、所定のＰＥは、上記所
定のＰＥが直接接続されていないＤＭＲ内のデータの読み出し及び書き込みを、このよう
な遠隔ＤＭＲから上記所定のＰＥの近隣のＤＭＲへの経路を確立することによって行うよ
う構成されてもよい。
【０１００】
ＰＥ３００が実装する命令は、算術演算及び論理演算並びにメタ命令をサポートしてよ
い。ＰＥ命令は、２つのオペランド及び１つの結果に関するメモリをアドレス指定するた
めに十分なビット長を有してよく、これにより１クロックサイクルでこれらの値の読み出
し及び書き込みを行うことができる。
【０１０１】
他の実施形態は、追加の命令又は異なる命令のセットを実装してよいことに留意された
い。いくつかの実施形態では、１つ又は複数のデータオペランドを必要とする所定の命令
の実行中、所定のＰＥは、近隣のＤＭＲメモリに直接アクセスして上記必要なオペランド
にアクセスするよう構成されてよい。
【０１０２】
ＰＥ３００はメタ命令を実行するよう構成されてよい。本出願で使用される場合、メタ
命令は、命令メモリ３１２等のＰＥ命令メモリに保存された命令に対する演算を実施でき
る命令を指す。基本的なメタ命令は、近隣のＤＭＲのＲＡＭから命令メモリ３１２をロー
ドすること（即ちオーバレイをロードすること）であってよい。ＤＭＲメモリから命令メ
モリをロードすることにより、データと命令との間のメモリの分割をソフトウェアプログ
ラミングによって決定できる。従ってアプリケーションのプログラマは、自身のソフトウ
ェアを、利用可能なメモリの最良の利用に関して最適化できる。いくつかの実施形態では
、ＰＥ３００は、ＩＰＵ命令メモリを修正できる他のメタ命令を含んでよく、又は例えば
試験、エラー分析及び／若しくはエラー修復のためにＤＭＲメモリに命令メモリをセーブ
してよい。
【０１０３】
ＡＬＵ３２０は、特定のＰＥ３００の実施形態でサポートされる命令によって定義され
る演算を含む、少なくとも固定小数点数系に関する演算を実施するよう構成されてよい。
例えば一実施形態では、ＡＬＵ３２０は固定小数点型加算、減算、乗算、積和、論理及び
シフト演算を実施するよう構成されてよい。いくつかの実施形態では、ＡＬＵ３２０は、
拡張精度演算をサポートするために、過去の計算から得られたキャリービットを保持する
よう構成されてよい。他の実施形態では、ＡＬＵ３２０は、浮動小数点型演算、又は特定
のアルゴリズムを実装するために選択された特定目的のための演算を実施するよう構成さ
れてよい。
【０１０４】
図８‐並列実行のためのソフトウェアを開発するための方法のフローチャート
図８は、一実施形態による、マルチプロセッサシステム上での並列実行を標的としたソ
フトウェアを開発するための方法を示す。図５に示す方法は、とりわけここで説明するコ
ンピュータシステム又はデバイスのいずれと併用してよい。様々な実施形態では、図示さ
れている方法の要素のうちのいくつかは同時に、若しくは図示されているものとは異なる
順序で実施されてよく、又は省略されてよい。所望に応じて追加の方法の要素を実施して
もよい。図示したように、この方法は以下のように動作し得る。
【０１０５】
ｘ８０２に示すように、例示的な一実施形態では、例えばマルチプロセッサシステム上
での展開及び実行のために標的化されたアプリケーションの、所望のシステムの複数のビ
ューを指定する入力を受信してよい。各ビューは、システムの各態様を提示又は指定して
よく、またこれらビューは総体として、効率的な並列実行のためにマルチプロセッサシス
テムが展開できる実行可能なプログラムを生成するためにコンパイラ（又は他のソフトウ
ェアツール）が使用できる情報を提供してよい。
【０１０６】
この入力は、様々な形態のいずれで、また様々なツールのいずれを介して受信されてよ
い。例えばいくつかの実施形態では、入力はユーザによって提供されてよく、即ちユーザ
入力であってよい。他の実施形態では、入力は所望に応じて別のシステム又はプロセス、
ストレージ媒体等から受信されてよい。更に入力はローカルに提供されてよく、又はロー
カルエリアネットワーク（ＬＡＮ）若しくはインターネット等の広域ネットワーク（ＷＡ
Ｎ）を介して受信されてよい。例示的な一実施形態では、ユーザはスプレッドシート中で
ビューを指定してよい。別の例示的実施形態では、ユーザはウィザード、即ちグラフィカ
ルユーザインタフェース（ＧＵＩ）への入力を行ってよく、これは指定プロセスを通して
、例えばプロンプト、有用な提案等によってユーザをリードする。更なる実施形態では、
ユーザは入力／指定プロセスを管理するためにチェックリストを使用してよく、指定され
る各アイテム、例えばビュー、サブビュー等がチェックリストに挙げられており、チェッ
クリストは各チェックリストアイテムが指定されているか（されていないか）を示す。別
の例示的実施形態では、１つ又は複数のテンプレート又はフォームを提供してよく、ユー
ザはビューを指定する情報で上記テンプレート又はフォームを埋めてよい。
【０１０７】
各ビューは、アプリケーションの動作又は実行の各態様を含むか又はその表現となって
よい。多数のビューはメモリビュー、通信ビュー、制御ビュー、処理ビューを含んでよい
。他のビューも所望に応じて定義又は指定してよい。一実施形態では、各ビューは、ビュ
ーの更に詳細な属性を指定する複数のサブビュー（又は「ファセット」）を含むか又は指
定してよい。例えば各ビューは、サイズ、挙動及びアクセシビリティサブビュー（又はフ
ァセット）を含んでよく、各サブビューは、各サブビューがその一部となっているビュー
に関連する特定の意味を有してよい。
【０１０８】
従って例えば、メモリビューは：アプリケーションによる使用に必要な又は利用可能な
メモリのサイズ（又は量）、即ちデータを処理するためにアプリケーションが使用するメ
モリ構造サイズ；メモリの挙動、即ちメモリ構造が所定のタイミングで挙動する様式；並
びにメモリのアクセシビリティ、即ち例えばアプリケーション及び／又はシステムによる
メモリ構造のアクセシビリティを指定してよい。
【０１０９】
同様に、入力は：通信ビュー（通信ビューの各サブビュー、例えば通信サイズ、挙動、
アクセシビリティを定義することを含む）；制御ビュー（制御サイズ、挙動、アクセシビ
リティを含む）；並びに処理ビュー（処理サイズ、挙動、アクセシビリティを含む）を定
義又は指定してよい。
【０１１０】
いくつかの実施形態では、ビュー又はサブビューのうちのいくつかは、他のサブビュー
又はビューの指定によって、例えば同一の又は異なるビューのサブビューによって、自動
的に定義又は指定され得ることに留意されたい。従って例えば、メモリサイズ、挙動及び
アクセシビリティが指定されると、通信挙動が自動的に指定され得る。別の様式で考える
と、いくつかの実施形態では、ビューは、方程式の数が変数の数を超える線形方程式の優
決定系と同様に、「過剰に指定される」か又は「過剰に決定される」場合がある。
【０１１１】
本出願で使用される特定の用語又は標識は単なる例示であること、並びに所望に応じて
本出願で開示される新規の構成要素、情報及びプロセスに対していずれの名称を使用して
よいことに留意されたい。例えば所望に応じて、ビュー又は態様はモデル等と呼ばれる場
合もあり、本出願で開示されるサブビューはサブモデル、ファセット、プロパティ等と呼
ばれる場合もある。
【０１１２】
システムのビューが指定又は定義されると、これらのビューを表す情報は、ｘ８０４に
示すように、アプリケーションのソースコード内に含まれ得る。この包含は、広範な方法
のうちのいずれにおいて実施され得る。例えばいくつかの実施形態では、情報はアプリケ
ーションの１つ又は複数のヘッダファイルに含まれ得る。他の実施形態では、情報は、ア
プリケーションプログラム要素又は構成要素の中でとりわけ、１つ又は複数の動的リンク
ライブラリ（ＤＬＬ）又はマクロ定義に含まれ得る。より一般には、ビューを表す情報は
、所望に応じていずれの様式及びいずれの形態でアプリケーションソースコードに組み込
まれてよい。
【０１１３】
ｘ８０６では、ソースコードは例えば、コンパイラ又は他のツールによって処理でき、
これはシステムに関して指定又は定義された複数のビューを表す情報を分析することを含
む。例えば一実施形態では、コンパイラは、アプリケーションソースコード内の複数のビ
ューを表す情報を認識するよう構成してよく、またこの情報を抽出及び分析してよい。他
の実施形態では、コンパイラは情報を原位置で分析してよい。
【０１１４】
ｘ８０８に示すように、実行可能なプログラムは上記処理に基づいて生成してよく、こ
こで上記実行可能なプログラムは、効率的な並列実行のためにマルチプロセッサシステム
に展開可能である。換言すると、コンパイラは、指定されたビューの分析を含むｘ８０６
の処理に基づいて、実行可能なプログラムを生成してよい。
【０１１５】
従って、本技術の実施形態は、上述のようなソフトウェア開発への従来技術のアプロー
チの様々な欠点に対処でき、これによってユーザは、システムの動作、例えばマルチプロ
セッサシステム上でのアプリケーションの動作に関する様々な要件又は制約を指定でき、
これら指定された要件又は制約をコンパイラ（又は他のツール）が使用して、システム上
で効率的に実行できる実行可能なコードを生成してよい。
【０１１６】
以下に、上述の技術の様々な例示的実施形態を提示する。
【０１１７】
１．マルチプロセッサシステム内での並列実行のためのアプリケーションソフトウェア
を開発するための方法であって、上記方法は、コンピュータが：第１の入力に応答して所
望のシステムの複数のビューを指定するステップ（ここで上記複数のビューは：メモリビ
ュー；通信ビュー；制御ビュー；及び処理ビューを含む）；アプリケーションプログラム
のソースコードに上記複数のビューを表す情報を含めるステップ；アプリケーションプロ
グラムのソースコードを処理するステップ（上記複数のビューを表す情報を分析するステ
ップを含む）；並びに上記処理ステップに基づいて、実行可能なプログラムを生成するス
テップ（上記実行可能なプログラムは並列実行のためにマルチプロセッサシステムに展開
可能である）を実施することを含む、方法。
【０１１８】
２．複数のビューを指定する上記ステップは、各ビューに関して：サイズ；挙動；及び
アクセシビリティを指定するステップを含む、実施形態１の方法。
【０１１９】
３．上記入力は：ウィザード；グラフィカルユーザインタフェース；スプレッドシート
；又はデータファイルのうちの少なくとも１つが受信するユーザ入力を含む、実施形態１
の方法。
【０１２０】
４．ソースコードに上記複数のビューを表す情報を含める上記ステップは：アプリケー
ションプログラムの１つ若しくは複数のヘッダファイル；アプリケーションプログラムに
関するマクロ定義；又は１つ若しくは複数の動的リンクライブラリ（ＤＬＬ）のうちの１
つ又は複数に上記情報を含めるステップを含む、実施形態１の方法。
【０１２１】
５．上記処理ステップ及び上記生成ステップはコンパイラによって実施される、実施形
態１の方法。
【０１２２】
６．上記マルチプロセッサシステムはＨｙｐｅｒＸアーキテクチャを備える、実施形態
１の方法。
【０１２３】
更なる実施形態
以下に、上述の技術の更なる例示的実施形態の説明を提示するが、開示される実施形態
は単なる例示であり、本技術の実装をいずれの特定の形態、機能又は外観に限定すること
を意図したものではないことに留意されたい。特定の（非限定的な）使用のケースとして
２つの例示的実施形態：撮像フィルタ及び有限インパルス応答（ＦＩＲ）フィルタを提示
する。
【０１２４】
定義されたシステムのビュー及びプロセス
あるシステムにおいてデータは、上記システムがリアルタイム型であるかそうでないか
に関わらず、無線受信機、画像センサ又は他の入力収集デバイスのいずれかからの（実際
の又は概念上の）ストリームとして受信されることが多い。受信されるデータは、アルゴ
リズム及びその代表データ構造に対して自然である方法で処理されることが望ましい。こ
れは、処理のために、サンプル形態、ブロック形態又はハイブリッド形態のデータ構造を
取り扱う能力を必要とし得る。これはまた、処理システムの通信及びメモリアーキテクチ
ャが、様々なアルゴリズム及びデータ構造システムをサポートできるよう、リアルタイム
に動的であり、かつ適合可能であることを必要とし得る。
【０１２５】
例示的な使用のケース：撮像フィルタ
一例として、等式１によって特徴付けられる例示的な撮像フィルタを考える。
【０１２６】
【数１】
2019145172.tif 000003
【０１２７】
ここでｔは時間であり、ｒは行インデックスであり、ｃは列インデックスであり、ｘ［
ｒ，ｃ，ｔ］は入力ピクセルであり、ｈ［ｒ，ｃ，ｔ］はフィルタ係数であり、ｙ［ｒ，
ｃ，ｔ］は出力ピクセルである。
【０１２８】
合計は２Ｍ＋１行及び２Ｎ＋１列に亘っており、従ってフィルタの寸法的なメモリサイ
ズは（２Ｍ＋１）×（２Ｎ＋１）であり、最小のレイテンシが望ましい。
【０１２９】
撮像フィルタシステムを用いた、図８の方法の記述
例示的な撮像フィルタリングプロセスを、図９Ａに図式的に示す。このアプローチでは
、ピクセル（ピクセルデータ）のデータストリームは通常、行毎に受信される。フィルタ
及び／又は境界条件のデータ要件を満たすために十分な行数のデータが受信されると、図
示されているように、データを水平に横断するように２次元フィルタを走らせて、フィル
タリングされた画像を生成してよい。図９Ａのアプローチは図１０においてブロック図の
形態で表されており、この図１０は、単一のプロセスを有する画像フィルタリングのブロ
ック図を示す。
【０１３０】
画像データをより迅速に処理するために、一般的なスキームは、画像を垂直方向に分割
するものであり、各垂直セグメントのデータは、ピクセル毎、行毎に（処理リソースに）
受信されて、図９Ｂに示すように並列にフィルタリングが実施される。図９Ｂの並列アプ
ローチは図１１においてブロック図の形態で表されており、この図１１は、複数のプロセ
スを有する画像フィルタリングのブロック図を示す。
【０１３１】
ＭＰＩをサポートするＡＮＳＩ  Ｃ言語ベースのソフトウェアプログラミングモデルに
おいてスレッドを処理するための本技術の実施形態を実装する例示的なプログラム（フィ
ルタカーネルのコード例）は、以下のように書くことができる：
//* filter_kernel.c
//* example hx3xxx pseudo code for 2D filter
#include <mpx.h>
#include <math.h>
#include "filter_system.h"
// initialize variables
int 2d_lin_buffer [(ROW+3)*COL];
// initialize 2D circular line buffer on 2d_buffer
void init_2D_circ_lin_buf ( .... )
{ .... }
// update 2D circular line address on 2d_buffer
void update_2D_circ_lin_address ( .... )
{ .... }
// 2D filter function with calculations written through
// line based pointers for efficiency. This is unnatural.
// Performs function while receiving next line of data and
// sending out previously calculated results.
void 2d_filter ( .... )
{ .... }
mpx_cell filter_kernel ( .... )
{ // begin mpi_cell..
// initialize
init 2D circ lin buf ( .... );
while (1)
{ // begin while
MPX_Recv( .... ); // non-blocking line receive
2d filter( ....); // perform filter across line of data
MPX_Send( .... ); // non-blocking line send of results
update_2D_circ_lin_address ( .... );
} // end while
} // end mpx_cell 
コード部分Ａ：ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃ‐フィルタカーネルのコード例
【０１３２】
スレッドを処理する「ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃ」を構成するシステムは、以下
のように書くことができる（フィルタシステムのコード例）：
//* filter_system.c
//* example hx3xxx pseudo code for 2D filter system
#include <mpx.h>
#include <math.h>
#include "filter_system.h"
mpx_cell filter_system ( .... )
{ // begin mpx_cell..
// system defined through MPX_PARALLEL
if (MPX_RANK == MPX_PARALLEL)
{ // begin MPX_PARALLEL
distribution_and_collection: di_co_sys( .... );
filter_thread_00: filter_kernel ( .... );
filter_thread_01: filter_kernel ( .... );
filter_thread_02: filter_kernel ( .... );
....
} // end MPX_PARALLEL
} // end mpx_cell
コード部分Ｂ：ｆｉｌｔｅｒ＿ｓｙｓｔｅｍ．ｃ‐フィルタシステムのコード例
【０１３３】
「ｖｏｉｄ  ２ｄ＿ｆｉｌｔｅｒ（  ．．．．  ）」関数は以下の例のように書くこと
ができる：
// apply filter across line of data
for( col = begin; ... )
{ // begin col = begin..
result [ col ] = 0;
for ( i = 0; ... )
{ // begin i = 0..
for ( j = 0; ... )
{ // begin j = 0..
// operations
result[ col ] += (long)( filter[ i ] [ j ] ...
* data[ i ] [ address_line[ i ] - offset + j ] );
} // end for j = 0..
} // end for i = 0..
} // end for col = begin..
コード部分Ｃ：Ｍ×Ｎフィルタとして実装される２ｄ＿ｆｉｌｔｅｒ関数
// apply Laplacian filter across line of data
for ( col = begin; ... )
{ // begin for begin = 0..
// operations..
temp = in_data[ address_line[ center ] + col - Lap ] ...
+ in_data[ address_line[ center ] + col + Lap ];
temp += (long)( in_data[ address_line[ center - Lap ] + col ] ...
+ in_data[ address_line[ center + Lap ] + col ] );
temp -= (long)( 4 * in_data[ address_line[ center ] + col ] );
result_data[ col ] = abs(temp);
} // end for col = begin..
コード部分Ｄ：ラプラシアンフィルタとして実装される２ｄ＿ｆｉｌｔｅｒ関数
// apply Laplacian filter across line of data
address_center = address_line[ center ];
address_n_Lap = address_line[ center - Lap ];
address_p_Lap = address_line[ center + Lap ];
for ( col = begin; ... )
{ // begin for begin = 0..
// operations ..
temp = in_data[ address_center + col - Lap ] ...
+ in_data[ address_center + col + Lap ];
temp += (long)( in_data[ address_n_Lap + col ] ...
+ in_data[ address_p_Lap + col ] );
temp -= (long)( 4 * in_data[ address_center + col ] );
result_data[ col ] = abs(temp);
} // end for col = begin..
コード部分Ｅ：ラプラシアンフィルタとして実装される、簡略化されたｖｏｉｄ  ２ｄ＿
ｆｉｌｔｅｒ関数
【０１３４】
ここで提示したコード部分／プログラムは単なる例示であり、いずれの特定のプログラ
ム言語に実施形態を限定することを意図したものではないことに留意されたい。
【０１３５】
論理的には、ＡＮＳＩ  Ｃソフトウェアプログラミングモデルを有するＭＰＩは、雑多
なメモリ及び適合可能な通信スキームの全要件をサポートできる。実行モデルは、ソフト
ウェアプログラミングモデルの要件を満たす能力を提供できる。更にソフトウェアプログ
ラミングモデルは、可変リアルタイムパフォーマンスを標的とすることができるスケーラ
ブルなコードをサポートできる。
【０１３６】
結果の例は、図１２に示すような、例えば（ＣｏｈｅｒｅｎｔＬｏｇｉｘ，Ｉｎｃｏｒ
ｐｏｒａｔｅｄから提供される）例示的なｈｘ３ＸＸＸプロセッサ等のメモリ‐ネットワ
ークプロセッサ上で実現される。より具体的には、図１２は、ｈｘ３１００プロセッサ上
で、Ｃコードの行を変更せず、３０ｆｐｓ（左の画像）、続いて６０ｆｐｓ（右の画像）
で示されている、例示的な４Ｋビデオ２Ｄフィルタシステムのリソースのレイアウトを示
す。ここでソフトウェアスレッドの数は増大しており、追加のハードウェアスレッドを使
用してフレームレートスループットを上昇させることができる。
【０１３７】
上述のように、現行のアプローチの１つの問題は、ソフトウェアプログラミングモデル
が標的ハードウェアの特徴の外挿をサポートする場合、システムの効率的な記述ができな
いという点である。システムを適切に記述するためには、システムの挙動及びインタラク
ティブ性の全ての重要な態様を、プログラミングモデルの制御、通信、メモリ及び処理モ
デルそれぞれの中で何らかの方法でキャプチャしなければならない。最後の２つ、即ちメ
モリ及び処理モデルは、通常はアドレス指定されず、実行モデルから暗黙的に割り当てら
れると想定される。
【０１３８】
従って、いずれのシステムを効率的に定義することは、システム全体を効率的に定義す
ることを必要とし得る。この例では、議論の焦点は、通信構造のプロパティ及びメモリプ
ロパティとのインタラクティブ性からシステムを記述し、またシステム要件から処理を記
述することに当てられている。図８の方法を参照して上述したように、これは、メモリ構
造のプロパティ、即ち：通信をサポートするために使用される構造のサイズ；処理をサポ
ートするために使用される構造のサイズ；処理をサポートするための構造の挙動；通信を
サポートするための構造の挙動；処理をサポートするための構造のアクセシビリティ；及
び通信をサポートするための構造のアクセシビリティを定義することを伴い得る。これに
続いて、通信、制御及び処理プロパティを引き出すか又は明確に定義できる。
【０１３９】
上述の撮像フィルタの例に関して、これは以下の様式で実施できる。
【０１４０】
メモリ構造のサイズの定義：
図１１に示すように、この撮像フィルタの例では、システムに関して最も自然なメモリ
構造をサポートするために、循環ラインバッファアドレス指定スキームを生成する必要が
あり得る。メモリ構造は、フィルタのサイズ、即ち現在のデータのフィルタ処理に必要な
行数（このケースでは２Ｍ＋１）と、処理の現在の結果をキャプチャするための更なる行
と、次のデータのラインを同時に受信するための更なる行と、フィルタ処理の過去に計算
された結果を送信するための更なる行とを加算した数によって定義できる。従ってこの例
示的なアプリケーションに関して、メモリ構造のサイズは、積（２Ｍ＋４）＊（２Ｎ；Ｈ
／Ｎv）個のピクセルとして定義又は指定できる。
【０１４１】
メモリ構造の挙動の定義：
構造のサイズに加えて、所定の時点における構造の挙動を明確に定義する必要がある。
この特定のケースでは、メモリの挙動は、過去に受信された処理済みのデータと、利用可
能な、即ち到着済みの新規のデータとに対して定義される。具体的には、この例示的実施
形態では、現在の処理のために使用されることになる、「現在のデータ」として表示でき
るメモリのセクションが存在し、そのサイズは「２Ｍ＋１」行×「２Ｎ＋１」超の列であ
り、また、次のデータのラインを受信するメモリのセクションが存在し、過去に計算され
た結果を保持するメモリのセクションが存在し、最後に、処理から現在の結果を収集する
メモリのセクションが存在する。現在の処理が完了し、過去に計算された結果が送信され
た後、受信されたばかりの次のデータのラインが、今度は現在のデータの第１のラインと
なるように、メモリの挙動を更新できる。そして現在の結果は、送信されるべき過去に計
算された結果となり、現在の結果はその位置を再割り当てされる。従って、これらメモリ
セクションをこのように回転式で使用することにより、メモリ構造の挙動を定義でき、又
は特徴付けることができる。
【０１４２】
メモリ構造のアクセシビリティの定義
各メモリセクションは、定義されたアクセシビリティを有する必要がある。この特定の
例示的なケースでは、現在のデータに関しては、このデータは標準的な２次元アレイの形
態でアクセス可能である必要がある。上述のメモリ構造の挙動に従って、新規のデータの
ラインが到着して新規のデータの第１の行となり、データの最も古い又は最後の行が脱落
する度に、ユーザ／プログラマの視点からのデータの自然な書き込み及びアクセスをサポ
ートするために、物理アドレスへの２次元アクセスを更新してよい。他の３つのメモリの
セクション（上述）は、データ及びフィルタリングの結果の受信並びに結果の送信をサポ
ートする、データの１次元アレイを効果的に実装できる。
【０１４３】
通信プロパティ（サイズ、挙動、アクセシビリティ）の定義
メモリ構造のサイズ、挙動、アクセシビリティが定義されると、通信間又は通信内、制
御、及び処理プロパティを、そのシステム又は別のシステム内のインタラクティブ性に基
づいて引き出すことができ、又は明確に定義できる。この特定のケースでは、システムの
入力プロパティを、メモリ構造のサイズ、挙動、アクセシビリティの定義から引き出すこ
とができる。例えば通信無線機内のインターリーバ及び／又はデインターリーバの場合に
関してといった他のシステムは、より明確な定義が必要となり得る。
【０１４４】
一実施形態では、次のステップは、ソフトウェアプログラミングモデル内でシステムの
プロパティを効果的に表現することであってよい。これを行うには、ＭＰＩ等のＡＰＩを
生成又は拡張してＡＮＳＩ  Ｃをサポートすること、Ｃ＋＋で特定のクラス構造を生成す
ること等を含むがこれらに限定されない、多数の方法が存在する。しかしながら、具体的
な語彙的表現は重要ではない。重要なのは、プログラミングモデルがこれらの（動的な）
システムの定義を認識すること、即ちツールフローがシステムの定義を解釈でき、続いて
システムを標的の実行モデル及び下層のハードウェアアーキテクチャに効果的にマッピン
グできることである。
【０１４５】
例示的なコードであるコード部分Ａ、ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃは、制御モデル
、通信モデル並びに補助メモリ構造及び処理に明らかにアプローチし、またそのように解
釈される必要があり得る。これは、システムを直感的に表現でき、システムを定義でき、
又は効率的にシステムを解釈できるような方法で、制御、通信及びメモリ構造の間で動的
インタラクティブ性を定義できない。
【０１４６】
撮像フィルタの例を用いて続けると、ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃは以下のように
書き換えできる：
//* filter_kernel.c
//* example pseudo code for 2D filter incorporating system
// property defintion
#include <mpx.h>
#include <math.h>
#include "filter_system.h"
// initialize variables
mpx_2d_lin int buffer[(ROW+3)*COL];
// 2D filter function with calculations written naturally as for (i, j)
// and performs function while receiving next line of data and
// sending previously calculated results.
void 2d_filter( .... )
{.... }
mpx_cell filter_kernel ( .... )
{ // begin mpi_cell..
while(1)
{ // begin while
MPX_Recv( .... ); // non-blocking line receive
2d_filter( .... ); //perform filter across line of data
MPX_Send( .... ); // non-blocking line send of results
} // end while
} // end mpx_cell
コード部分Ｆ：ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃ‐一実施形態によるシステムのプロパテ
ィの定義を組み込んだ、フィルタカーネルの更新されたコード例
【０１４７】
理解できるように、上記更新されたコード例であるコード部分Ｆにおいて、プログラム
文「ｍｐｘ＿２ｄ＿ｌｉｎ  ｉｎｔ  ｂｕｆｆｅｒ［（ＲＯＷ＋３）＊ＣＯＬ］；」は変
数を宣言しており、具体的には、この時点ではプログラミングモデルによってサポートさ
れている、上述のサイズ、挙動、アクセシビリティプロパティを備えるメモリ構造を宣言
している。
【０１４８】
従ってここで、コード部分Ａの「ｖｏｉｄ  ２ｄ＿ｆｉｌｔｅｒ（  ．．．．  ）」関
数を自然な形態で書くことができ、以下の２つの例において提示されるように、その処理
において高い演算効率を達成できる：
// perform filter across line of data
for( col = begin; ... )
{ // begin col = begin..
result data [ col ] = 0;
for ( i = 0 ; ... )
{ // begin i = 0..
for ( j = 0 ; ... )
{ // begin j = 0..
// operations
result_data[ col ] += (long)( filter [ i ] [ j ]...
* in_data[ i ][ col - offset + j ] );
} // end for j = 0..
} // end for i = 0..
} // end for col = begin..
コード部分Ｇ：Ｍ×Ｎフィルタとして実装される２ｄ＿ｆｉｌｔｅｒ関数の、更新された
コード例
// apply Laplacian filter across line of data
for ( col = begin; ... )
{ // begin for begin = 0..
// operations ..
result_data[ col ] = abs ( (4 * in_data [ center ] [ col ] )...
- in_data[ center ] [ col - Lap ]...
- in_data[ center ] [ col + Lap ]...
- in_data[ center - Lap ] [ col ] ...
- in_data[ center + Lap ] [ col ] );
} // end for col = begin..
コード部分Ｈ：ラプラシアンフィルタとして実装されるｖｏｉｄ  ２ｄ＿ｆｉｌｔｅｒ関
数の、更新されたコード例
【０１４９】
続いて、プログラム文「ＭＰＸ＿Ｒｅｃｖ（  ．．．．  ）；  ／／  ｎｏｎ-ｂｌｏ
ｃｋｉｎｇ  ｌｉｎｅ  ｒｅｃｅｉｖｅ」は、挙動及びアクセシビリティのプロパティを
自動的に更新する単回更新を提供できる。これは、受信されるべき次のデータのライン、
処理するための現在のデータ、収集されるべき現在の結果をセットアップする。
【０１５０】
ツールフロー内において、コンパイラは、システムの挙動を解釈するよう、及び定義さ
れたシステムの機能性をサポートするために、ハードウェアリソースをより効果的にマッ
ピングするよう、設計されてよい。
【０１５１】
上述の撮像フィルタの例は、主としてメモリ定義（メモリビュー）の視点から記述され
ている。これを限定として解釈するべきではない。サイズ、挙動、アクセシビリティの観
点から記述したシステムのメモリモデルに加えて、又はこれの代わりに、制御、通信、処
理ビュー（及びサブビュー）を同様に使用して、システムを記述又は定義してよい。
【０１５２】
従って、ソフトウェアプログラミングモデル内において、効果的なシステムの記述をサ
ポートするために、全てのモデルは、処理、メモリ、通信及び制御並びにこれらの間の及
び／又はこれらの内部でのアクティビティのサイズ、挙動、アクセシビリティを記述する
か又は暗黙的に解釈するプロセスをサポートする必要があり得る。
【０１５３】
例示的な使用のケース：有限インパルス応答フィルタ
別の例として、等式２によって特徴付けられる例示的な有限インパルス応答（ＦＩＲ）
フィルタを考える。
【０１５４】
【数２】
2019145172.tif 000004
【０１５５】
ここでｔは時間であり、ｃiは係数であり、ｘ［ｔ］は入力サンプルであり、Ｎはフィ
ルタ長であり、ｙ［ｔ］は出力サンプルである。
【０１５６】
ＦＩＲフィルタを使用した、図８の方法の記述
このタイプのシステム（ＦＩＲフィルタ）では、データストリーム入力は典型的にはサ
ンプル毎に、即ち１度に１サンプルずつ受信される。ＦＩＲフィルタはその長さよって特
徴付けられ、これは、ＦＩＲフィルタが出力サンプルを生成するために使用する入力サン
プルの数に等しい。ＦＩＲフィルタのデータ要件（例えば長さ）を満たすためにデータの
十分なサンプルを受信すると、上記データに対してＦＩＲフィルタの計算が実施され、フ
ィルタリングされたデータサンプル出力が生成される。データをより迅速に処理するため
に、一般的なスキームは、フィルタ処理を複数の段階及び／又はパイプライン化されたセ
グメントに分割することである。ブロック図形態の単一のＦＩＲフィルタプロセスを図１
３に示す。ブロック図形態の、段階及びパイプライン並列処理を示す多数のプロセスを用
いたＦＩＲフィルタを、図１４に示す。
【０１５７】
ＭＰＩをサポートするＡＮＳＩ  Ｃ言語ベースのソフトウェアプログラミングモデルを
用いて、図１２、１３に示すスレッドプロセスを記述するためのプログラムは、以下のよ
うに記述できる：
//* fir_filter_kernel.c
//* example hx3xxx pseudo code for FIR filter
#include <mpx.h>
#include <math.h>
#include "fir_filter_system.h"
// initialize variables
int ld_sample_buffer[ length_fir_filter + 3 ];
// initialize 1D circular sample buffer on 1d_sample_buffer void init_1D_circ_sa
m_buf( .... )
{ .... }
// update 1D circular sample address on 1d_sample_buffer void update_1D_circ_sam
_address( .... )
{ .... }
// FIR filter function with calculations written with sample based pointers
// for efficiency. This is unnatural. Performs function while receiving
// next sample of data and sending out previously calculated sample result.
void fir filter( .... )
{.... }
mpx_cell fir_filter_kernel ( .... )
{ // begin mpi_cell..
// initialize
init_1D_circ_sam_buf( .... );
while (1)
{ // begin while
MPX_Recv( .... ); // non-blocking sample receive
fir_filter( .... ); //perform filter on current data
MPX_Send ( .... ); // non-blocking sample send of results
update_1D_circ_sam_address( .... );
} // end while
} // end mpx_cell
コード部分Ｉ：ｆｉｒ＿ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃ‐ｆｉｒフィルタカーネルのコ
ード例
【０１５８】
従って、コード部分Ｊのシステムは、「ｆｉｒ＿ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃ」処
理スレッドで構成されるＦＩＲフィルタのパイプライン相及びアルゴリズム相両方の並列
処理を示す図１４の構文的表現を表し、以下のように書くことができる：
//* fir_filter_system.c
//* example hx3xxx pseudo code for FIR filter system
#include <mpx.h>
#include <math.h>
#include "fir_filter_system. h"
mpx_cell fir_filter_system ( .... )
{ // begin mpx_cell..
// system defined through MPX_PARALLEL
If (MPX_RANK == MPX_PARALLEL)
{ // begin MPX_PARALLEL
distribution_and_collection: di_co_sys( .... );
fir_filter_phasesegment_00: fir_filter_kernel( .... );
fir_filter_phasesegment_01: fir_filter_kernel( .... );
fir_filter_phasesegment_10: fir_filter_kernel( ....);
....
} // end MPX_PARALLEL
} // end mpx_cell
コード部分Ｊ：ｆｉｒ＿ｆｉｌｔｅｒ＿ｓｙｓｔｅｍ．ｃ‐ｆｉｒフィルタシステムのコ
ード例
【０１５９】
以下のコード部分Ｋは、図１５と一致した方法で循環バッファを用いてＦＩＲ計算を実
装する。
【０１６０】
「ｖｏｉｄ  ｆｉｒ＿ｆｉｌｔｅｒ（  ．．．．  ）」関数は、以下のように書くこと
ができる：
// apply FIR filter to current sample data
// calculate filter using circular data buffer
// "1d_sample_buffer"
// assumptions:
// a. "begin" and "result" are indices into 1d_sample
// buffer [N+2] and are known to be in the range 0
// to N+2. "begin" is the index of the newest
// sample and (result-1) is the index of the oldest
// sample.
// b. "filter [N] " array variable contains filter
// coefficients//
// intialize variables
int i;
int end;
int ind;
long temp_result;
// process part 1
// calculates the filter from newest sample to oldest
// sample or the end of the data buffer
// "1d_sample_buffer"
// determine the "end" condition for the
// processing of part 1
if (begin > 3) {
end = N+3;
}
else {
end = (N + begin);
}
// processing of filter for "process part 1"
ind = 0;
for( i = begin; i < end; i=i+l )
{ // begin for i = 0..
temp_result += ( long) 1d_sample_buffer [ i ] * filter [ ind ];
ind += 1;
} // end for i = 0..
// process part 2, if necessary
// calculates the remaining data for the filter
//continuing from newest to oldest if process 1 did
//not perform all the processing
if (begin > 3)
{ // begin if begin..
for ( i = 0; i < (result) ; i=i+l )
{ // begin for i = 0..
temp_result += ( long) 1d_sample_buffer [ i ] * filter [ ind ];
ind += 1;
} // end for i = 0..
} // end i f begin..
1d_sample_buffer[result] = temp_result;
コード部分Ｋ：ｆｉｒ＿ｆｉｌｔｅｒ関数
【０１６１】
この実装形態では、「１ｄ＿ｓａｍｐｌｅ＿ｂｕｆｆｅｒ」は、図１５に示した経時的
メモリにおける構造と同様に演算できる。
【０１６２】
撮像フィルタの例に関して上述したように、論理的には、ＡＮＳＩ  Ｃソフトウェアプ
ログラミングモデルを有するＭＰＩは、雑多なメモリ及び適合可能な通信スキームの全要
件をサポートできる。実行モデルは、ソフトウェアプログラミングモデルの要件を満たす
能力を提供でき、またソフトウェアプログラミングモデルは、可変リアルタイムパフォー
マンスを標的とすることができるスケーラブルなコードをサポートできる。
【０１６３】
これもまた上述のように、現行のアプローチでは、標的ハードウェアの特徴の外挿をサ
ポートするソフトウェアプログラミングモデルは、システムの効率的な記述を可能とする
ことができないか、又は促進しない。
【０１６４】
この例示的なＦＩＲフィルタの例では、議論の焦点は、通信構造のプロパティ及びメモ
リプロパティとのインタラクティブ性からシステムを記述し、またシステム要件から処理
を記述することに当てられている。これは、通信構造のプロパティ、即ち：通信をサポー
トするために使用される構造のサイズ；処理をサポートするために使用される構造のサイ
ズ；処理をサポートするための構造の挙動；メモリをサポートするための構造の挙動；処
理をサポートするための構造のアクセシビリティ；及びメモリをサポートするための構造
のアクセシビリティを定義することを伴い得る。この通信ビューが定義されると、メモリ
、制御及び処理プロパティを引き出すか又は明確に定義できる。例示的な一実施形態では
、これは以下の方法で実施できる。
【０１６５】
通信構造のサイズの定義
図１４のＦＩＲフィルタ例において示すように、システムに関して最も自然なメモリ構
造をサポートするために、循環サンプルバッファアドレス指定スキームが生成され得る。
通信構造のサイズは、フィルタのサイズ、即ち現在のデータのフィルタ処理に必要な行数
（このケースでは１Ｎ）と、処理の現在の結果をキャプチャするための更なるサンプルと
、次のデータのサンプルを同時に受信するための更なるサンプルと、ＦＩＲフィルタ処理
の過去に計算された結果を送信するための更なるサンプルとを加算した数によって定義で
きる。従ってこの例示的なアプリケーションに関して、通信構造のサイズは、「Ｎ＋３」
として定義又は指定できる。
【０１６６】
通信構造の挙動の定義：
通信構造のサイズに加えて、所定の時点における構造の挙動を明確に定義する必要があ
る。この特定のケースでは、通信の挙動は、過去に受信された処理済みのデータと、利用
可能な、即ち到着済みの新規のデータとに対して定義される。具体的には、この例示的実
施形態では、現在の処理のために使用されることになる、「現在のデータ」として表示さ
れる（通信メモリの）セクションが存在し、そのサイズは「Ｎ」サンプル超であり、また
、次のデータのサンプルを受信するセクション（又はサンプル空間）が存在し、過去に計
算された結果を保持するセクション（又はサンプル空間）が存在し、最後に、処理から現
在の結果を収集するセクションが存在する。現在の処理が完了し、過去に計算された結果
が送信された後、受信されたばかりの次のデータのサンプルが、今度は現在のデータの第
１のサンプルとなるように、通信の挙動を更新できる。そして現在の結果は、送信される
べき過去に計算された結果となり、現在の結果はその位置を再割り当てされる。従って、
これら通信（メモリ）セクションをこのように回転式で使用することにより、通信構造の
挙動を定義でき、又は特徴付けることができる。
【０１６７】
通信構造のアクセシビリティの定義
各通信セクションは、定義されたアクセシビリティを有する必要がある。この特定の例
示的なケースでは、現在のデータに関しては、このデータは標準的な１次元アレイの形態
でアクセス可能である必要がある。上述の通信構造の挙動に従って、新規のデータのサン
プルが到着して又は受信されて新規のデータの第１のサンプルとなり、データの最も古い
又は最後のサンプルが脱落する度に、ユーザ／プログラマの視点からのデータの自然な書
き込み及びアクセスをサポートするために、物理アドレスへの１次元アクセスを更新して
よい。他の３つの通信のセクション（上述）は、データ及びフィルタリングの結果の受信
並びに結果の送信をサポートする、データのサンプル空間を効果的に実装できる。
【０１６８】
メモリプロパティ（サイズ、挙動、アクセシビリティ）の定義
通信構造のサイズ、挙動、アクセシビリティが定義されると、メモリ間又はメモリ内、
制御、及び処理プロパティを、そのシステム又は別のシステム内のインタラクティブ性に
基づいて引き出すことができ、又は明確に定義できる。この特定のケースでは、システム
の入力プロパティを、通信構造のサイズ、挙動、アクセシビリティの定義から引き出すこ
とができる。
【０１６９】
ここでもまた、次のステップは、ソフトウェアプログラミングモデル内でシステムのプ
ロパティを効果的に表現することであってよく、これを行うには、ＭＰＩ等のＡＰＩを生
成又は拡張してＡＮＳＩ  Ｃをサポートすること、Ｃ＋＋で特定のクラス構造を生成する
こと等を含むがこれらに限定されない、多数の方法が存在する。しかしながら上述のよう
に、具体的な語彙的表現は重要ではない。寧ろ重要なのは、プログラミングモデルがこれ
らの（動的な）システムの定義を認識すること、即ちツールフローがシステムの定義を解
釈でき、続いてシステムを標的の実行モデル及び下層のハードウェアアーキテクチャに効
果的にマッピングできることである。
【０１７０】
例示的なコードであるコード部分Ｉ、ｆｉｒ＿ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃは、制
御モデル、メモリモデル、補助通信構造及び処理に明らかにアプローチし、またそのよう
に解釈される必要があり得、これは上述のように、システムを直感的に表現でき、システ
ムを定義でき、又は効率的にシステムを解釈できるような方法で、制御、通信、処理及び
メモリ構造の間で動的インタラクティブ性を定義できない。
【０１７１】
ＦＩＲフィルタの例を用いて続けると、ｆｉｒ＿ｆｉｌｔｅｒ＿ｋｅｒｎｅｌ．ｃは以
下のように上書きできる：
//* fir_filter_kernel.c
//* example pseudo code for FIR filter incorporating system
// property defintion
#include <mpx.h>
#include <math.h>
#include "filter_system.h"
// initialize communication memory
struct com_fir {
int com [N];
int receive;
int send;
int result;
}
com_fir com;
// FIR filter function with calculations written naturally as for(i)
// and performs function while receiving next sample of data and
// sending previously calculated result.
void fir_filter( .... )
{.... }
mpx_cell fir_filter_kernel( .... )
{ // begin mpi_cell..
// receive initilization of FIR filter properties of generic FIR filter
// kernel including type (size and amount) of input and output for
// MPX_FIFO_IN and MPX_FIF0_0UT
MPX_Recv( .... ) ;
while(1)
{ // begin while
// non-blocking sample receive or data sample receive and partial
// accumulation
MPX_Recv( com.recieve,....,MPX_FIFO_FIR |
MPX_NONBLOCKING              |
MPX_FIFO_IN );
fir filter( .... ); //perform FIR filter across current data in
// "com"
// non-blocking send of resulting sample or sample data
// and partial accumulation
MPX_Send( com.send,....,MPX_FIFO_FIR |
MPX_NONBLOCKING ...        |
MPX_FIFO_OUT );
} // end while
} // end mpx_cell
コード部分Ｌ：  ｆｉｒ  ｆｉｌｔｅｒ  ｋｅｒｎｅｌ．ｃ‐一実施形態によるシステム
のプロパティの定義を組み込んだ、ｆｉｒフィルタカーネルの更新されたコード例
【０１７２】
コード部分Ｌの更新されたコード例に示すように、プログラム文「ｉｎｔ  ｃｏｍ［Ｎ
］；」は変数を宣言しており、これは、この時点ではプログラミングモデルによってサポ
ートされている、上述のサイズ、挙動、アクセシビリティプロパティを備える通信構造と
して使用される。これはコード部分Ｌ中の、「ＭＰＸ＿Ｒｅｃｖ（ｃｏｍ，．．．．，Ｍ
ＰＸ＿ＦＩＦＯ＿ＦＩＲ  ｜  ＭＰＸ＿ＮＯＮＢＬＯＣＫＩＮＧ  ｜  ＭＰＸ＿ＦＩＦＯ
＿ＩＮ）；」及び「ＭＰＸ＿Ｓｅｎｄ（ｃｏｍ，．．．．，ＭＰＸ＿ＦＩＦＯ＿ＦＩＲ  
｜  ＭＰＸ＿ＮＯＮＢＬＯＣＫＩＮＧ  ｜  ＭＰＸ＿ＦＩＦＯ＿ＯＵＴ）；」という例示
的なＭＰＩ構造体によって示される。
【０１７３】
ここで、コード部分Ｋの「ｖｏｉｄ  ｆｉｒ＿ｆｉｌｔｅｒ（  ．．．．  ）」関数を
自然な形態で書くことができ、以下のように、その処理において高い演算効率を達成でき
る：
// apply FIR filter to current sample data
int40 temp = 0;
for( i = 0; i < FILTER_LENGTH; i++ )
{ // begin i = begin..
temp += (long) com.com[ i ] * filter[ i ];
} // end for i = 0..
com.result = temp >> SCALE;
コード部分Ｍ：更新されたｆｉｒ＿ｆｉｌｔｅｒ関数
【０１７４】
ここで「ｃｏｍ」通信メモリは、図１６に示した経時的メモリにおける構造と同様に演
算できる。
【０１７５】
最後に、プログラム文「ＭＰＸ＿Ｒｅｃｖ（  ｃｏｍ．ｒｅｃｉｅｖｅ，．．．．，Ｍ
ＰＸ＿ＦＩＦＯ＿ＦＩＲ  ｜  ＭＰＸ＿ＮＯＮＢＬＯＣＫＩ  Ｇ  ｜  ＭＰＸ＿ＦＩＦＯ
＿Ｉ  ）；  ／／  ｎｏｎ-ｂｌｏｃｋｉｎｇ  ｓａｍｐｌｅ  ｒｅｃｅｉｖｅ  ｏｒ  
ｄａｔａ  ｓａｍｐｌｅ  ｒｅｃｅｉｖｅ  ａｎｄ  ｐａｒｔｉａｌ  ａｃｃｕｍｕｌａ
ｔｅ」は、挙動及びアクセシビリティのプロパティを自動的に更新する単回更新を提供で
きる。これは、受信されるべき次のデータのサンプル、処理するための現在のデータ、収
集されるべき現在の結果をセットアップする。
【０１７６】
上述のＦＩＲフィルタの例の例示的な１つの変形例では、ＦＩＲフィルタの一部はスレ
ッドで実施され、計算のためにＦＩＲの部分累算を受信する必要があり、計算が完了する
と、適切なデータサンプルを有する別のスレッドへ転送する。例示的なコード部分Ｎは、
サンプルデータ及び部分累算を受信するスレッドを示し、これにコード部分Ｏが続き、こ
れは部分ＦＩＲフィルタカーネル、及び図１７に示すような代表的な通信メモリ構造の使
用を示し、図１４のＦＩＲ相／セグメントの中段のブロックに対応する。
//* fir_filter_kernel.c
//* example pseudo code for FIR filter incorporating system
// property definition
// it receives partial_result, sampled data, and sends sampled data
#include <mpx.h>
#include <math.h>
#include "filter_system.h"
// initialize communication memory
struct com_fir {
int com[FILTER_LENGTH];
int receive;
int40 result_partial;
}
com_fir com;
// FIR filter function with calculations written naturally as
//for (i)
// and performs function while receiving next sample of data and 
// sending previously calculated result.
void fir_filter( .... )
{.... }
mpx_cell fir_filter_kernel ( .... )
{ // begin mpi_cell..
// receive initilization of FIR filter properties of generic FIR filter
// kernel including type (size and amount) of input and
// output for MPX_FIFO_IN and MPX_FIF0_0UT
MPX_Recv( .... );
while (1)
{ // begin while
// non-blocking sample receive or data sample receive and
// partial accumulation
MPX_Recv( com. receive |
com. result_partial,....,MPX_FIFO_FIR | ...
MPX_NONBLOCKING ... |
MPX_FIFO_IN );
fir_filter( .... ); //apply FIR filter across
//current data in "com.com"
// non-blocking send of resulting sample or sample data
// and partial accumulation
MPX_Send ( com.com [N-1] | com.result_partial , ...., ...
MPX_FIFO_FIR  | ... MPX_NONBLOCKING |
MPX_FIF0_0UT );
} // end while
} // end mpx_cell
コード部分Ｎ：サンプリングされたデータ及び部分累算転送をサポートする通信モデル構
造のコンテキスト内の、部分フィルタカーネル組み込みシステムのプロパティの定義の例
// perform part of a FIR filter on current sample data
// supporting receiving partial accumulation and
// forwarding partial accumulation
for( i = 0; i < FILTER_LENGTH; i++ )
{ // begin i = begin..
com.result_partial += (long)com.com[ i ] * filter[ i ];
} // end for i = 0..
//not needed: com. result = temp >> SCALE;
コード部分Ｏ：部分累算をサポートする、自然な形態で書かれたＦＩＲフィルタカーネル
の一部
【０１７７】
サンプルのみを受信し、部分累算結果と共にサンプルを送信するためのコード、並びに
サンプル及び部分累算を受信して最終的なＦＩＲフィルタ結果を生成するためのコードは
、提供された２つのＦＩＲコードの例の変形例として書くことができ、ここでは簡潔にす
るためにこれを提示しない。本出願に開示される技術のこのような具体的実装形態は、プ
ログラミング技術を有する者の能力の範囲内である。多数の他のフィルタタイプも同様の
様式で再構成でき、他のアルゴリズム及びプロセスについても同様である。換言すると、
上述の例は単なる例示及び例証であり、本発明の範囲を制限することを意図したものでは
ない。
【０１７８】
従って、上で開示されている技術の実施形態は、マルチプロセッサシステム上でのソフ
トウェアの並列実行に関する従来技術のアプローチを上回る有意な効率を提供できる。
【０１７９】
コード部分Ｍに比べて、コード部分Ｏは、整数に適合するためのアキュムレータのリス
ケールを必要としない。
【０１８０】
撮像フィルタの例に関して上述したように、ツールフロー内において、コンパイラは、
システムの挙動を解釈するよう、及び定義されたシステムの機能性をサポートするために
、ハードウェアリソースをより効果的にマッピングするよう、設計されてよい。
【０１８１】
上述のＦＩＲフィルタの例は、主として通信定義（通信ビュー）の視点から記述されて
いる。ここでもまた、これを限定として解釈するべきではない。サイズ、挙動、アクセシ
ビリティの観点から記述したシステムの通信モデルに加えて、又はこれの代わりに、制御
、メモリ、処理ビュー（及びサブビュー）を同様に使用して、システムを記述又は定義し
てよい。
【０１８２】
システム設計の効率的な捕捉に続いて、ハードウェアからのより効率的な操作を達成す
るために、定義されたシステムプロパティをサポートするための新規のプログラム可能な
ハードウェア特徴部分が生成されている。これらの特徴部分は、処理要素、データ経路、
アドレス生成、制御フロー等を含んでよいがこれらに限定されない。これらの特徴部分は
、所定の演算サイクルにおいて（実質的に）最大の演算及びエネルギ効率を達成すること
、並びに多くの計算負荷が高いアプリケーションにおいてオーバヘッド（セットアップ、
インデックスレジスタ更新等）をゼロ近くまで低減することを目的としている。
【０１８３】
ハードウェア要素
以下は、改善されたシステムを提供する、様々な新規のハードウェア要素を説明する。
【０１８４】
ハードウェアの設計は、標的とされたシステムアプリケーションに関して、エネルギ効
率の良い様式で実施できるよう、密接に連結され得る。循環データバッファリングを、モ
ジュロアドレッシング及び（以下に説明する）ＤＭＲ  ＦＩＦＯ技術をハードウェア反復
ループと共に用いて行ってよく、これによりループにおけるアドレス指定が自動化される
。（以下に説明する）ＨｙｐｅｒＯｐは、従来の技術が必要とする高い最適化コストを要
することなく、高度な並列処理を制御する方法を提供する。（以下に説明する）マルチデ
ータ経路ハードウェアは、実際のアルゴリズム数学セクションのより良好な並列処理を、
純粋なＡＳＩＣ、非プログラマブルソリューションと略同じ程度に効率的な様式で可能と
する。自動反復バッファリングは、フェッチ（及び復号化）電力を削減する。限定された
アドレス空間は、データ及び命令の両方に関して、効率的なアドレス指定及び読み出し／
書き込み動作を提供する。データの再整列及びアキュムレータ転送は、データ移動オーバ
ヘッドを低減するため、及びアルゴリズムをより迅速に実行できるよう、多数のＰＥを１
つに結合して、追加のリソースを動作させるための機構を提供する。
【０１８５】
目標
ハードウェアシステムのいずれの工学的実装の目標は、システムに必要な機能性を最小
のコスト関数で提供することである。このコスト関数は多数の態様を含み、ここで最も重
要なもののうちのいくつかは、実際のハードウェアコスト、システム全体を実装するため
の時間／コスト、使用コスト（電力及び面積）等である。これは様々な方法でトレードオ
フを克服する多数のオプションを何度も利用できる。前の節において、提示された様々な
ソリューションは、ＧＰＰ、ＧＰＵ、ＤＳＰ、ＦＰＧＡ、メニーコア／マルチコア、ＡＳ
ＩＣを含んでいた。これらのタイプのハードウェアを用いて利用可能な既存のシステムの
実装は、複雑性、使いやすさ、プログラム可能性、柔軟性、コスト、電力の点で大きく異
なる。与えられた例のうち、所定のシステムに関して最も電力効率が良いのはＡＳＩＣで
ある。しかしながら、ＡＳＩＣは最も柔軟性のないものでもあり、また開発の時間及びコ
ストに関して最も犠牲の大きいものである。その他のものはより柔軟性を提供するが、大
抵比較的低いコスト／時間及び増大された電力においてトレードオフを有している。本出
願において記載するハードウェアの目標は、純粋なＡＳＩＣハードウェアソリューション
の電力効率に依然としてアプローチしながら、特定のタイプの計算負荷のための従来の手
段によって高度にプログラム可能なハードウェアプラットフォームを提供することである
。
【０１８６】
概念
この目標に挑戦し、到達するために、提示されている他のソリューションの実質的に全
てから概念を借用する。これらの概念の革新的な修正及び組織化は、より迅速な実装（市
場に出るまでの時間）を可能とするために望まれる高度なプログラム可能性を依然として
提供しながら、電力効率に関して純粋なハードウェアソリューションにアプローチする電
力効率の良い実装を可能とする。使用されるソフトウェア技術は、ハードウェアを補助す
るパフォーマンス及び電力最適化を提供するアーキテクチャに密接に連結される。
【０１８７】
ここでの主要な焦点は、低電力で高スループットを提供するために実行ユニット又は処
理要素（ＰＥ）をどのように設計するかを説明することである。これは、処理のためにデ
ータがＰＥへと及びＰＥから流れるファブリックを提供するデータメモリルータ（ＤＭＲ
）における、メモリ及び通信システムに連結される。
【０１８８】
処理要素
従来技術（ＧＰＰ、ＧＰＵ、マルチコア、ＤＳＰ等）における処理要素（ＰＥ）は複数
の命令アーキテクチャを有し、これら命令アーキテクチャは、従来の完全に符号化された
命令、又は多数の演算ユニットの制御のための多数のスロットを有する超長命令語（ＶＬ
ＩＷ）であった。これらのアーキテクチャにおけるデータ経路に関して、従来技術のうち
のいくつかは、様々な程度の独立性によって並列に演算を行うことができる多数の演算ユ
ニットを含む。スーパースケーラ型の実装において混合される多数の命令ストリームをサ
ポートできるものもあれば、シングルスレッド化されるものもある。
【０１８９】
ここで提示する革新的なＰＥのアーキテクチャは、従来の完全に符号化された命令及び
サブ命令のためのＶＬＩＷ型スロットのハイブリッドである。これは極めて柔軟かつ効率
的な命令アーキテクチャであり、乗算器、ＡＬＵユニット、アドレス生成器等といった多
数の演算ユニット及びこれらを相互接続するための機構を有する多種多様なデータ経路を
サポートできる。命令ストリームの実行をスケジューリングするために多くのハードウェ
アを必要とするスーパースケーラアーキテクチャの動的スケジューリングとは異なり、こ
のアーキテクチャは、命令ストリームを生成するソフトウェアツール（コンパイラ、アセ
ンブラ等）によって提供される静的スケジューリングを提供する。この静的スケジューリ
ングは、静的スケジューリングを例えばＧＰＰのランダムな命令ストリームに関してあま
り最適でないものとするいくつかの制限を有しているものの、適切な最適化コンパイラ及
びソフトウェア開発ツールと連結される場合、ＤＳＰ及び画像処理のための高度に構造化
されたリアルタイム型アルゴリズムにとって完全に十分であり、大いに改善された実行時
の電力効率を提供する。
【０１９０】
ＰＥは、演算ユニットが実行される多数のパイプラインステージで構成される。主要な
演算ユニットは、命令フェッチ、復号化／発行、オペランドフェッチ、実行ユニット及び
ライトバック（フェッチに連結される）である。使用される公称９ステージパイプライン
を図１８に示し、演算ユニットがパイプラインのどこで動作するかが示されている。
【０１９１】
このパイプライン構造は寧ろ、今日の基準に照らしても浅く、これは目的を有している
。個々のユニット及び特徴の設計を、低電力設計を可能とする固有の設計点に重点を置い
て、以下の節で議論する。読者は情報が多数のセクションに亘って情報が広がる傾向にあ
ることに気付くだろう。というのは、特徴及びアーキテクチャが共に動作する多数の機能
性ユニットを横断して、固有の全体的なハードウェア設計を生成するからである。大半の
ものよりも少ないステージを有するパイプラインは、パフォーマンスを向上させ電力を削
減するために行われるハードウェア最適化の一部である。より小さく、より単純なハード
ウェアを用いて、パイプラインを、浅いパイプラインによってでさえ高いパフォーマンレ
ベルで実行されるよう構築できる。
【０１９２】
実行パイプライン
基本的なパイプライン
図１９は、単一データ経路アーキテクチャに対して改善されたＰＥデータ経路の図であ
る。より詳細には、図１９は、（前世代と同様の）幾分標準的な単一データ経路、及び改
善されたＰＥデータ経路アーキテクチャ（命令フェッチ、復号化、及び制御論理は図示せ
ず）の概念ブロック図である。この改善されたデータ経路は、単一データ経路よりも約６
０％多いロジックで実現できる。換言すると、改善されたデータ経路におけるパイプ０又
はパイプ１は、本質的に１サイクル毎に同等又はそれ以上の演算が可能である単一データ
経路よりも、２０％論理的でない。単一のデータ経路は、論理演算及び算術演算のための
別個の経路を有する。乗算器は、浮動小数点仮数乗算をサポートするために２４ｂ×２４
ｎであってよい。これには４０ｂアキュムレータ及び加算−比較−選択（ＡＣＳ）ユニッ
トが続いてよい。続いて全ての結果を再びシフト及び累算してよい。限定された量のパイ
プライン並列処理は、アキュムレータを半分に分割すること及び単一命令マルチデータ処
理（ＳＩＭＤ）モードで動作させることにより、８ビットデータ上で可能である。
【０１９３】
改善されたデータ経路アーキテクチャは、図においてパイプ０、パイプ１として示した
二重の独立したパイプラインを含む。これらのパイプはそれぞれ、デュアル１６ｂ×１６
ｂ乗算器を有する。パイプは、乗算の結果の範囲：クアッド１６ｂ、デュアル１６ｂ＋１
つの３２ｂ、デュアル３２ｂ、又は１つの６４ｂ（これは浮動小数点演算のための単一の
２４ｂ乗算もサポートする）を達成するために圧縮器回路によって結合される。各パイプ
に関して、圧縮器の後には、シフト、論理、加算、ＡＣＳ、続いて最終的なアキュムレー
タのステージが続いてよい。単純な単一データ経路パイプラインでは、１６ｂ演算、リア
ルタイムＤＳＰエンジンのための一次データサイズのために、単一の演算操作（乗算、又
は加算／減算）のみを１クロック毎に実施してよい。新規のアーキテクチャにより、ハー
ドウェアは、特定の演算に関して１クロック毎に最高４つの同一のタイプの演算を提供す
るために、より多くの最適な構造に分割される。このアーキテクチャは、１つのパイプラ
イン毎に削減された量のハードウェアと共に、ＤＳＰ及び画像演算を行うために十分な遥
かにエネルギ効率の高い方法を提供する。達成可能なエネルギ効率は純粋なハードウェア
ソリューションに匹敵するが、達成可能なエネルギ効率はここでは完全にソフトウェアプ
ログラム可能なＰＥにおいて達成され、これは開発努力を低減する。デュアル／クアッド
パイプラインアーキテクチャは１ＰＥサイクル毎に多数の異なる組み合わせの演算を可能
とするが、従来のアセンブリ言語命令セットは固有の柔軟性の全てをサポートできない。
この増大した柔軟性を十分に利用するためのモデルを符号化及びプログラミングする命令
全体における変化についても議論する。
【０１９４】
図１９、２０において、データ経路が乗算器の後で２つの圧縮器を（パイプ１とパイプ
０との間で）連結していることに留意されたい。ＦＩＲフィルタ等に必要とされるような
多数のオペランドの積和演算のような、演算の加速のための単一の乗算の累算を提供する
。これは、これらの演算及び差分絶対値の和（ＳＡＤ）タイプの演算を行う、極めて効率
的な方法である。この最適化は、その他のものよりも、このアーキテクチャの電力効率を
大幅に増大させる。これは、ＭＡＣのための乗算器アレイ又はＳＡＤタイプの演算のため
の加算器アレイからの部分積に対する別のビットの圧縮演算を単に行う一方で、別の全加
算器の有効性を提供する、少数の単純ゲートである。再び、これらの追加のゲートを効率
的に使用する能力は、後に議論の対象となる改善された命令符号化及び制御技術を必要と
し得る。
【０１９５】
改善されたＰＥデータ経路の特徴を要約する：
【０１９６】
それぞれ（１サイクル毎に）以下が可能である２つのデータ経路：
・１つ／２つの１６×１６乗算又は１つの３２×３２乗算
・１つ／２つの１６ｂ加算／減算又は１つの３２ｂ加算／減算
・４０ｂバレルシフト
・３２ｂ論理演算
・２つの４０ｂアキュムレータを用いた４０ｂ累算
【０１９７】
データ経路は共に（１サイクル毎に）以下を実施できる：
・１つの３２×３２乗算又は積和演算
・１つの３２ｂ浮動小数点加算／減算／乗算
・二重又は単一の累算を伴う４つの１６ｘ１６乗算
・累算による４つの差分絶対値の和
【０１９８】
２つのデータ経路における乗算器及び加算器の４つの演算に基づいて、ＤＳＰアルゴリ
ズムに必要である、効率的に実施できる更に多くの機能が存在する。純粋に命令符号化レ
ベル（後のＨｙｐｅｒＯｐを参照）においてではなく、プログラミングレベルにおいて実
装されることになるこれらの演算を可能とするために、改善された命令セットを、かなり
低いレベルのプログラミングモデルにおいてハードウェアを露出させるよう設計してよい
。これは、このアーキテクチャによる別の革新をもたらす。
【０１９９】
オペランド整列
メモリからのオペランド及びメモリに対する結果の書き込みのフェッチは、全てのアー
キテクチャのより大きな電力を消費するタスクである。大きなローカルキャッシュ及び複
雑なキャッシングシステムにより、多くの電力がこれらの演算に消費されるため、全体的
な効率を損なう。従来技術のシステムの大半において、メモリサブシステムは、多数の異
なるオペランドサイズ、及びマルチレベルキャッシュシステムを通してアクセスされる大
きなアドレス空間を可能とする。メニープロセッサＩＣチップの各ＰＥのためのオンチッ
プサポーティングメモリは、サイズが更に制限され、同数のオペランドサイズ及び整列演
算をサポートする必要はない。
【０２００】
ＨｙｐｅｒＯｐをサポートするためのデータ整列多重化装置及びＰＥアーキテクチャに
おけるデータ整列多重化装置の使用を説明するために、オペランドサイズ及び整列につい
てここで簡潔に説明する。データオペランド及び結果については後の節でより詳細に議論
するが、本議論では、アーキテクチャが様々な条件において、かつ必ずしも同時にではな
く、以下のオプションを提供すればよい：
・２つの１６ビットオペランドのフェッチ
・２つの３２ビットオペランドのフェッチ
・１６ビット及び３２ビットオペランドの組み合わせのフェッチ
・追加の６４ビットの整列オペランドのフェッチ
・単一の１６ビットの結果の書き込み
・単一の３２ビットの結果又は２つの１６ビットの結果の書き込み
・２つの３２ビットの結果又は６４ビットの結果の書き込み
【０２０１】
メモリインタフェースを単純なままとするために、全ての上述の演算を物理メモリに関
するデータサイズ境界上に整列させるべきである。これは。特定のアルゴリズムにおける
それらの使用の実現可能性を制限するように思われる。この制限に対処するために、オペ
ランド（及び結果）整列多重化装置を上述のデュアル／クアッドパイプラインアーキテク
チャに追加する。整列多重化装置は、アセンブリ言語プログラミングモデルを有する単一
パイプラインにおいて使用が非常に制限される場合があるものの、整列多重化装置は、Ｈ
ｙｐｅｒＯｐプログラミングモデルを有するデュアル／クアッドパイプラインアーキテク
チャの柔軟性と良好に一致する。
【０２０２】
図２０は、本議論のためにいくつかの追加のフローレジスタの拡張を有する、デュアル
高スループット演算ユニットの指定データパイプライン０（ＤＰ０）及びデータパイプラ
イン１（ＤＰ１）を用いたデータ経路の例を示す。これらは追加のパイプラインレジスタ
Ｘ、Ｙ（入力用）、Ｚ（出力用）である。また、オペランドステージＡ、Ｂ、Ｃ及び宛先
ステージＤも示す。
【０２０３】
Ａ、Ｂ、Ｃレジスタを、以前に議論したのと同程度に利用可能である最大６４ビット幅
のオペランドを保存するために使用される。ＨｙｐｅｒＯｐは、２つのデータ経路のＡ、
Ｂ、ＣレジスタとＸ、Ｙレジスタとの間のシステム多重化を用いて、データ経路が実施す
る各演算に必要なオペランド及び単語整列を制御する。ＨｙｐｅｒＯｐ処理中にＡ、Ｂ、
Ｃレジスタへのオペランドフェッチは、メモリへの整列アクセスを可能とするプログラム
制御下にあり、これにより、データ経路算術演算ユニットに再整列様式で（及び従って必
要に応じて整列されていないように見えるもの）にオペランドを提供する。この革新によ
り、より単純な低電力メモリ構造及びアドレス指定モードが可能となり、これにより、ど
のようにしてオペランドがメモリに保存されるかにかかわらずピークスループットを提供
するために、複雑なデータ経路／ＨｙｐｅｒＯｐの組み合わせに十分なオペランドを供給
する方法を提供する。
【０２０４】
結果は、オペランドの議論におけるものと同様である。データ経路結果は、Ｈｙｐｅｒ
Ｏｐ実行中にアキュムレータ又はＺレジスタのいずれかに入れられる。続いてこれらを、
他の場所にライトバックするためにＤに移動させるか、又は後続の命令において追加のオ
ペランドとして使用されることになる例示した経路上にフィードバックされる。オペラン
ドと同様に、ここで結果の再整列ができ、これにより、非整列データのためにメモリ／レ
ジスタに整列されたライトバック提供する。この場合も、これらの演算はＨｙｐｅｒＯｐ
によって独立して制御される。
【０２０５】
１つのパイプラインにつき二重のアキュムレータ
同様の算術演算の長い文字列を加算して単一の合計とするためのアキュムレータをサポ
ートする多くのアーキテクチャでは、単一のアキュムレータが存在する。更に、場合によ
っては全ての演算がこのアキュムレータを結果で修飾する（この場合でも我々の前世代）
。この構造は、追加のデータ経路の追加及びＨｙｐｅｒＯｐによって１サイクル毎に多数
のオペランドに対して演算する能力の追加により、１サイクル毎の主に単一のスカラー演
算であるアーキテクチャのために良好に作用するのと同時に、これはこの概念を拡張する
ために必須のものとなる。現行の設計点は、データ経路毎に２つの独立したアキュムレー
タを含む。各演算は、必要であれば、どのアキュムレータを更新するかを選択できる。従
ってこれらを用いて、前で議論したシステム多重化構造によって後に処理するための中間
値を保存できるか、又は多数のデータストリームを追加のサイクル若しくはアキュムレー
タ値をセーブ及び復元する電力オーバヘッドを要することなく、インタリーブ形式で処理
できる。二重のデータ経路及びオペランド／結果アライメントといった他の特徴と連結さ
れる場合、二重のアキュムレータ構造のこれらの特徴は、パイプラインがより十分に利用
される状態を保つための機構を提供し、これは同様に設計のための演算毎の全体的な電力
を削減する。
【０２０６】
アキュムレータ転送
アキュムレータに関連する別の特徴は、いくつかのアルゴリズムの内側ループを高速化
するための、及びチップ内の多数のＰＥに亘る並列実行を増大させるための別の方法を提
供する。例えばこれは、多数のＰＥに亘って広がる必要がある計算ループに対するオーバ
ヘッドを最小化して、マルチタップ高帯域幅ＦＩＲフィルタ等の場合に帯域幅を処理する
十分なデータを提供するために必要である。これは、図２１に示したＰＥ間の「アキュム
レータ転送（ａｃｃｕｍｕｌａｔｏｒ  ｆｏｒｗａｒｄｉｎｇ）」によって達成できる。
【０２０７】
この図は２つのＰＥを示すが、これは所望の帯域幅に到達するために必要とされるのと
同じ数まで、容易に拡張可能である。経路は、１つのアキュムレータが更新されると更新
された値が別のＰＥに対するＤＭＲのファブリック拡張部分に転送されるように、設けら
れる。ここで、到達したこのアキュムレータ値はローカル計算に加算して新たなローカル
アキュムレータに入れるために使用される。この新たなアキュムレータ値は、更なる計算
のために別のＰＥに再び転送される。
【０２０８】
また、ローカルＭＡＣ（又はその他の）計算のための４つの係数値を保持するためのＣ
レジスタの使用が図示されている。これは、例えばＦＩＲフィルタの４つのタップを提供
できる。鎖線の中の各ＰＥは更なる４つのタップを提供できる。よって例えば、しかしそ
れによって限定されないが、８個のＰＥは、１クロックあたり１つのサンプルのフルクロ
ックレートで、３２タップのＦＩＲフィルタを実装してよい。単一のＰＥにこの同一のフ
ィルタを実装することは、フィルタの帯域幅を８クロック毎に１つのサンプルまで制限す
ることになる。
【０２０９】
データは、フィルタを通してデータストリームを前進させるためのＦＩＦＯ構造を有す
るＤＭＲ間を通過する。前の節で言及したリアライメントバッファを用いて、各ローカル
ＰＥを処理する現在のデータセットのための適切な係数を選択する。データ移動は実行に
よるロックステップにおけるものであり、これにより、アルゴリズムと一致した方法で次
の計算を行うためのデータの到着時にトリガが起こる。このようにして、フィルタを、同
一のデータ移動、及び同様のフィルタを実装する純粋なハードウェア構造が必要とする同
一の計算のみを用いて実装してよい。これにより、このプログラマブルソリューションの
電力散逸が、同一の機能を実施するＡＳＩＣに匹敵するものとなる。
【０２１０】
このケースに基づいて、単一のクアッド乗算−累算命令をフェッチして、このアルゴリ
ズムの内側ループを実行してよい。後の節では更なる詳細が提供されるが、この命令を（
必要な場合他のものと共に）命令フェッチ及び分配ユニットによってローカル命令バッフ
ァに保存してよい。ループでは更なる命令フェッチは不要であり、単一の命令に関しては
更なる復号化は不要であり、潜在的に多くの電力散逸をセーブする。
【０２１１】
例えばデュアル／クアッドアーキテクチャを有する多数のＰＥを用いたＦＩＲフィル
タの場合、各ＰＥは各サイクルにおいて、単一命令を有する最大４つの入力サンプルまで
処理できる。この命令は、制御ラインのトグリングなしに、何度も実行できる。システム
がこの１つ又は複数の反復命令を検出すると、メモリからのフェッチは起こらないため、
命令メモリは節電モードに入る。ＦＩＲフィルタのようなタイトループＤＳＰアルゴリズ
ムのうちのいくつかに関して、このプログラマブルシステムにおけるデータ移動及び計算
及びマイナー制御トグリングは、ＡＳＩＣハードウェア実装と同様であり、従って略同一
の動的電力散逸を達成する。
【０２１２】
命令フェッチ／復号化におけるアドレス生成
図２０では、アドレス生成器ユニット（ＡＧＵ）を含むアドレス生成器セクションを示
したが、これについて詳述していなかった。ＰＥアーキテクチャのアドレス生成器セクシ
ョンは、ハードウェアによってサポートされる様々なアドレス指定モードのためのアドレ
スを生成する。その固有の特徴をこの節で詳述する。
【０２１３】
アドレス生成器セクションは、アドレス生成に使用するための多数のプログラマブル算
術演算ユニットを有してよい。更に、パイプラインのアドレス計算部分において更なる計
算を行うために使用できる１つ又は複数の拡張された算術演算及び論理ユニット（ＧＡＬ
Ｕ）が存在してよい。これらの計算は、パイプの機能性及びパフォーマンスを拡張するの
に、並びにテーブルルックアップ型演算及びその他のものにおけるパイプライン遅延を排
除するのに有用である。図２０において、例示的なアドレス生成器セクションは、３つの
ＡＧＵ及び１つのＧＡＬＵ及び一連のサポートレジスタを含む。
【０２１４】
標準的な符号化方法における典型的な演算のために、ＡＧＵを用いて２つのソースオペ
ランド及びデスティネーションのための、又はこれらのサブセット及びいくつかのアドレ
ス若しくは拡張数学演算のためのアドレスを生成する。ユニットは符号化を用いて密接に
連結される。ＨｙｐｅｒＯｐ符号化を介した拡張演算のために、これらのユニットは更に
連結解除され、命令ストリームによって個別に制御できる。これは、演算の更なる柔軟性
及び更なる並列化を可能とする。最適化はコンパイル時に実施してよく、これにより、リ
アルタイムの順序変更が不要となり、従って上記最適化の動作パワーペナルティがなくな
る。
【０２１５】
このハードウェアのより詳細なブロック図を図２２に示す。この図により、多数のＡＧ
Ｕの連結が、このセクションにおける使用のために利用可能なレジスタと共にはっきりと
分かる。例示的なハードウェアを以下のように詳述できる：
・アドレス型計算のための３つの標準的なＡＧＵ
・追加の算術／論理サポート（ＧＡＬＵ）のための１つの拡張ＡＧＵ
・８つのベースレジスタＢ０．．Ｂ７
○アドレス指定モードにあるＢ０は値ゼロを得る
○Ｂ０はスタックポインタとして使用される（ＳＰ相対アドレス指定モード）
・８つのインデックスレジスタ１０．．１７
○アドレス指定モードにある１０は値ゼロを得る
○１０を他のＡＧＵ算術のための一時レジスタとして使用できる
・８つのストライドレジスタＳ０．．Ｓ７
○ＳｎはＩｎ又はＢｎと共に使用される
・２次インデックス又はベースレジスタ用の４つの追加のインクリメンタ
○インデックスレジスタ１４．．１７
○ベースレジスタＢ４．．Ｂ７
○ストライドレジスタＳ４．．によるインクリメント
【０２１６】
最後の３つの項目はパイプの早期の命令フェッチ部分におけるアドレス計算及び単純計
算において使用され得ないだけでなく、後に説明するハードウェア反復動作に連結されて
クリティカルループ計算のためにゼロオーバヘッドルーピングを提供する。
【０２１７】
図２３は、単一のＡＧＵのより詳細な図を示すブロック図である。各ＡＧＵの特徴部分
は以下を含んでよい：
１）更なるアドレス計算がより多くのレジスタ上で利用可能である；
２）拡張された迅速なＡＧＵの動作のための新たなブロック。（これらのうちの１つの
みが存在し得る。入力は既存の多重化装置及びＡ、Ｂソースアドレス復号化からのフォー
ル度を使用する）；
３）加算器の条件コード出力は迅速な分岐性能を可能とする。（これは、追加のパイプ
ライン遅延を挿入するメインデータ経路の代わりにＡＧＵが決定算術演算を実施した場合
に、ゼロオーバヘッド条件の分岐を提供する）；
４）（循環バッファリングのための）剰余インデックス算術演算；
５）（平坦なメモリへの多次元アレイのマッピングのための）マルチストライドインデ
ックス算術演算；
６）加速されたテーブルルックアップのための複雑な算術演算。
【０２１８】
アドレス計算に単一のＡＧＵを使用するのに加えて、特定の命令によって複数のＡＧＵ
を組み合わせて、より複雑なアドレス計算を実施できる。このようにして、ＨｙｐｅｒＯ
ｐは、アドレスに対する複雑な算術演算を実施するためにＡＧＵを配分でき、これによっ
てメモリアドレスの使用方法に更なる柔軟性を提供できる。これらのより複雑なアドレス
指定モデルは、循環アドレス指定（後のセクションで更に詳細に取り扱う）、剰余アドレ
ス指定、２Ｄ及び３Ｄアドレス指定と共に使用するためのマルチストライドインデクシン
グ、複雑なテーブルルックアップアドレス指定、ｓｉｎ／ｃｏｓによる特別なアドレス指
定等を含むことができる。ハードウェアパイプラインのこのセクションに加算器及び論理
性能を有するという柔軟性により、特定のアルゴリズムに関して複雑なアドレス算術演算
を、このアドレス算術演算を通常の実行パイプラインで実施した場合に可能なものよりも
効率的に、実施できる。ＡＧＵはメインデータ経路ＡＬＵとは別個のハードウェアである
ため、アドレス計算はデータ計算と同時に実施できる。
【０２１９】
ＡＧＵ分岐
ＡＧＵパイプライン領域の別のＡＬＵ機能性は、ゼロオーバヘッド分岐を可能とする、
早期の分岐計算である。分岐の決定を計算するための算術演算を、パイプラインの通常の
実行セクションで実施すると、これはパイプラインのタイミング構造の範囲内において非
常に後で行われる。これは、分岐を誤って予測した場合、複数の命令をフェッチして、分
岐の決定を終了させている間にこれら命令を推測で実行することになる（命令は、結果を
書き込むことによってその不変状態を変更できない）ことを意味する。決定が誤っている
場合、これらの結果は無効であり、使用されず、これらのための電力及び時間が無駄にな
る。ＡＧＵ算術演算は、実施される分岐決定よりもパイプ内で極めて早期に行われるため
、誤った命令をフェッチすることはなく、推測による実行も発生しない。従って、分岐に
よって、使用できない命令に対するいずれの実行サイクル又は電力が浪費されることがな
くなる。
【０２２０】
循環アドレス指定
ＤＳＰアルゴリズムの加速のための複雑なストリーミングデータ構造をサポートするた
めに、拡張されたアドレス指定モードが望まれる。１つのこのようなモードは、循環アド
レス指定である。このタイプのアドレス指定により、算術演算をより簡潔な形態で書くこ
とができ、またかなりの複雑性がデータ経路からＡＧＵセクションへと移され、このＡＧ
Ｕセクションにおいて、上記算術演算をより効率的に、かつパフォーマンスのためにより
良いパイプラインのタイムスロットにおいて実行できる。これを達成するためにハードウ
ェアをどのように利用するかは、以下の例から理解できる。
【０２２１】
２つのＡＧＵからの２つのインデックスインクリメンタのペアを組み合わせて、１つの
インデックスに対する循環アドレス指定、例えば｛ｉ６，ｓ６｝及び｛ｉ７，ｓ７｝を生
成すると想定する。
【０２２２】
図２４に示す循環バッファを想定する、ここで：
・ｉ６は現在のアレイインデックスを保持し、
・ｓ６は通常のストライドを保持し、
・ｉ７は最後の有効な循環アレイインデックスを保持し、
・ｓ７はラップ状況のためのストライドを保持する。
【０２２３】
これは、２つのインクリメンタを図２５に示すように連結することによって達成できる
。これは、アドレスに対するＮを法とする完全な剰余演算を実装し、また算術演算は、１
回のアドレス計算につき最高１回のラップしか行わないようなものである。この制約はソ
フトウェアによって維持できる。４つのインクリメンタが存在するため、このようなアプ
ローチにおいて２つの循環バッファ、｛ｉ４，ｓ４，ｉ５，ｓ５｝及び｛ｉ６，ｓ６，ｉ
７，ｓ７｝を実装できる。
【０２２４】
典型的なＧＰＰアーキテクチャでは、データフローのアドレス指定及び管理のためのア
ルゴリズム及び算術演算は、総計算負荷の極めて大きな部分を占める。上述のＰＥアーキ
テクチャの特徴部分は、データフローのコンパイル時間管理と共に、あるアプリケーショ
ンに関する総計算負荷を大幅に低減し、従って電力散逸を大幅に低減する。
【０２２５】
命令フォーマット及び符号化
このアーキテクチャの命令セットは、以下の２つの別個のサブセットに分解される：
・６４ｂの従来のアセンブリ命令
・１２８ｂのＨｙｐｅｒＯｐ命令
【０２２６】
これら２つのサブセットは、図２６に示す、プログラミングのための関連するモデルを
有する。従来のアセンブリモード（ＡＳＭ）は、従来技術において典型的な、固定長６４
ビット命令に符号化される単一命令ストリームモードであってよい。ＡＳＭ符号化は、異
なる命令タイプのために複数のフォーマットをサポートしてよく、主要な形態は、単一の
データ経路演算による３オペランド（２ソース、１宛先）フォーマットである。このモデ
ルでは、１２８ビットＨｙｐｅｒＯｐモードよりも並列処理のサポートが弱い。しかしな
がら、単一のパイプラインの２つの半体、又は２つの（若しくはそれより多い）パイプラ
イン上での演算を制御するＳＩＭＤ命令のための特定の命令符号化が存在してよい。また
、パフォーマンス及び電力の最適化のためのクアッドデータ経路演算を実行することにな
る、極めて限定的な命令のセットのための符号化も存在し得る。
【０２２７】
もう１つの命令サブセットは、ＨｙｐｅｒＯｐモードである。これについては以下のセ
クションで議論する。これら２つの符号化モデルからの命令は、所定のアルゴリズムに関
する最良の演算を提供するいずれの形態及びシーケンスの命令のストリームへと混合でき
、上記アルゴリズムは最適化コンパイラによって決定できる。
【０２２８】
ＨｙｐｅｒＯｐ
ＨｙｐｅｒＯｐと呼ばれる命令のセットは、高い柔軟性のために、デュアル／クアッド
パイプラインを粒度が高い様式で制御する。命令符号化スタイルは、「従来の」アセンブ
リ（ＡＳＭ）スタイルと、超長命令語（ＶＬＩＷ）スタイルとの間の何らかのスタイルで
ある。これは以下を提供する：
・実行ユニット内の両方のデータ経路パイプの、分離され、かつ独立した制御
・ソースオペランドの位置の、分離され、かつ独立した制御
・結果ライトバックの位置の、分離され、かつ独立した制御
・１クロックあたり最大３つのＡＧＵの、別個の制御
・ハードウェア反復モデルの制御
・（多くの場合、分岐よりも効率的である）術語型実行のための制御
【０２２９】
例示した改善されたデュアル／クアッドデータ経路を用いて、幅広いパイプライン化及
び同時並列処理をプログラムできる。データ経路要素の独立した制御、並びにデータ経路
実行からのデータ（オペランド）フェッチ及び１つ又は複数の結果ライトバックの連結解
除は、従来のＳＩＭＤ機械の厳格性とは異なり、演算において極めて高い柔軟性を提供す
る。ＨｙｐｅｒＯｐ命令は、データ経路のパイプライン化及び同時並列処理の、粒度が高
い制御を提供する。各パイプは、使用されるＨｙｐｅｒＯｐに応じて、１クロックあたり
複数の命令を実行できる。
【０２３０】
ＨｙｐｅｒＯｐに関する基本的な動機は、ＲＦ波形処理からＭＰＥＧ画像圧縮及び暗号
化までの例を用いた、幅広いアプリケーションソフトウェアのためのアセンブリコードの
分析に由来している。アセンブリ（ＡＳＭ）コードは「Ｃ」コードよりも効率的に実行さ
れることが多いが、最適ではなく、実行が非効率的となる場合も多数発生していた。本発
明者らは、アルゴリズムに関わる算術演算を実行するために使用されるＰＥサイクルの個
数に関して効率を定義している。データストリームを何らかの階層フォーマットに従って
解釈し、（例えば２Ｄフィルタを用いて）処理し、同一の又は別の階層フォーマットに従
って再度パッケージングしなければならない場合に、非効率が発生していた。他の場合に
は、様々なタイプ｛短い、整数、浮動、長い｝の間での変換を行うためにかかる時間が過
剰であった。これらの場合において、様々な寸法及び場合によっては可変サイズのアレイ
に保存されたデータを走査するために、ループを使用することが多い。ループアドレス計
算を、データの処理に使用されるものと同一のハードウェア上で実施する場合、アドレス
計算はループ遅延（オーバヘッド）を含む。
【０２３１】
更に、新規のデュアル／クアッドアーキテクチャは、より独立性の高い演算ユニットを
提供し、従って、１つ又は複数のパイプラインが含む並列演算又は迅速な順次演算に関し
て、より高い柔軟性及びより多くの機会を提供する。ＨｙｐｅｒＯｐ命令は、ＡＳＭフォ
ーマットに限定することなくこのハードウェアを制御する方法を提供する。独立したスロ
ットという観念は、この業界で使用されている超長命令語（ＶＬＩＷ）符号化スタイルか
ら借用したものである。ＶＬＩＷスタイルでは、命令内の特定のフィールドを、特定の機
能ユニットを制御するための「スロット」と呼ぶ。スロットのコーディングの独立性は、
機能ユニットの独立性に対応する。ＶＬＩＷスタイルの命令は、全ての機能ユニットに何
かを実施させない場合があるが、プログラマは一般に殆どのスロットに、プログラム内の
命令の殆どにとって有用な何かを実施させようとする。このようなＡＳＭ及びＶＬＩＷ符
号化スタイルのハイブリッドにより：
・プログラム可能なデータ経路の並列処理
・データ経路要素の独立した制御
が可能となる。
【０２３２】
ＨｙｐｅｒＯｐ命令は、標準的な符号化スキームを用いた場合には実行できない方法で
命令を並列処理及び加速できるように、実行パイプ演算、レジスタ、多重化の、より粒度
の高い制御を提供する。これにより、３つのＡＧＵ及び２つのデータ経路の独立した制御
が現行の実装形態において提供される。従来の符号化方法を用いて従来のパイプラインを
通過するに従ってオペランドに結び付けられたパイプラインレジスタが、このモードでプ
ログラマに提示される。これにより、メモリに保存する必要がない中間結果を有するタイ
トなループを遥かに効率的に実行でき、オペランドの移動及び整列を実行パイプラインか
ら切り離して、コンパイラによるパイプラインの最適化においてより高い柔軟性を提供で
きる。Ｅｒｒｏｒ！Ｒｅｆｅｒｅｎｃｅ  ｓｏｕｒｃｅ  ｎｏｔ  ｆｏｕｎｄ．これらの
レジスタは、図２０のＰＩＰＥ部分においてＸ、Ｙ、Ｚで標識されている。これらは常に
存在し、従来の命令によってハードウェアをパイプライン化するためにさえ使用される。
しかしながらＨｙｐｅｒＯｐモードでは、これらは、図示されている多重化ハードウェア
と共に、符号化される命令によって直接制御され、これにより、パフォーマンス及び電力
の最適化のための、粒度が極めて高いデータフローの制御が提供される。
【０２３３】
これは、更なるビットの符号化によって、追加のハードウェアに容易に拡張できる。図
２０はＰＥアーキテクチャの単なる一例である。
【０２３４】
５つの実行ユニットを制御するためのＨｙｐｅｒＯｐ命令に関するビットフィールドの
フォーマットの例を、図２７に示し、これは同様の命令セットの一般的な符号化を例示す
るものである。いくつかの高いビット数は、図２７に示すものとは異なる特別な命令フォ
ーマットを信号伝達できる。第１のフィールド（番号１２７）は、命令がマルチパート命
令に関しては１２８ビットで符号化され、又は単一パート命令に関しては６４ビットで符
号化されることをＰＥに信号伝達するために使用される。「ｃｏｎｄＥｘｅｃ」フィール
ドは、計算され、ＰＥにおいて状態として保存されている条件に基づく、命令の特定のフ
ィールドの条件付き実行を可能とするために使用される。３つの「ｔｙｐ」フィールドは
、制御情報の一部としてＡＧＵフィールドと組み合わせて使用される。アドレス生成ユニ
ット（Ｇ０、Ｇ１、Ｇ２）に関する２セットのフィールドは、これらのユニットそれぞれ
において実施される演算を制御する。最後の（ビット数が最も小さい）２つのフィールド
はそれぞれ、実行ユニット内の２つのパイプライン化されたデータ経路それぞれにおいて
実施されている演算を制御するための２０ビットフィールドである。
【０２３５】
最大５つの実行ユニットに関して、独立した制御が可能であることに留意されたい。各
ユニットは、スループットとして、１クロックあたり１つ以上の演算を実施できる。典型
的なＨｙｐｅｒＯｐは、１クロックあたり約８〜１２個の基本演算を制御できる。反復ハ
ードウェアの全てが使用中であり、かつロードを計数して、各１６ビットデータ語を「ｏ
ｐ」として保存する場合、このＨｙｐｅｒＯｐ命令フォーマットを用いて、１クロックあ
たり約３６個のｏｐを得ることができる。１．５ＧＨｚのクロック及び２５６個のＰＥ設
計点を用いると、これは略１４ＴＯＰＳ（テラ演算／秒）となる。
【０２３６】
これは、命令レベル並列処理を制御し、このような並列処理のスケジューリング及び最
適化をコンパイラ及びフォフトウェア開発ツールの領域に残すための、極めて効率的な方
法である。これにより、スーパースケーラタイプのスキームに比べてハードウェアを大幅
に小型化でき、上記スーパースケーラタイプのスキームは、ピークパフォーマンスに到達
するためのコンパイラ最適化が必要である一方で、オペランド、演算及び結果を完全に順
序変更及び最適化するために、実行時に遥かに多量のハードウェア及び電力も必要とする
。
【０２３７】
「ＦＩＲ」フィルタのための並列アセンブリ言語の例は、このフィルタがどのように作
用するかを理解する助けとなり得る。この並列アセンブリ言語の例は、コード部分Ｍにお
いて提供されるＡＮＳＩ  Ｃコードの例に対応する。「｜｜」の記号は、ＨｙｐｅｒＯｐ
符号化命令によって並列に実行される命令を隔てるものである。
// perform FIR filter on current sample data and produce sample out
// %bl points to structure com.com
// %b2 points to the coefficient array filter
// %dl points to structure com. result
// %il is index i
{ repeat1 $0, FILTER_LENGTH - 1, $4, %il, ACCO = 0;
|A| ldi com.com, %bl; |B| ldi filter, %b2; | C | void;
|D| void; |G| void; }
{ | A | ld64 0[%bl + %il], %AB; | B| void; | C | ld64 0[%b2 + %il] , %C;
|DP0| qmadd16 %AB , %C, %ACC0; |D| st32 %ACC0, %dl;
|G| void; }
コード部分Ｐ：ＡＮＳＩ  Ｃのコード部分Ｍに対応する、ＦＩＲフィルタ関数に関する並
列アセンブリ言語コード
【０２３８】
フェッチ／フロー制御
ハードウェアは、プリフェッチ法によってパイプラインに命令を供給し続ける、非常に
標準的な命令フェッチユニットを備えてよい。このフェッチユニットにはフロー制御が付
随し、これは命令に連結されて、特定の制御条件に対処するための効率的な方法を提供す
る。上記制御条件は以下を含む：
・オーバヘッドが低い様式でのループの加速のためのハードウェアの反復
・バッファリングの反復
・条件付き実行（マルチレベル）
【０２３９】
命令フェッチ／バッファリング
命令フェッチ及び復号化ユニットの例を図２８に示す。命令はＦＩＦＯ形式で命令バッ
ファ内に維持でき、出力は、保存された命令のシーケンスをもたらす現在の命令を含む。
【０２４０】
命令が発行されると、ＩＦＵは新規の命令アドレスを計算して命令メモリ（ＩＭ）を読
み出し、命令は命令バッファにロードされる。ＩＦＵは、例えば６４ｂと１２８ｂといっ
た、複数の長さが混ざった命令を処理してよい。これらはパディングを伴わずに命令メモ
リにパックされる。ＩＭからの第１の命令語（ＩＷ）は、命令の長さに関するコードを含
む。スタートアップ時、１２８ビットの命令が読み出される。そして命令の発行に続いて
適切なビット数が読み出され、これによって発行された命令の語を補充する。
【０２４１】
多数の命令を命令バッファに保存でき、典型的な例は８〜１６個である。この例では、
命令はシーケンスのまま維持され、順序変更されない。いくつかのマイクロプロセッサア
ーキテクチャでは動的順序変更が行われるが、これは複雑な論理を必要とし、相当な電力
を散逸させ得る。
【０２４２】
現在の命令が完了すると、この命令は「リタイア」し、次の命令が現在の命令として指
定され、これ以降も同様である。命令バッファに適合できる程度に十分に小さい命令のグ
ループは、ループ内で効率的に実行でき、またループが完了するまでいずれの追加のフェ
ッチも必要としなくてよい。反復ハードウェアプログラミングを用いてこれらのシーケン
スを検出し、バッファ内に適切な命令を保持する。これは、極めて電力効率の高い内側ル
ープを提供する。バッファ及び反復ハードウェアは、最大３深度（又は３次元ループ実行
）までのネスティングをサポートする。単一の命令の最も効率的な内側ループに関して、
この単一の命令は現在の命令として休止状態であり、ループカウントが満たされるまで、
単に復号化に対する制御を駆動する。これは、プログラム可能なアーキテクチャに関して
極めて電力効率が高い。
【０２４３】
反復バッファからの実行中、フェッチが必要ないため、電力を節約するために命令メモ
リを低電力状態とすることができる。関数の最も内側のループの命令の数は、ループの各
繰り返しのための実行時間において大きな因子であり、従って関数の速度、スループット
、帯域幅に反比例する。反復バッファの目的は、最も重要な内側ループがバッファに適合
するように、十分な深度（殆どの場合８又は１６個の命令）を提供することである。
【０２４４】
このハイブリッドアーキテクチャプロセスは、１つのＰＥについて一度に１つの命令を
処理し、従ってスケーラと呼ぶことができる（スーパースケーラではない）。しかしなが
らＨｙｐｅｒＯｐのサブ命令は独立して復号化され、従ってサブ命令の２つ以上のスレッ
ドを維持できる。最適化コンパイラツールは、ユーザプログラムを命令ストリームにコン
パイルした後、これをサブ命令の複数のスレッドに分割してより高い並列性を達成するこ
とにより最適化できる。データハザードを回避するためのルールを適用すると、命令スト
リームを最適化するために、個々のサブ命令を命令ストリーム内で前後に移動させること
ができる。サブ命令をロックしてロックステップで発行するこのような制限により、復号
器、制御及びフェッチユニットの複雑性は大幅に低減され、従って電力散逸が節減される
。
【０２４５】
反復
反復ハードウェアは、ＧＰＰの典型的な試験及び分岐方法よりも効率的なリアルタイム
ＤＳＰアルゴリズムのタイトな内側ループに対する、ハードウェア内でのルーピングを提
供するための機構である。
【０２４６】
反復ループハードウェアは：
・ゼロオーバヘッドループ形成のための内側ループのためのハードウェアの事前ロード
；
・１次インデックスレジスタを用いたネスティングの３つのレベルのサポート；
・４つの２次ベース／インデックスレジスタの自動インクリメント
を提供する。
【０２４７】
反復ループの関数は、以下のＣのようなコードによって示される：
do {
PC = TOP
while (PC <= BOTTOM_NEW)
execute instructions;
} while (CURRENT != END;
CURRENT += STRIDE)
コード部分Ｑ：反復ループの擬似コード
【０２４８】
このような演算を実装するためのハードウェアレジスタを表１に示す。これらのうちの
いくつかについては、アドレス計算の議論において既に議論した。反復ループのために使
用されるインデックス値は、処理されるデータのアレイに対するアドレスの計算に使用さ
れる場合が多いため、これらのレジスタはＡＧＵによってアクセス可能である。
【０２４９】
【表１】
2019145172.tif 000005
【０２５０】
６４ビット及び１２８ビット両方の符号化において、これらの必要なレジスタ全てを単
一のクロックでロードし、任意に反復ハードウェアを始動させるための、特別な命令が存
在してよい。ここで過去の世代を上回る１つの革新は、反復ハードウェアをロードして、
ループのＴＯＰアドレスに到達した時に上記反復ハードウェアが始動するよう準備するた
めの方法が含まれることである。これにより、３深度ループが得られ、内側の２つのルー
プは、外側のループの開始前にロードされる。これにより、内側ループに関する反復命令
のフェッチは行われず、従って内側ループはサイクルカウントに関してゼロオーバヘッド
ループとなる。
【０２５１】
このハードウェアを用いると、命令のセットに対して３深度ネスティングを実装でき、
ループは命令のために必要なクロックだけを用いて実行される。ループカウンタ、インク
リメント、比較、分岐、アドレス計算のためのサイクルオーバヘッドは不要である。これ
によりデータ経路ハードウェアを自由にし、アルゴリズムの算術部分のみに集中させるこ
とができる。
【０２５２】
図２９
図２９は、マルチパート命令の受信及び実行の第１の実施形態を示すフローチャートで
ある。
【０２５３】
本方法は、フェッチユニット及び複数のアドレス生成ユニットを備えるマルチプロセッ
サ装置において動作し得る。フェッチユニットは、マルチパート命令を受信するよう構成
されてよく、マルチパート命令は複数のフィールドを含む。複数のアドレス生成器ユニッ
トは、複数のフィールドのうちの第１のフィールドに応じた算術演算を実施するよう構成
された第１のアドレス生成器ユニットを備えてよい。複数のアドレス生成器ユニットはま
た、複数のアドレスのうちの少なくとも１つのアドレスを生成するよう構成された第２の
アドレス生成器ユニットを備えてよく、複数のアドレスそれぞれは、複数のフィールドそ
れぞれに依存する。マルチプロセッサ装置は更に、複数のアドレスのうちの第１のアドレ
スに応じた第１のデータを保存するよう構成された保存ユニットを備えてよい。更にフェ
ッチユニットは、複数のアドレスのうちの第２のアドレスに応じた第２のデータをフェッ
チするよう構成されてよい。マルチプロセッサ装置は更に、複数のアドレスのうちの少な
くとも１つの別のアドレスを生成するよう構成された第３のアドレス生成器ユニットを備
えてよい。更に、複数のフィールドのサブセットの各フィールドは、複数のアドレス生成
器ユニットそれぞれが実施する演算を符号化してよい。
【０２５４】
マルチパート命令を受信及び実行するための方法は、以下のように動作できる。
【０２５５】
まず２９０２において、プロセッサはマルチパート命令を受信してよく、このマルチパ
ート命令は複数のフィールドを含む。次に２９０４においてプロセッサは、複数のフィー
ルドのうちの第１のフィールドに応じた算術演算を実施してよい。２９０６においてプロ
セッサは更に、複数のフィールドそれぞれに応じて、複数のアドレスのうちの所定のアド
レスを生成してよい。
【０２５６】
追加の実施形態では、本方法は更に、複数のアドレスのうちの第１のアドレスに応じた
第１のデータを保存するステップを含んでよい。また本発明は更に、複数のアドレスのう
ちの第２のアドレスに応じた第２のデータをフェッチするステップも含んでよい。一実施
形態では、プロセッサは複数のアドレス生成器ユニットを含み、算術演算を実施するステ
ップは、複数のアドレス生成器ユニットのうちの少なくとも１つのアドレス生成器ユニッ
トを用いて上記算術演算を実施するステップを含む。更に一実施形態では、複数のフィー
ルドのサブセットの各フィールドは、複数のアドレス生成器ユニットそれぞれが実施する
演算を符号化してよい。
【０２５７】
図２９の方法は、複数のプロセッサと、例えばデータメモリルータ（ＤＭＲ）であって
よい、複数の動的に構成可能な通信要素とを備えるシステムにおいて動作でき、複数のプ
ロセッサ及び複数の動的に構成可能な通信要素は、散在型の配置において連結されてよい
。複数のプロセッサのうちの所定のプロセッサは：１）マルチパート命令を受信し（ここ
でマルチパート命令は複数のフィールドを含み）；２）複数のフィールドのうちの所定の
フィールドに応じた算術演算を実施し；３）複数のフィールドのサブセットに応じた複数
のアドレスを生成するよう構成されてよい。複数のプロセッサはそれぞれ、複数のアドレ
スのうちの第１のアドレスに応じた第１のデータを保存するよう、更に構成されてよい。
更に、複数のプロセッサのうちの所定のプロセッサは、複数のアドレスのうちの第２のア
ドレスに応じた第２のデータをフェッチするよう構成されてよい。
【０２５８】
更に、複数のプロセッサのうちの所定のプロセッサは、複数のアドレス生成器ユニット
を含んでよく、また複数のフィールドのサブセットの各フィールドは、複数のアドレス生
成器ユニットそれぞれが実施する演算を符号化してよい。
【０２５９】
図３０
図３０は、マルチパート命令の受信及び実行の第１の実施形態を示すフローチャートで
ある。
【０２６０】
本方法は、フェッチユニット及び実行ユニットを備えるマルチプロセッサ装置において
動作し得る。フェッチユニットは、マルチパート命令を受信するよう構成されてよく、マ
ルチパート命令は複数のデータフィールドを含む。実行ユニットは複数のパイプラインユ
ニットを含んでよく：１）複数のフィールドのうちの第１のフィールドに応じた、複数の
パイプラインユニットのうちの所定のパイプラインユニットを用いて、第１の演算を実施
し；２）複数のフィールドのうちの第２のフィールドに応じた、複数のパイプラインユニ
ットのうちの少なくとも２つのパイプラインユニットを並列に用いて、第２の演算を実施
するよう、構成されてよい。複数のパイプラインユニットはそれぞれ、複数の乗算器ユニ
ット及び複数の加算器ユニットを含んでよい。複数のパイプラインユニットはそれぞれ、
部分積の第１の数を部分積の第２の数へと圧縮するよう構成された圧縮器ユニットも含ん
でよい。複数のパイプラインユニットのうちの第１のパイプラインユニットの圧縮器ユニ
ットは、複数のパイプラインユニットの第２のパイプラインユニットの圧縮器ユニットか
ら少なくとも１つの部分積を受信するよう構成されてよい。また、複数のフィールドのサ
ブセットの各フィールドは、複数のパイプラインユニットそれぞれが実施する演算を符号
化してよい。
【０２６１】
マルチパート命令を受信及び実行するための方法は、以下のように動作できる。まず３
００２において、プロセッサはマルチパート命令を受信してよく、このマルチパート命令
は複数のフィールドを含む。次に３００４においてプロセッサは、複数のフィールドのう
ちの第１のフィールドに応じた、複数のパイプラインユニットのうちの所定のパイプライ
ンユニットを用いて、第１の演算を実施するステップを実施してよい。３００６において
プロセッサは、複数のフィールドのうちの第２のフィールドに応じた、複数のパイプライ
ンユニットのうちの少なくとも２つのパイプラインユニットを並列に用いて、第２の演算
を実施してよい。
【０２６２】
一実施形態では、複数のフィールドのサブセットの各フィールドは、複数のパイプライ
ンユニットそれぞれが実施する演算を符号化する。
【０２６３】
第２の演算を実施するステップは、複数のパイプラインユニットのうちの少なくとも２
つのパイプラインユニットのうちの第１のパイプラインユニットによって第１の部分積の
セットを生成するステップと、複数のパイプラインユニットのうちの上記少なくとも２つ
のパイプラインユニットのうちの第２のパイプラインユニットによって第２の部分積のセ
ットを生成するステップとを含んでよい。
【０２６４】
複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニットのうちの
第１のパイプラインユニットによる、第１の部分積のセットの生成は、部分積の第１の数
を部分積の第２の数へと圧縮するステップを含んでよく、第２の数は第１の数未満である
。複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット及び複数の加算器ユニ
ットを含んでよい。
【０２６５】
図３０の方法は、複数のプロセッサと、複数の動的に構成可能な通信要素、例えばＤＭ
Ｒとを備えるシステムにおいて動作できる。複数のプロセッサはそれぞれ複数のパイプラ
インユニットを含んでよい。複数のプロセッサ及び複数の動的に構成可能な通信要素は、
散在型の配置において連結されてよい。複数のプロセッサはそれぞれ：１）マルチパート
命令を受信し（ここでマルチパート命令は複数のフィールドを含み）；２）複数のフィー
ルドのうちの第１のフィールドに応じた、複数のパイプラインユニットのうちの所定のパ
イプラインユニットを用いて、第１の演算を実施し；３）複数のフィールドのうちの第２
のフィールドに応じた、複数のパイプラインユニットのうちの少なくとも２つのパイプラ
インユニットを並列に用いて、第２の演算を実施するよう構成されてよい。
【０２６６】
各プロセッサの複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット及び複
数の加算器ユニットを含んでよい。複数のプロセッサそれぞれの複数のパイプラインユニ
ットそれぞれは更に、部分積の第１の数を部分積の第２の数へと圧縮するよう構成された
圧縮器ユニットを含んでよい。各プロセッサの第１のパイプラインユニットの圧縮器ユニ
ットのうちの少なくとも１つは更に、各プロセッサの第２のパイプラインの別の圧縮器ユ
ニットから、少なくとも１つの部分積を受信するよう構成されてよい。
【０２６７】
一実施形態では、複数のフィールドのサブセットの各フィールドは、複数のパイプライ
ンユニットそれぞれが実施する演算を符号化する。
【０２６８】
図３１
図３１は、プロセッサによる演算の実施の一実施形態を示すフローチャートである。
【０２６９】
本方法は、命令を受信するよう構成されたフェッチユニットと、複数のパイプラインユ
ニットを含む実行ユニットとを備えるマルチプロセッサ装置において動作し得る。各パイ
プラインユニットはアキュムレータユニットを含んでよい。実行ユニットは：１）複数の
パイプラインユニットのうちの第１のパイプラインユニットを用いて、受信した命令に応
じた第１の演算を実施して結果を生成し；２）複数のパイプラインユニットのうちの第１
のパイプラインユニットのアキュムレータユニットに上記結果を保存し；３）複数のパイ
プラインユニットのうちの第１のパイプラインユニットのアキュムレータユニットに保存
された結果を、プロセッサのアキュムレータユニットに伝送するよう、構成されてよい。
複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット及び複数の加算器ユニッ
トを含んでよい。
【０２７０】
一例として、第１の演算は乗算演算を含んでよく、第１のパイプラインユニットのアキ
ュムレータユニットに結果を保存するために、実行ユニットは更に、第１のパイプライン
ユニットに、乗算演算の少なくとも１つの部分積を保存するよう構成されてよい。
【０２７１】
一実施形態では、命令は複数のフィールドを含んでよく、第１のパイプラインユニット
を用いて、受信した命令に応じた第１の演算を実施するために、実行ユニットは更に、第
１のパイプラインユニットを用いて、複数のフィールドのうちの第１のフィールドに応じ
た第１の演算を実施するよう構成されてよい。
【０２７２】
実行ユニットは更に、複数のフィールドのうちの第２のフィールドに応じた、複数のパ
イプラインユニットのうちの少なくとも２つのパイプラインユニットを並列に用いて、第
２の演算を実施するよう構成されてよい。
【０２７３】
演算を実施するための方法は、以下のように動作できる。
【０２７４】
３１０２において、本方法は、複数のプロセッサのうちの第１のプロセッサを用いて第
１の演算を実施するステップを含んでよい。第１のプロセッサは、第１の複数のアキュム
レータを含んでよく、第１の演算を実施するステップは、第１の複数のアキュムレータの
うちの所定のアキュムレータに値を保存するステップを含んでよい。
【０２７５】
３１０４において、本方法は、第１の複数のアキュムレータのうちの上記所定のアキュ
ムレータに保存された値を、複数のプロセッサのうちの第２のプロセッサが含む第２の複
数のアキュムレータのうちの所定のアキュムレータに伝送するステップを含んでよい。
【０２７６】
３１０６において、本方法は、第２の複数のアキュムレータのうちの上記所定のアキュ
ムレータに保存された値に応じた、複数のプロセッサのうちの第２のプロセッサを用いて
、第２の演算を実施するステップを含んでよい。
【０２７７】
一実施形態では、本方法は更に、第１のプロセッサによって第１のマルチパート命令を
受信するステップを含んでよく、第１のマルチパート命令は、第１の複数のフィールドを
含む。第１のプロセッサを用いて第１の演算を実施するステップは、第１の複数のフィー
ルドのうちの第１のフィールドに応じた、複数のプロセッサのうちの第１のプロセッサを
用いて、第１の演算を実施するステップを含んでよい。
【０２７８】
本方法は更に、複数のプロセッサのうちの第２のプロセッサによって第２のマルチパー
ト命令を受信するステップを含んでよく、第２のマルチパート命令は、第２の複数のフィ
ールドを含む。
【０２７９】
所定のアキュムレータに保存された値に応じた第２のプロセッサを用いて第２の演算を
実施するステップは、第２の複数のフィールドのうちの第１のフィールドに応じた第２の
プロセッサを用いて第２の演算を実施するステップを含んでよい。
【０２８０】
図３１の方法は、複数のプロセッサと、複数の動的に構成可能な通信要素、例えばＤＭ
Ｒとを備えるシステムにおいて動作できる。複数のプロセッサはそれぞれ複数のアキュム
レータユニットを備えてよい。複数のプロセッサ及び複数の動的に構成可能な通信要素は
、散在型の配置において連結されてよい。第１のプロセッサは：１）第１の命令を受信し
；２）第１の命令に応じた第１の演算を実施して結果を生成し；３）第１のプロセッサの
複数のアキュムレータユニットのうちの所定のアキュムレータユニットに上記結果を保存
し；４）第１のプロセッサの複数のアキュムレータユニットのうちの上記所定のアキュム
レータユニットに保存された結果を、複数のプロセッサのうちの第２のプロセッサの複数
のアキュムレータユニットのうちの所定のアキュムレータユニットに伝送するよう、構成
されてよい。
【０２８１】
複数のプロセッサのうちの第２のプロセッサは：１）第２の命令を受信し；２）第２の
命令と、複数のプロセッサのうちの第２のプロセッサの複数のアキュムレータユニットの
うちの上記所定のアキュムレータユニットに保存された値とに応じた第２の演算を実施す
るよう、構成されてよい。
【０２８２】
第１の命令は第１のマルチパート命令を含んでよく、第１のマルチパート命令は第１の
複数のフィールドを含み、第２の命令は第２のマルチパート命令を含み、第２のマルチパ
ート命令は第２の複数のフィールドを含む。第１の命令に応じた第１の演算を実施するた
めに、第１のプロセッサは更に、第１の複数のフィールドのうちの第１のフィールドに応
じた第１の演算を実施するよう構成されてよい。第２の命令及び所定のアキュムレータユ
ニットに保存された値に応じた第２の演算を実施するために、第２のプロセッサは更に、
第２の複数のフィールドのうちの第１のフィールドに応じた第２の演算を実施するよう構
成されてよい。
【０２８３】
図３２
図３２は、プロセッサによる演算の実施の一実施形態を示すフローチャートである。
【０２８４】
本方法は、フェッチユニットと、複数のアドレス生成器ユニットと、複数のバッファと
を備えるマルチプロセッサ装置において動作し得る。フェッチユニットはマルチパート命
令を受信するよう構成されてよく、マルチパート命令は複数のフィールドを含む。複数の
アドレス生成器ユニットのうちの第１のアドレス生成器ユニットは、第１のフィールドに
応じた第１の演算を実施して、結果を生成してよい。更に、複数のアドレス生成器ユニッ
トのうちの第２のアドレス生成器ユニットは、複数のフィールドのうちの第２のフィール
ド及び上記第１の結果に応じた第２の演算を実施するよう構成されてよい。
【０２８５】
一実施形態では、第１のバッファは、複数のフィールドのうちの少なくとも１つのフィ
ールドに応じた第１のストライド値を保存するよう構成され、第２のバッファは、複数の
フィールドのうちの少なくとも１つの別のフィールドに応じた第２のストライド値を保存
するよう構成される。
【０２８６】
複数のフィールドのうちの第１のフィールドに応じた第１の演算を実施するために、第
１のアドレス生成器ユニットは更に、第１のストライド値に応じた第１の演算を実施する
よう構成されてよい。
【０２８７】
演算を実施するための方法は、以下のように動作できる。本方法は、複数のアドレス生
成器ユニット及び複数のバッファを備えるプロセッサにおいて動作できる。
【０２８８】
３２０２において、本方法はマルチパート命令を受信してよく、このマルチパート命令
は複数のフィールドを含む。３２０４において、本方法は、複数のフィールドのうちの第
１のフィールドに応じた第１のアドレス生成器ユニットを用いて、第１の演算を実施して
よい。３２０６において、本方法は、複数のフィールドのうちの第２のフィールドと、第
１の結果とに応じた第２のアドレス生成器ユニットを用いて、第２の演算を実施してよい
。
【０２８９】
本方法は更に、複数のバッファのうちの第１のバッファに第１のストライド値を保存す
るステップ、及び複数のバッファのうちの第２のバッファに第２のストライド値を保存す
るステップを含んでよい。
【０２９０】
第１のフィールドに応じた第１のアドレス生成ユニットを用いて第１の演算を実施する
ステップは、第１のストライド値に応じた第１の演算を実施するステップを含んでよい。
【０２９１】
本方法は、複数のプロセッサと、複数の動的に構成可能な通信要素、例えばＤＭＲとを
備えるシステムにおいて動作できる。複数のプロセッサ及び複数の動的に構成可能な通信
要素は、散在型の配置において連結されてよい。複数のプロセッサのうちの所定のプロセ
ッサは：１）マルチパート命令を受信し（ここでマルチパート命令は複数のフィールドを
含み）；２）複数のフィールドのうちの第１のフィールドに応じた、複数の生成器のうち
の第１のアドレス生成器を用いて、第１の演算を実施して、第１の結果を生成し；３）複
数のフィールドのうちの第２のフィールドと上記第１の結果とに応じた、複数の生成器の
うちの第２のアドレス生成器を用いて、第２の演算を実施するよう構成されてよい。
【０２９２】
一実施形態では、複数のプロセッサはそれぞれ複数のバッファを含む。所定のプロセッ
サは更に、上記所定のプロセッサの複数のバッファのうちの第１のバッファに各第１のス
トライド値を保存するよう構成されてよい。所定のプロセッサは更に、上記所定のプロセ
ッサの複数のバッファのうちの第２のバッファに各第２のストライド値を保存するよう構
成されてよい。
【０２９３】
第１のフィールドに応じた第１のアドレス生成器を用いて第１の演算を実施するために
、所定のプロセッサは更に、各第１のストライド値に応じた第１の演算を実施するよう構
成されてよい。
【０２９４】
図３３
図３３は、プロセッサを動作させる一実施形態を示すフローチャートである。
【０２９５】
本方法は、フェッチユニットと、実行ユニットと、複数のアドレス生成器ユニットとを
備えるマルチプロセッサ装置において動作し得る。フェッチユニットは命令を受信するよ
う構成されてよい。実行ユニットは複数のパイプラインユニットを備えてよい。実行ユニ
ットは：１）命令がマルチパート命令であることの決定に応答して、複数のパイプライン
ユニットのうちの第１のパイプラインユニットを用いて第１の演算を実施し、マルチパー
ト命令は複数のフィールドを含み、第１の演算は、複数のフィールドのうちの第１のフィ
ールドに応じたものであり；２）複数のフィールドのうちの第２のフィールドに応じた、
複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニットを並列に用
いて、第２の演算を実施するよう、構成されてよい。
【０２９６】
実行ユニットは更に、命令が単一パート命令であることの決定に応答して、第１のパイ
プラインユニットを用いて第３の演算を実施するよう構成されてよい。命令が単一パート
命令であることの決定に応答して、複数のパイプラインユニットのうちの第１のパイプラ
インユニットを用いて第３の演算を実施するために、実行ユニットは更に、過去に受信し
たマルチパート命令に応じた、複数のパイプラインユニットのうちの第２のパイプライン
ユニットを用いて、第４の演算を実施するよう構成されてよい。第１のアドレス生成器は
、複数のフィールドのうちの第２のフィールドに応じた算術演算を実施するよう構成され
てよい。
【０２９７】
プロセッサを動作させるための方法は、以下のように動作できる。本方法は、複数のパ
イプラインユニットを備えるプロセッサにおいて動作できる。
【０２９８】
３３０２において、本方法は命令を受信してよい。
【０２９９】
３３０４において、本方法は、命令がマルチパート命令であることの決定に応答して、
第１のパイプラインユニットを用いて第１の演算を実施してよい。マルチパート命令は複
数のフィールドを含んでよく、第１の演算は複数のフィールドのうちの第１のフィールド
に応じたものであってよい。
【０３００】
３３０６において、本方法は、複数のフィールドのうちの第２のフィールドに応じた、
複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニットを並列に用
いて、第２の演算を実施してよい。
【０３０１】
本方法は更に、命令が単一パート命令であることの決定に応答して、第１のパイプライ
ンユニットを用いて第３の演算を実施してよい。第１のパイプラインユニットを用いて第
３の演算を実施するステップは、過去に受信したマルチパート命令に応じた、複数のパイ
プラインユニットのうちの第２のパイプラインユニットを用いて、第４の演算を実施する
ステップを含んでよい。
【０３０２】
本方法は更に、命令が単一パート命令であることの決定に応答して、第１のアドレスを
フェッチするステップを含んでよい。本方法はまた、複数のフィールドのサブセットに応
じた複数のアドレスを生成するステップも含んでよい。
【０３０３】
本方法は、複数のプロセッサと、複数の動的に構成可能な通信要素、例えばＤＭＲとを
備えるシステムにおいて動作できる。複数のプロセッサ及び複数の動的に構成可能な通信
要素は、散在型の配置において連結されてよい。複数のプロセッサはそれぞれ複数のパイ
プラインユニットを備えてよい。各プロセッサは：１）命令を受信し；２）命令がマルチ
パート命令であることの決定に応答して、複数のパイプラインユニットのうちの第１のパ
イプラインユニットを用いて第１の演算を実施し、ここでマルチパート命令は複数のフィ
ールドを含み、第１の演算は、複数のフィールドのうちの第１のフィールドに応じたもの
であり；３）複数のフィールドのうちの第２のフィールドに応じた、複数のパイプライン
ユニットのうちの少なくとも２つのパイプラインユニットを並列に用いて、第２の演算を
実施するよう構成されてよい。
【０３０４】
各プロセッサは更に、命令が単一パート命令であることの決定に応答して、第１のパイ
プラインユニットを用いて第３の演算を実施するよう構成されてよい。命令が単一パート
命令であることの決定に応答して、第１のパイプラインユニットを用いて第３の演算を実
施するために、各プロセッサは更に、過去に受信したマルチパート命令に応じた第２のパ
イプラインユニットを用いて、第４の演算を実施するよう構成されてよい。
【０３０５】
一実施形態では、各プロセッサは更に、複数のフィールドのサブセットに応じた複数の
アドレスを生成するよう構成される。各プロセッサは更に、複数のアドレスのうちの第１
のアドレスに応じた第１のデータを保存するよう構成されてよい。
【０３０６】
図３４
図３４は、複数のパイプラインユニットを有するプロセッサを動作させる第１の実施形
態を示すフローチャートである。
【０３０７】
本方法は、フェッチユニット及び実行ユニットを備える装置において動作し得る。フェ
ッチユニットは複数の命令を受信するよう、及び受信した複数の命令に応じた少なくとも
１つの反復命令シーケンスを識別するよう、構成されてよい。少なくとも１つの反復命令
シーケンスは、複数の命令のうちの少なくとも１つの命令を含んでよい。実行ユニットは
複数のパイプラインユニットを含んでよく、識別された反復命令シーケンスに応じた少な
くとも第１のサイクルに関して、複数のパイプラインユニットの第１のサブセットを選択
的に無効化するよう構成されてよい。実行ユニットは更に、識別された反復命令シーケン
スに応じた第２のサイクルに関して、複数のパイプラインユニットの第２のサブセットを
選択的に無効化するよう構成されてよい。例えば上記無効化は、複数のパイプラインユニ
ットのサブセットを低電力モードとするステップを含んでよい。装置は更に、複数のアド
レス生成器ユニット、フェッチユニット、保存ユニットを備えてよい。保存ユニットは、
上記少なくとも１つの反復命令シーケンスに応じた低電力モードに入るよう構成されてよ
い。フェッチユニットは、上記少なくとも１つの反復命令シーケンスに応じた低電力モー
ドに入るよう構成されてよい。複数のアドレス生成器ユニットのうちの少なくとも１つは
、上記少なくとも１つの反復命令シーケンスに応じた低電力モードに入るよう構成されて
よい。
【０３０８】
プロセッサを動作させるための方法は、以下のように動作できる。
【０３０９】
まず３４０２において、プロセッサは複数の命令を受信してよい。次に３４０４におい
てプロセッサは、受信した複数の命令に応じた少なくとも１つの反復命令シーケンスを識
別してよく、上記少なくとも１つの反復命令シーケンスは少なくとも１つの命令を含む。
３４０６においてプロセッサは、識別された反復命令シーケンスに応じた少なくとも第１
のサイクルに関して、複数のパイプラインユニットの第１のサブセットを選択的に無効化
してよい。３４０８においてプロセッサは、識別された反復命令シーケンスに応じた第２
のサイクルに関して、複数のパイプラインユニットの第２のサブセットを選択的に無効化
してよい。
【０３１０】
３４１０において、プロセッサは、上記少なくとも１つの反復命令シーケンスに応じた
保存ユニットを無効化してよい。あるいは、又はこれに加えて、３４１２においてプロセ
ッサは、上記少なくとも１つの反復命令シーケンスに応じたフェッチユニットを無効化し
てよい。あるいは、又はこれに加えて、３４１４においてプロセッサは、上記少なくとも
１つの反復命令シーケンスに応じた、複数のアドレス生成器ユニットのサブセットを、選
択的に無効化してよい。
【０３１１】
図３４の方法は、複数のプロセッサと、複数の動的に構成可能な通信要素とを備えるシ
ステムにおいて動作でき、複数のプロセッサ及び複数の動的に構成可能な通信要素は、散
在型の配置において連結されてよく、複数のプロセッサはそれぞれ複数のパイプラインユ
ニットを含んでよく、また：１）複数の命令を受信し；２）受信した複数の命令に応じた
少なくとも１つの反復命令シーケンスを識別し、ここで上記少なくとも１つの反復命令シ
ーケンスは、上記複数の命令のうちの少なくとも１つの命令を含み；３）識別された反復
命令シーケンスに応じた少なくとも第１のサイクルに関して、複数のパイプラインユニッ
トの第１のサブセットを選択的に無効化し；４）識別された反復命令シーケンスに応じた
第２のサイクルに関して、複数のパイプラインユニットの第２のサブセットを選択的に無
効化するよう構成されてよい。追加の実施形態では、複数のプロセッサはそれぞれ、複数
のアドレス生成器ユニット、フェッチユニット、保存ユニットを含んでよい。保存ユニッ
トと、フェッチユニットと、複数のアドレス生成器ユニットのうちの少なくとも１つとの
うちの１つ又は複数は、少なくとも１つの反復命令シーケンスに応じた低電力モードに入
るよう構成されてよい。
【０３１２】
以下の番号付き段落は、追加の実施形態を記載する。
【０３１３】
多数のデータ経路の制御
１．マルチパート命令を受信するよう構成されたフェッチユニットであって、上記マル
チパート命令は複数のデータフィールドを含む、フェッチユニットと；複数のパイプライ
ンユニットを含む実行ユニットであって、上記実行ユニットは：複数のフィールドのうち
の第１のフィールドに応じた、複数のパイプラインユニットのうちの所定のパイプライン
ユニットを用いて、第１の演算を実施し；複数のフィールドのうちの第２のフィールドに
応じた、複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニットを
並列に用いて、第２の演算を実施するよう構成される、実行ユニットとを備える、装置。
【０３１４】
２．複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット及び複数の加算器
ユニットを含む、実施形態１の装置。
【０３１５】
３．複数のパイプラインユニットはそれぞれ、部分積の第１の数を部分積の第２の数へ
と圧縮するよう構成された圧縮器ユニットを含む、実施形態１の装置。
【０３１６】
４．複数のパイプラインユニットのうちの第１のパイプラインユニットの圧縮器ユニッ
トは、複数のパイプラインユニットの第２のパイプラインユニットの圧縮器ユニットから
少なくとも１つの部分積を受信するよう構成される、実施形態４の装置。
【０３１７】
５．複数のフィールドのサブセットの各フィールドは、複数のパイプラインユニットそ
れぞれが実施する演算を符号化する、実施形態１の装置。
【０３１８】
６．プロセッサを動作させるための方法であって、このプロセッサは複数のパイプライ
ンユニットを含み、本方法は：マルチパート命令を受信するステップであって、このマル
チパート命令は複数のフィールドを含む、ステップ；複数のフィールドのうちの第１のフ
ィールドに応じた、複数のパイプラインユニットのうちの所定のパイプラインユニットを
用いて、第１の演算を実施するステップ；複数のフィールドのうちの第２のフィールドに
応じた、複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニットを
並列に用いて、第２の演算を実施するステップを含む、方法。
【０３１９】
７．複数のフィールドのサブセットの各フィールドは、複数のパイプラインユニットそ
れぞれが実施する演算を符号化する、実施形態６の方法。
【０３２０】
８．第２の演算を実施するステップは、複数のパイプラインユニットのうちの少なくと
も２つのパイプラインユニットのうちの第１のパイプラインユニットによって第１の部分
積のセットを生成するステップと、複数のパイプラインユニットのうちの上記少なくとも
２つのパイプラインユニットのうちの第２のパイプラインユニットによって第２の部分積
のセットを生成するステップとを含む、実施形態６の方法。
【０３２１】
９．複数のパイプラインユニットのうちの少なくとも２つのパイプラインユニットのう
ちの第１のパイプラインユニットによって、第１の部分積のセットを生成するステップは
、部分積の第１の数を部分積の第２の数へと圧縮するステップを含み、第２の数は第１の
数未満である、実施形態８の方法。
【０３２２】
１０．複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット及び複数の加算
器ユニットを含む、実施形態６の方法。
【０３２３】
１１．複数のプロセッサであって、この複数のプロセッサはそれぞれ複数のパイプライ
ンユニットを含む、複数のプロセッサと；複数の動的に構成可能な通信要素とを備える、
システムであって、複数のプロセッサ及び複数の動的に構成可能な通信要素は散在型の配
置において連結され、複数のプロセッサはそれぞれ：マルチパート命令を受信し（ここで
マルチパート命令は複数のフィールドを含み）；複数のフィールドのうちの第１のフィー
ルドに応じた、複数のパイプラインユニットのうちの所定のパイプラインユニットを用い
て、第１の演算を実施し；複数のフィールドのうちの第２のフィールドに応じた、複数の
パイプラインユニットのうちの少なくとも２つのパイプラインユニットを用いて、第２の
演算を実施するよう構成される、システム。
【０３２４】
１２．各プロセッサの複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット
及び複数の加算器ユニットを含む、実施形態１１のシステム。
【０３２５】
１３．複数のプロセッサそれぞれの複数のパイプラインユニットはそれぞれ、部分積の
第１の数を部分積の第２の数へと圧縮するよう構成された圧縮器ユニットを含む、実施形
態１１のシステム。
【０３２６】
１４．複数のプロセッサのうちの所定のプロセッサの複数のパイプラインユニットのう
ちの第１のパイプラインユニットの圧縮器ユニットは更に、複数のプロセッサのうちの所
定のプロセッサの複数のパイプラインユニットのうちの第２のパイプラインユニットの別
の圧縮器ユニットから、少なくとも１つの部分積を受信するよう構成される、実施形態１
３のシステム。
【０３２７】
１５．複数のフィールドのサブセットの各フィールドは、複数のパイプラインユニット
それぞれが実施する演算を符号化する、実施形態１１のシステム。
【０３２８】
累算の転送
１．命令を受信するよう構成されたフェッチユニットと；複数のパイプラインユニット
を含む実行ユニットとを備える、装置であって、上記複数のパイプラインユニットはそれ
ぞれアキュムレータユニットを含み、実行ユニットは：複数のパイプラインユニットのう
ちの第１のパイプラインユニットを用いて、受信した命令に応じた第１の演算を実施して
結果を生成し；複数のパイプラインユニットのうちの第１のパイプラインユニットのアキ
ュムレータユニットに上記結果を保存し；複数のパイプラインユニットのうちの第１のパ
イプラインユニットのアキュムレータユニットに保存された結果を、プロセッサのアキュ
ムレータユニットに伝送するよう、構成される、装置。
【０３２９】
２．複数のパイプラインユニットはそれぞれ、複数の乗算器ユニット及び複数の加算器
ユニットを含む、実施形態１の装置。
【０３３０】
３．第１の演算は乗算演算を含み、複数のパイプラインユニットの第１のパイプライン
ユニットのアキュムレータユニットに結果を保存するために、実行ユニットは更に、複数
のパイプラインユニットのうちの第１のパイプラインユニットに、乗算演算の少なくとも
１つの部分積を保存するよう構成される、実施形態１の装置。
【０３３１】
４．命令は複数のフィールドを含み、複数のパイプラインユニットのうちの第１のパイ
プラインユニットを用いて、受信した命令に応じた第１の演算を実施するために、実行ユ
ニットは更に、複数のパイプラインユニットのうちの第１のパイプラインユニットを用い
て、複数のフィールドのうちの第１のフィールドに応じた第１の演算を実施するよう構成
される、実施形態１の装置。
【０３３２】
５．実行ユニットは更に、複数のフィールドのうちの第２のフィールドに応じた、複数
のパイプラインユニットのうちの少なくとも２つのパイプラインユニットを並列に用いて
、第２の演算を実施するよう構成される、実施形態５の装置。
【０３３３】
６．複数のプロセッサを動作させるための方法であって、本方法は：複数のプロセッサ
のうちの第１のプロセッサを用いて第１の演算を実施するステップであって、第１のプロ
セッサは第１の複数のアキュムレータを含み、第１の演算を実施するステップは、第１の
複数のアキュムレータのうちの所定のアキュムレータに値を保存するステップを含む、ス
テップ；第１の複数のアキュムレータのうちの上記所定のアキュムレータに保存された値
を、複数のプロセッサのうちの第２のプロセッサが含む第２の複数のアキュムレータのう
ちの所定のアキュムレータに伝送するステップ；第２の複数のアキュムレータのうちの上
記所定のアキュムレータに保存された値に応じた、複数のプロセッサのうちの第２のプロ
セッサを用いて、第２の演算を実施するステップを含む、方法。
【０３３４】
７．第１のプロセッサによって第１のマルチパート命令を受信するステップを更に含み
、第１のマルチパート命令は、第１の複数のフィールドを含む、実施形態６の方法。
【０３３５】
８．第１のプロセッサを用いて第１の演算を実施するステップは、第１の複数のフィー
ルドのうちの第１のフィールドに応じた、複数のプロセッサのうちの第１のプロセッサを
用いて、第１の演算を実施するステップを含む、実施形態７の方法。
【０３３６】
９．複数のプロセッサのうちの第２のプロセッサによって第２のマルチパート命令を受
信するステップを含み、第２のマルチパート命令は、第２の複数のフィールドを含む、実
施形態８の方法。
【０３３７】
１０．第２の複数のアキュムレータのうちの所定のアキュムレータに保存された値に応
じた第２のプロセッサを用いて第２の演算を実施するステップは、第２の複数のフィール
ドのうちの第１のフィールドに応じた、複数のプロセッサのうちの第２のプロセッサを用
いて第２の演算を実施するステップを含む、実施形態９の方法。
【０３３８】
１１．複数のプロセッサであって、これら複数のプロセッサはそれぞれ複数のアキュム
レータユニットを含む、複数のプロセッサと；複数の動的に構成可能な通信要素とを備え
る、システムであって、複数のプロセッサ及び複数の動的に構成可能な通信要素は、散在
型の配置において連結され、複数のプロセッサのうちの第１のプロセッサは：第１の命令
を受信し；第１の命令に応じた第１の演算を実施して結果を生成し；第１のプロセッサの
複数のアキュムレータユニットのうちの所定のアキュムレータユニットに上記結果を保存
し；第１のプロセッサの複数のアキュムレータユニットのうちの上記所定のアキュムレー
タユニットに保存された結果を、複数のプロセッサのうちの第２のプロセッサの複数のア
キュムレータユニットのうちの所定のアキュムレータユニットに伝送するよう構成される
、システム。
【０３３９】
１２．複数のプロセッサのうちの第２のプロセッサは：第２の命令を受信し；第２の命
令と、複数のプロセッサのうちの第２のプロセッサの複数のアキュムレータユニットのう
ちの上記所定のアキュムレータユニットに保存された値とに応じた第２の演算を実施する
よう、構成される、実施形態１１のシステム。
【０３４０】
１３．第１の命令は第１のマルチパート命令を含み、第１のマルチパート命令は第１の
複数のフィールドを含み、第２の命令は第２のマルチパート命令を含み、第２のマルチパ
ート命令は第２の複数のフィールドを含む、実施形態１２のシステム。
【０３４１】
１４．第１の命令に応じた第１の演算を実施するために、複数のプロセッサのうちの第
１のプロセッサは更に、第１の複数のフィールドのうちの第１のフィールドに応じた第１
の演算を実施するよう構成される、実施形態１３のシステム。
【０３４２】
１５．第２の命令及び所定のアキュムレータユニットに保存された値に応じた第２の演
算を実施するために、複数のプロセッサのうちの第２のプロセッサは更に、第２の複数の
フィールドのうちの第１のフィールドに応じた第２の演算を実施するよう構成される、実
施形態１３のシステム。
【０３４３】
ＡＧＵカップリング（循環アドレス指定）
１．マルチパート命令を受信するよう構成されたフェッチユニット（ここでマルチパー
ト命令は複数のフィールドを含む）と；複数のアドレス生成器ユニットとを備える、装置
であって、複数のアドレス生成器ユニットのうちの第１のアドレス生成器ユニットは、複
数のフィールドのうちの第１のフィールドに応じた第１の演算を実施して、第１の結果を
生成し、更に、複数のアドレス生成器ユニットのうちの第２のアドレス生成器ユニットは
、複数のフィールドのうちの第２のフィールド及び上記第１の結果に応じた第２の演算を
実施する、装置。
【０３４４】
２．複数のバッファを更に備える、実施形態１の装置。
【０３４５】
３．複数のバッファのうちの第１のバッファは、複数のフィールドのうちの少なくとも
１つのフィールドに応じた第１のストライド値を保存するよう構成される、実施形態２の
装置。
【０３４６】
４．複数のバッファのうちの第２のバッファは、複数のフィールドのうちの少なくとも
１つの別のフィールドに応じた第２のストライド値を保存するよう構成される、実施形態
３の装置。
【０３４７】
５．複数のフィールドのうちの第１のフィールドに応じた第１の演算を実施するために
、複数のアドレス生成器ユニットのうちの第１のアドレス生成器ユニットは更に、第１の
ストライド値に応じた第１の演算を実施するよう構成される、実施形態３の装置。
【０３４８】
６．プロセッサを動作させるための方法であって、上記プロセッサは、複数のアドレス
生成器ユニットを含み、本方法は：マルチパート命令を受信するステップであって、この
マルチパート命令は複数のフィールドを含む、ステップ；複数のフィールドのうちの第１
のフィールドに応じた、複数のアドレス生成器ユニットのうちの第１のアドレス生成器ユ
ニットを用いて、第１の演算を実施するステップ；複数のフィールドのうちの第２のフィ
ールドと、第１の結果とに応じた、複数のアドレス生成器ユニットのうちの第２のアドレ
ス生成器ユニットを用いて、第２の演算を実施するステップを含む、方法。
【０３４９】
７．プロセッサは更に、複数のバッファを含む、実施形態６の方法。
【０３５０】
８．複数のバッファのうちの第１のバッファに第１のストライド値を保存するステップ
を更に含む、実施形態７の方法。
【０３５１】
９．複数のバッファのうちの第２のバッファに第２のストライド値を保存するステップ
を更に含む、実施形態８の方法。
【０３５２】
１０．複数のフィールドのうちの第１のフィールドに応じた、複数のアドレス生成器ユ
ニットのうちの第１のアドレス生成器ユニットを用いて第１の演算を実施するステップは
、第１のストライド値に応じた第１の演算を実施するステップを含む、実施形態７の方法
。
【０３５３】
１１．複数のプロセッサと；複数の動的に構成可能な通信要素とを備える、システムで
あって、複数のプロセッサ及び複数の動的に構成可能な通信要素は、散在型の配置におい
て連結され、複数のプロセッサのうちの所定のプロセッサは：マルチパート命令を受信し
、ここでマルチパート命令は複数のフィールドを含み；複数のフィールドのうちの第１の
フィールドに応じた、複数の生成器のうちの第１のアドレス生成器を用いて、第１の演算
を実施して、第１の結果を生成し；複数のフィールドのうちの第２のフィールドと上記第
１の結果とに応じた、複数の生成器のうちの第２のアドレス生成器を用いて、第２の演算
を実施するよう構成される、システム。
【０３５４】
１２．複数のプロセッサはそれぞれ複数のバッファを含む、実施形態１１のシステム。
【０３５５】
１３．複数のプロセッサのうちの所定のプロセッサは更に、上記所定のプロセッサの複
数のバッファのうちの第１のバッファに各第１のストライド値を保存するよう構成される
、実施形態１２のシステム。
【０３５６】
１４．複数のプロセッサのうちの所定のプロセッサは更に、上記所定のプロセッサの複
数のバッファのうちの第２のバッファに各第２のストライド値を保存するよう構成される
、実施形態１３のシステム。
【０３５７】
１５．複数のフィールドのうちの第１のフィールドに応じた、複数の生成器のうちの第
１のアドレス生成器を用いて第１の演算を実施するために、複数のプロセッサのうちの所
定のプロセッサは更に、各第１のストライド値に応じた第１の演算を実施するよう構成さ
れる、実施形態１３のシステム。
【０３５８】
単一パート／マルチパートの決定を有する命令の受信
１．命令を受信するよう構成されたフェッチユニットと；複数のパイプラインユニット
を含む実行ユニットとを備える、装置であって、実行ユニットは：命令がマルチパート命
令であることの決定に応答して、複数のパイプラインユニットのうちの第１のパイプライ
ンユニットを用いて第１の演算を実施し、マルチパート命令は複数のフィールドを含み、
第１の演算は、複数のフィールドのうちの第１のフィールドに応じたものであり；複数の
フィールドのうちの第２のフィールドに応じた、複数のパイプラインユニットのうちの少
なくとも２つのパイプラインユニットを並列に用いて、第２の演算を実施するよう、構成
される、装置。
【０３５９】
２．実行ユニットは更に、命令が単一パート命令であることの決定に応答して、複数の
パイプラインユニットのうちの第１のパイプラインユニットを用いて第３の演算を実施す
るよう構成される、実施形態１の装置。
【０３６０】
３．命令が単一パート命令であることの決定に応答して、複数のパイプラインユニット
のうちの第１のパイプラインユニットを用いて第３の演算を実施するために、実行ユニッ
トは更に、過去に受信したマルチパート命令に応じた、複数のパイプラインユニットのう
ちの第２のパイプラインユニットを用いて、第４の演算を実施するよう構成される、実施
形態２の装置。
【０３６１】
４．複数のアドレス生成器ユニットを更に備える、実施形態１の装置。
【０３６２】
５．複数のアドレス生成器のうちの第１のアドレス生成器は、複数のフィールドのうち
の第２のフィールドに応じた算術演算を実施するよう構成される、実施形態４の装置。
【０３６３】
６．プロセッサを動作させるための方法であって、プロセッサは複数のパイプラインユ
ニットを含み、本方法は；命令を受信するステップ；命令がマルチパート命令であること
の決定に応答して、複数のパイプラインユニットのうちの第１のパイプラインユニットを
用いて第１の演算を実施するステップであって、ここでマルチパート命令は複数のフィー
ルドを含み、第１の演算は複数のフィールドのうちの第１のフィールドに応じたものであ
る、ステップ；複数のフィールドのうちの第２のフィールドに応じた、複数のパイプライ
ンユニットのうちの少なくとも２つのパイプラインユニットを並列に用いて、第２の演算
を実施するステップを含む、方法。
【０３６４】
７．命令が単一パート命令であることの決定に応答して、複数のパイプラインユニット
のうちの第１のパイプラインユニットを用いて第３の演算を実施するステップを更に含む
、実施形態６の方法。
【０３６５】
８．複数のパイプラインユニットのうちの第１のパイプラインユニットを用いて第３の
演算を実施するステップは、過去に受信したマルチパート命令に応じた、複数のパイプラ
インユニットのうちの第２のパイプラインユニットを用いて、第４の演算を実施するステ
ップを含む、実施形態６の方法。
【０３６６】
９．命令が単一パート命令であることの決定に応答して、第１のアドレスをフェッチす
るステップを更に含む、実施形態６の方法。
【０３６７】
１０．複数のフィールドのサブセットに応じた複数のアドレスを生成するステップを更
に含む、実施形態６の方法。
【０３６８】
１１．複数のプロセッサであって、複数のプロセッサはそれぞれ複数のパイプラインユ
ニットを含む、複数のプロセッサと；複数の動的に構成可能な通信要素とを備える、シス
テムであって、複数のプロセッサ及び複数の動的に構成可能な通信要素は、散在型の配置
において連結され、複数のプロセッサはそれぞれ：命令を受信し；命令がマルチパート命
令であることの決定に応答して、複数のパイプラインユニットのうちの第１のパイプライ
ンユニットを用いて第１の演算を実施し、ここでマルチパート命令は複数のフィールドを
含み、第１の演算は、複数のフィールドのうちの第１のフィールドに応じたものであり；
複数のフィールドのうちの第２のフィールドに応じた、複数のパイプラインユニットのう
ちの少なくとも２つのパイプラインユニットを並列に用いて、第２の演算を実施するよう
、構成される、システム。
【０３６９】
１２．複数のプロセッサはそれぞれ、命令が単一パート命令であることの決定に応答し
て、複数のパイプラインユニットのうちの第１のパイプラインユニットを用いて第３の演
算を実施するよう、更に構成される、実施形態１１のシステム。
【０３７０】
１３．命令が単一パート命令であることの決定に応答して、複数のパイプラインユニッ
トのうちの第１のパイプラインユニットを用いて第３の演算を実施するために、複数のプ
ロセッサはそれぞれ、過去に受信したマルチパート命令に応じた、複数のパイプラインユ
ニットのうちの第２のパイプラインユニットを用いて、第４の演算を実施するよう、更に
構成される、実施形態１２のシステム。
【０３７１】
１４．複数のプロセッサはそれぞれ、複数のフィールドのサブセットに応じた複数のア
ドレスを生成するよう、更に構成される、実施形態１１のシステム。
【０３７２】
１５．複数のプロセッサはそれぞれ、複数のアドレスのうちの第１のアドレスに応じた
第１のデータを保存するよう、更に構成される、実施形態１１のシステム。
【０３７３】
反復ループ中のプロセッサの非使用部分の電力ダウン
１．複数の命令を受信するよう、及び受信した複数の命令に応じた少なくとも１つの反
復命令シーケンスを識別するよう、構成された、フェッチユニットであって、少なくとも
１つの反復命令シーケンスは、複数の命令のうちの少なくとも１つの命令を含む、フェッ
チユニットと；複数のパイプラインユニットを含む実行ユニットとを備える、装置であっ
て、上記実行ユニットは：識別された反復命令シーケンスに応じた少なくとも第１のサイ
クルに関して、複数のパイプラインユニットの第１のサブセットを選択的に無効化し；識
別された反復命令シーケンスに応じた第２のサイクルに関して、複数のパイプラインユニ
ットの第２のサブセットを選択的に無効化するよう、構成される、装置。
【０３７４】
２．複数のアドレス生成器ユニット、フェッチユニット、保存ユニットを更に備える、
実施形態１の装置。
【０３７５】
３．保存ユニットは、上記少なくとも１つの反復命令シーケンスに応じた低電力モード
に入るよう構成される、実施形態２の装置。
【０３７６】
４．フェッチユニットは、上記少なくとも１つの反復命令シーケンスに応じた低電力モ
ードに入るよう構成される、実施形態２の装置。
【０３７７】
５．複数のアドレス生成器ユニットのうちの少なくとも１つは、上記少なくとも１つの
反復命令シーケンスに応じた低電力モードに入るよう構成される、実施形態２の装置。
【０３７８】
６．プロセッサを動作させるための方法であって、プロセッサは複数のパイプラインユ
ニットを含み、本方法は：複数の命令を受信するステップ；受信した複数の命令に応じた
少なくとも１つの反復命令シーケンスを識別するステップであって、上記少なくとも１つ
の反復命令シーケンスは少なくとも１つの命令を含む、ステップ；識別された反復命令シ
ーケンスに応じた少なくとも第１のサイクルに関して、複数のパイプラインユニットの第
１のサブセットを選択的に無効化するステップ；識別された反復命令シーケンスに応じた
第２のサイクルに関して、複数のパイプラインユニットの第２のサブセットを選択的に無
効化するステップを含む、方法。
【０３７９】
７．プロセッサは、フェッチユニット、保存ユニット、複数のアドレス生成器ユニット
を更に含む、実施形態６の方法。
【０３８０】
８．上記少なくとも１つの反復命令シーケンスに応じた保存ユニットを無効化するステ
ップを更に含む、実施形態７の方法。
【０３８１】
９．上記少なくとも１つの反復命令シーケンスに応じたフェッチユニットを無効化ステ
ップを更に含む、実施形態７の方法。
【０３８２】
１０．上記少なくとも１つの反復命令シーケンスに応じた、複数のアドレス生成器ユニ
ットのサブセットを、選択的に無効化するステップを更に含む、実施形態７の方法。
【０３８３】
１１．複数のプロセッサであって、複数のプロセッサはそれぞれ複数のパイプラインユ
ニットを含む、複数のプロセッサと；複数の動的に構成可能な通信要素とを備える、シス
テムであって、複数のプロセッサ及び複数の動的に構成可能な通信要素は、散在型の配置
において連結され、複数のプロセッサはそれぞれ：複数の命令を受信し；受信した複数の
命令に応じた少なくとも１つの反復命令シーケンスを識別し、ここで上記少なくとも１つ
の反復命令シーケンスは、上記複数の命令のうちの少なくとも１つの命令を含み；識別さ
れた反復命令シーケンスに応じた少なくとも第１のサイクルに関して、複数のパイプライ
ンユニットの第１のサブセットを選択的に無効化し；識別された反復命令シーケンスに応
じた第２のサイクルに関して、複数のパイプラインユニットの第２のサブセットを選択的
に無効化するよう構成される、システム。
【０３８４】
１２．複数のプロセッサはそれぞれ、複数のアドレス生成器ユニット、フェッチユニッ
ト、保存ユニットを含む、実施形態１１のシステム。
【０３８５】
１３．保存ユニットは、少なくとも１つの反復命令シーケンスに応じた低電力モードに
入るよう構成される、実施形態１２のシステム。
【０３８６】
１４．フェッチユニットは、少なくとも１つの反復命令シーケンスに応じた低電力モー
ドに入るよう構成される、実施形態１２のシステム。
【０３８７】
１５．複数のアドレス生成器ユニットのうちの少なくとも１つは、少なくとも１つの反
復命令シーケンスに応じた低電力モードに入るよう構成される、実施形態１２のシステム
。
【０３８８】
様々な実施形態において、コンピュータ可読メモリ媒体は、ソフトウェアアプリケーシ
ョンのスワップに関わる機能等の上述の様々な機能を実装するためにＭＰＳのプロセッサ
及び／又は１つ若しくは複数の外部プロセッサによって実行可能なプログラム命令を記憶
してよい。一般に、コンピュータ可読メモリ媒体は、実行した場合に本出願に記載の機能
の一部分又は全てを実装する、命令のいずれのセットを含んでよい。一般にコンピュータ
可読メモリ媒体は、コンピュータシステムに命令及び／又はデータを提供するために使用
中にコンピュータがアクセスできる、いずれのストレージ媒体を含んでよい。例えばコン
ピュータ可読メモリ媒体は、磁気又は光媒体、例えばディスク（固定若しくは消去可能）
、テープ、ＣＤ‐ＲＯＭ、ＤＶＤ‐ＲＯＭ、ＣＤ‐Ｒ、ＣＤ‐ＲＷ、ＤＶＤ‐Ｒ、ＤＶＤ
‐ＲＷ又はＢｌｕ‐ｒａｙ（登録商標）といったストレージ媒体を含んでよい。ストレー
ジ媒体は更に、ユニバーサルシリアルバス（ＵＳＢ）インタフェース、フラッシュメモリ
インターフェイス（ＦＭＩ）、シリアルペリフェラルインタフェース（ＳＰＩ）等の周辺
インタフェースを介してアクセス可能な、ＲＡＭ（例えば同期ダイナミックＲＡＭ（ＳＤ
ＲＡＭ）、ラムバスＤＲＡＭ（ＲＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）等）、Ｒ
ＯＭ、フラッシュメモリ、不揮発性メモリ（例えばフラッシュメモリ）等の揮発性又は不
揮発性メモリ媒体を含んでよい。ストレージ媒体は、微小電気機械システム（ＭＥＭＳ）
、並びにネットワーク及び／又は無線リンク等の通信媒体を介してアクセス可能なストレ
ージ媒体を含んでよい。キャリア媒体は、コンピュータがアクセス可能なストレージ媒体
、及び有線又は無線伝送等の伝送媒体を含んでよい。
【０３８９】
好ましい実施形態との関連で以上の実施形態について説明したが、本明細書に記載した
具体的形態に上記好ましい実施形態を限定することは意図されておらず、反対に、添付の
請求項によって定義されるような本発明の精神及び範囲内に合理的に含まれ得るような代
替例、修正例、均等物を上記好ましい実施形態が包含することが意図されている。
【図１】
2019145172.tif 000006
【図２】
2019145172.tif 000007
【図３】
2019145172.tif 000008
【図４】
2019145172.tif 000009
【図５】
2019145172.tif 000010
【図６】
2019145172.tif 000011
【図７】
2019145172.tif 000012
【図８】
2019145172.tif 000013
【図９Ａ】
2019145172.tif 000014
【図９Ｂ】
2019145172.tif 000015
【図１０】
2019145172.tif 000016
【図１１】
2019145172.tif 000017
【図１２】
2019145172.tif 000018
【図１３】
2019145172.tif 000019
【図１４】
2019145172.tif 000020
【図１５】
2019145172.tif 000021
【図１６】
2019145172.tif 000022
【図１７】
2019145172.tif 000023
【図１８】
2019145172.tif 000024
【図１９】
2019145172.tif 000025
【図２０】
2019145172.tif 000026
【図２１】
2019145172.tif 000027
【図２２】
2019145172.tif 000028
【図２３】
2019145172.tif 000029
【図２４】
2019145172.tif 000030
【図２５】
2019145172.tif 000031
【図２６】
2019145172.tif 000032
【図２７】
2019145172.tif 000033
【図２８】
2019145172.tif 000034
【図２９】
2019145172.tif 000035
【図３０】
2019145172.tif 000036
【図３１】
2019145172.tif 000037
【図３２】
2019145172.tif 000038
【図３３】
2019145172.tif 000039
【図３４】
2019145172.tif 000040
【外国語明細書】
2019145172000001.pdf