(57)【要約】  マルチコア通信トポロジを生成する装置および関連する方法。マルチコアコンピュータの予め決められた数のコアに対応するトポロジが、アプリケーションプログラミングデバイスを用いて生成される。多くのノードが、マルチコア通信トポロジの予め決められた数の利用可能なコアに対するマッピングのために記述される。多くのノードの各々の特性が特定される。マルチコア通信トポロジのノードの各々間の通信が、アプリケーションプログラミングデバイスの電子メモリの専用のマルチコア通信ライブラリを用いて特定される。検証された出力ファイルは、アプリケーションプログラミングデバイスでマルチコアトポロジのために生成される。出力ファイルは、マルチコアコンピュータのためにマルチコア通信可能実行可能アプリケーションプログラムインターフェース（ＡＰＩ）を生成するように処理される。
2012520518.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラミングデバイスを有するマルチコアコンピュータの予め決められた数のコアに対応するマルチコア通信トポロジを生成する方法において、
マルチコア通信トポロジの予め決められた数の利用可能なコアに対するマッピングのために、多くのノードを記述するステップと、
多くのノードの各々の特性を特定するステップと、
アプリケーションプログラミングデバイスの電子メモリの専用のマルチコア通信ライブラリを用いて、マルチコア通信トポロジのノードの各々間での通信を特定するステップと、
マルチコアトポロジを処理して、マルチコアコンピュータのためのマルチコア通信可能実行可能アプリケーションプログラムインターフェース（ＡＰＩ）を生成するステップと
を有していることを特徴とする方法。
【請求項２】
前記ＡＰＩは、拡張マークアップ言語を用いて生成されることを特徴とする請求項１に記載の方法。
【請求項３】
前記拡張マークアップ言語のコードは、アプリケーションプログラミングデバイスのグラフィカルユーザインターフェース（ＧＵＩ）入力に対して供給される入力と協同して生成されることを特徴とする請求項１に記載の方法。
【請求項４】
前記通信ライブラリは、ＭＣＡＰＩ標準ＡＰＩをサポートすることを特徴とする請求項１に記載の方法。
【請求項５】
構成のためのグラフィカルユーザインターフェースは、様々なビューモードを含んでいることを特徴とする請求項３に記載の方法。
【請求項６】
前記ＡＰＩは、連続的に生成されて修正されるか、または別々に作成されて構成シーケンスの中間ステップとして挿入されることを特徴とする請求項１に記載の方法。
【請求項７】
生成されたＡＰＩは、ノード間の最短経路を有するトポロジを利用することを特徴とする請求項１に記載の方法。
【請求項８】
ノード間通信は、同期、非同期、接続、無接続、バッファ付、スカラ、パケット、またはストリーム通信であることを特徴とする請求項１に記載の方法。
【請求項９】
マルチコアトポロジのために検証された出力ファイルは、アプリケーションプログラミングデバイスで生成されることを特徴とする請求項１に記載の方法。
【請求項１０】
マルチコアコンピュータの予め決められた数のコアに対応するマルチコア通信トポロジを生成するためのコンピュータプログラム命令に従ってコンピュータに方法を実行させるために、協同して機能しているアプリケーション開発コンピュータによって実行可能なコンピュータプログラム命令によってコード化されたコンピュータ読み取り可能な記憶媒体において、
マルチコア通信トポロジの予め決められた数の利用可能なコアに対するマッピングのために、多くのノードを識別するステップと、
多くのノードの各々の特性を特定するステップと、
専用のマルチコア通信ライブラリを用いて、マルチコア通信トポロジのノードの各々間での通信を特定するステップと、
マルチコアトポロジを処理して、マルチコアコンピュータのためのマルチコア通信可能実行可能アプリケーションプログラムインターフェース（ＡＰＩ）を生成するステップと
をコンピュータに実行させることを特徴とする記憶媒体。
【請求項１１】
前記ＡＰＩは、拡張マークアップ言語を用いて生成されることを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１２】
前記拡張マークアップ言語のコードは、アプリケーション開発コンピュータのグラフィカルユーザインターフェース（ＧＵＩ）入力に対して供給される入力と協同して生成されることを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１３】
前記通信ライブラリは、ＭＣＡＰＩ標準ＡＰＩをサポートすることを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１４】
構成のためのグラフィカルユーザインターフェースは、様々なビューモードを含んでいることを特徴とする請求項１２に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１５】
前記ＡＰＩは、連続的に生成されて修正されるか、または別々に作成されて構成シーケンスの中間ステップとして挿入されることを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１６】
生成されたＡＰＩは、ノード間の最短経路を有するトポロジを利用することを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１７】
ノード間通信は、同期、非同期、接続、無接続、バッファ付、スカラ、パケット、またはストリーム通信であることを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【請求項１８】
マルチコアトポロジのための検証された出力ファイルを生成するステップをコンピュータに実行させる命令を更に含むことを特徴とする請求項１０に記載のコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
現在記載されている提案は、マルチコアプロセッサインターフェース機能およびトポロジに関し、より詳しくは、減少したエネルギ使用および増加した動作速度を提供するために生成されたトポロジを強化するマルチコアプロセッサインターフェース、および関連する方法に関する。
【背景技術】
【０００２】
ここに提供される「背景」説明は、発明の分野の状況を一般的に示すためである。このセクションに記載されている範囲の現在挙げられている発明者の仕事は、背景説明の態様と同様に、出願時の従来技術と認めたわけではない。明示的または黙示的に従来技術として認めたわけではなく、ここに請求される提案の総合的な状況を教示するという精神において提供される。
【０００３】
ソフトウェアは、複雑さが増加し、資源の消費も増加したので、ハードウェアプラットフォーム上での対応する要求が生み出されている。この要求に答える際に、シングルコアプロセッサおよびムーアの法則を避けられない性能は、対応する処理パワーの増加による（すなわち、クロック速度を上げることによる）ペースを保つための能力を制限してきた。この課題を解決するために、性能の向上を達成するために同じ基板上で２つ以上のプロセッサが用いられるように、マルチプロセッサ構成（architectures）が開発された。これらのマルチプロセッサ構成は、「マルチコア」として知られている。マルチコアプロセッサは、処理性能を増加させる一方で、プロセッサの設置面積を減らし、より良好な電力消費および熱特性を提供する。
【０００４】
まだ、大部分の従来のアプリケーションソフトウェアは、シングルプロセッサ用に記述されている。このようなアプリケーションソフトウェアは、組み込まれたマルチコアコンピュータ上で自動的により速く動作するわけではない。事実、それは全く動作しない可能性もある。これは、ソフトウェアがマルチスレッドの場合であっても起こり得る。シングルプロセッサにおいて、スレッドは、順次動作する。これに対して、マルチコアコンピュータにおいては、それらは、同時に動作し得るので、シングルプロセッサの場合には見られなかった同期の問題を露呈させる。マルチスレッドコードのプログラミングは、しばしばスレッドの複雑な連係を必要とし、簡単にバグが導入される可能性があり、それは、スレッド間で共有されるデータ上での処理のインターリービングのために、見つけるのが非常に困難である。更に事態を難しくすることには、スレッドは、理想的には、最大の利益（性能および電力消費）を達成するために、均等にコアをロードする方法で、複数のコアに分配される。
【０００５】
マルチコアチップ設計上に増加する重みが与えられると、これらの新規なチップを利用するためにソフトウェアをマルチスレッド化することができる範囲は、当面はコンピュータの性能上での単一の最も大きな制約になりそうである。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
現在、上述した不備がなく、マルチコアプロセッサアプリケーションに対して最適化された通信トポロジを提供する移植可能なＡＰＩの必要がある。
【課題を解決するための手段】
【０００７】
本発明の一態様において、マルチコア通信トポロジを生成する装置および関連する方法が提供される。このトポロジは、アプリケーションプログラミングデバイスで生成される、マルチコアコンピュータの予め決められた数のコアに対応する。マルチコア通信トポロジの予め決められた数の利用可能なコアに対するマッピングのために、多くのノードが記述される。多くのノードの各々の特性が特定される。マルチコア通信トポロジのノードの各々間の通信が、アプリケーションと結合されたアプリケーションプログラミングデバイスの電子メモリの専用のマルチコア通信ライブラリを用いて特定される。検証された出力ファイルが、アプリケーションプログラミングデバイスでマルチコアトポロジのために生成される。この出力ファイルは、マルチコアコンピュータのためのマルチコア通信可能実行可能アプリケーションプログラムインターフェース（ＡＰＩ）を生成するために処理される。
【０００８】
本発明の前述の一般的説明および以下の詳細な説明は、例示のためであり、本発明を限定するためではないことは理解されるべきである。
【０００９】
ここに請求される提案およびその多くの効果のより完全な理解が、たやすく得られるであろう。なぜなら、同じことが、添付の図面と関連して考慮されるときに、以下の詳細な説明を参照することでよりよく理解されるからである。しかしながら、添付の図面およびそれらの例示的な描写は、この明細書に含まれている提案の範囲をいかなる形であれ制限しない。明細書および図面に含まれている提案の範囲は、添付の請求項の語によって定義される。
【図面の簡単な説明】
【００１０】
【図１】本発明の例示的実施形態による代表的なマルチコアプロセッサ構成の高水準ブロック図である。
【図２】本発明の例示的実施形態のマルチコアトポロジ生成器のモジュラ構成の処理フロー図である。
【図３】本発明の例示的実施形態による例示的な相互接続トポロジのノードのブロック図である。
【図４】本発明の例示的実施形態による開発者ステーションのＧＵＩに示されるプロジェクトエディタの例示的なスクリーンショットである。
【図５】本発明の例示的実施形態による開発者ステーションのＧＵＩに示されるノードトポロジの例示的なスクリーンショットである。
【図６】本発明の例示的実施形態による開発者ステーションのＧＵＩに示される図５のノードトポロジに対する修正を示す例示的なスクリーンショットである。
【図７】本発明の例示的実施形態による開発者ステーションのＧＵＩに示されるノード資源割り当ての例示的なスクリーンショットである。
【図８】本発明の例示的実施形態による開発者ステーションのＧＵＩに示されるノードリンクパラメータ割り当ての例示的なスクリーンショットである。
【図９】本発明の例示的実施形態による開発者ステーションのＧＵＩに示されるツリー構造のトポロジ概観の例示的なスクリーンショットである。
【図１０】本発明の例示的実施形態による開発者ステーションのＧＵＩに示されるトポロジマップ検証の例示的なスクリーンショットである。
【図１１】本発明の例示的な実施形態による開発者ステーションのＧＵＩに示されるＸＭＬベースのトポロジマップの例示的なスクリーンショットである。
【図１２】本発明の例示的実施形態による例示的な実行可能なＣ言語ベースのトポロジである。
【発明を実施するための形態】
【００１１】
ここに記載されている技術の提案は、「マルチコア通信トポロジ生成器」（ＭＣＴＧ）を用いて、文字通り、例えば拡張マークアップ言語（ＸＭＬ）を用いてマルチコアプロセッサコンピュータのコア上に分配される予め定義された数のノードを有するマルチコア通信トポロジを生成する。
【００１２】
以下の説明において使用する特定の用語は、便宜だけのためであり、限定するものではない。用語「マルチコアプロセッサコンピュータ」は、ここでは、単一のシリコンダイの中に集積された２つ以上の独立したコアを走らせるコンピュータ、または集積されたパッケージの中にまたは１つ以上のプリント回路基板（ＰＣＢ）上に組み付けられた２つ以上のコアを有するコンピュータを指すために用いられる。市販の例示的なマルチコアプロセッサコンピュータは、ニューヨークのアーモンクのIBMからのPowerPC（登録商標）およびCell Processor、カリフォルニアのサンタクララのインテルからのXeon（登録商標）、およびテキサスのダラスのテキサスインスツルメンツからのOMAP（登録商標）を含む。同様に、「コア」は、ここでは、マイクロプロセッサの中心部を指すために用いられ、これは、ＣＰＵ（中央演算処理装置）、ＤＳＰ（デジタルシグナルプロセッサ）、ＧＰＵ（図形処理ユニット）、または他の専用プロセッサであってもよい。「ノード」は、ここでは、ネットワークに付けられたオブジェクトを指すために用いられ、通信チャネル上の情報を送信、受信、または転送することができる。そして、それは、多くのエンティティにマッピングされ得る論理的抽象概念であり、プロセス、スレッド、オペレーティングシステムのインスタンス、ハードウェアアクセラレータ、またはプロセッサコアを含むが、これらに限られるわけではない。
【００１３】
２つの別個のタイプのマルチコアプロセッサがあり、これらは汎用およびアプリケーションに焦点を合わせたマルチコアプロセッサである。
【００１４】
汎用マルチコアプロセッサは、複数の通常は同じコアを有するプロセッサであり、コアのいずれも、アプリケーション内での処理ニーズを提供するために用いられ得る。対照的に、アプリケーションに焦点を合わせたマルチコアプロセッサは、アプリケーションの異なる部分のために異なるコアを備えている。例えば、１つのコアは、音声/映像を処理することができると共に、他のコアは、入/出力デバイスを管理する。
【００１５】
マルチコアプロセッサの使用によって得られる性能の量は、解決される問題および用いられるアルゴリズム、およびソフトウェアおよびハードウェア構成の中でのそれらの実現による。アプリケーションソフトウェアは、コードが並列に実行され得る時に、マルチコア構成から利益を得る。
【００１６】
ここで図１を参照すると、組込型マルチコアプロセッサコンピュータ２は、しばしばリアルタイムコンピューティングの制約を有する１または２、３の専用の機能を実行するように設計された複数のプロセッサコア４から成る特定目的のコンピュータシステムである。図１に、２つの４コアプロセッサが示されている。マルチコアプロセッサは、通常、関連するハードウェアおよび機械部品を含む完全な装置の一部として組み込まれる。複数のコアは、１つの単一チップ上にあってもよいし、複数のチップ上にあってもよいし、両方であってもよい。コンピュータは、システムの電源を入れる時に同じ数のコアが物理的に存在することを意味する静的トポロジを有している（プロセッサの数を変える動的トポロジ、例えばインターネットと対照的に）。
【００１７】
通常、マルチコア結合からのマルチコア通信ＡＰＩ（ＭＣＡＰＩ）は、マルチコアコンピュータシステム内に密に分配されたコアおよび／またはプロセッサ間での通信および同期のための標準化されたＡＰＩを提供する。ＭＣＡＰＩの目的は、通信および同期の基本構成要素を捕獲することであり、これは、密に分配された組込型システムのために必要である。このようなＡＰＩのためのターゲットシステムは、複数の次元の異質性（例えば、コアの異質性、相互接続の異質性、メモリの異質性、オペレーティングシステムの異質性、ソフトウェアツールチェーンの異質性、およびプログラミング言語の異質性）にわたる。
【００１８】
ＭＣＡＰＩ標準は、プロセス指向およびスレッド指向システム上で実行されることを意図している。ＭＣＡＰＩは、『ノード』間にトランスポート層を定義し、これは、プロセス、スレッド、またはいくつかの他の制御スレッド（thread-of-control）抽象概念であり得る。標準は、特定の共有メモリモデルまたはプロセス保護モデルに対する依存を持つことを明確に避ける。ＭＣＡＰＩによって定義される通信動作は、理想的には、スレッドまたはプロセスベースのシステム上で同一のセマンティックスによって実行される。従って、ＭＣＡＰＩ構文だけを用いるプログラムは、ＭＣＡＰＩインプリメンテーション間で移植可能でなければならない。他方、ＭＣＡＰＩ外のＡＰＩを利用するプログラム、例えばｐスレッドは、それらの追加のＡＰＩを含むシステム間でのみ移植可能である。
【００１９】
図２に示すように、例示的実施形態のＭＣＴＧのモジュラ構成は、モジュールに分けられている。すなわち、アプリケーション準備１０、トポロジ−マップ作成１５、トポロジ定義作成２０、マルチコアアプリケーションを構築する２５、アプリケーションをテストする３０。このモジュラ構成は、設置面積（footprint）をできるだけ小さく保つ一方で、様々なシステム要求を収容するために、特定の機能を加えること、および除去することをより簡単にする。トポロジ構成とランタイム通信アプリケーションを分離することによって、モジュールは、構成時間に異なるコア４に再マッピングされ得る。そして、トポロジ資源および構成は、アプリケーションソースコードの修正なしで、修正かつ最適化され得る。当業者なら認めるであろうが、モジュラソフトウェアは、分割され得るし、または、１つのシステムパッケージまたはそれらの組み合わせに統合され得る。
【００２０】
開発中のプラットフォームは、図２のＭＣＴＧの処理フローを、汎用プロセッサおよびオペレーティングシステム、例えばマイクロソフトビスタ（登録商標）、ユニックス、ソラリス、リナックス（登録商標）、アップルＭＡＣ−ＯＳおよび当業者に公知の他のシステムと連動して実行するユーティリティアプリケーションとして実行する。例示の実施形態において、開発者ステーションはＧＵＩを備えている。
【００２１】
使用中、アプリケーションプログラマは、ＭＣＴＧへの入力のための所望のノードの数を決定する。決定は、並列実行可能性に基づいている。そして、アプリケーションプログラムおよびハードウェア構成における機能モジュールの分析に基づいて、コア２へのノードのマッピングを仮定する。ノードは、作成され、構成され、通信トポロジを備えるコア２にリンクかつマッピング（結合）される。ツールによって援助されるトポロジ作成が、視覚的になされ、構築され、ＸＭＬベースのモデルをスケーラブルに用い、更にここに記載されているターゲットの組込型マルチコアプロセッサコンピュータに固有のランタイムライブラリコンポーネントを用いる。この方法は、アプリケーション機能と基礎をなすトポロジの分離を提供し、アプリケーションプログラミング過程を簡単にする。
【００２２】
より詳しく図２を参照すると、５つの別々のブロックが、例示的実施形態においてマルチコア通信トポロジが構築され、構成され、かつ検証される方法を含むアプリケーション構成動作の流れを表している。アプリケーショントポロジおよびランタイム通信ライブラリは、図１に示したようなマルチコアコンピュータハードウェア上にマッピングされる。
【００２３】
ブロック１０、アプリケーション準備で、修正され、構成され、かつマルチコアハードウェア上で動作するために最適化かつ検証されたマルチコアトポロジと結合されるアプリケーションプログラムに関する知識をもつプログラマは、開発者ステーションでソフトウェアを検査し、分析し、修正し、かつ構成する。
【００２４】
この分析は、応答時間、スループットおよび電力消費に関する特定の性能要求に加えて、並列処理および同時処理の可能性を判定する。これは、以下のものに限定されるわけではないが、アプリケーション機能のモジュール性、異なる機能間でのデータ依存性を含む。それは、異なる機能間で共有されるデータ構造、および、それらが、データ破壊またはプログラムデッドロックを引き起こし得る競争状態を引き起こし得るかどうかを見つけることを含む。プロファイリングツールを用いて、または類似の機能を提供するシミュレータを用いて、アプリケーションの最も計算に強い機能を見つけるために、プロファイリングが用いられる。プログラマは、アプリケーションを機能モジュールに分割し、通信が、これらのモジュールを使用可能にする（通信プリミティブ（primitive）が挿入される）。アプリケーション機能モジュールが標準開発ツールを用いて構築され、オブジェクトファイルになる。アプリケーション分析、アプリケーション分割、およびターゲットマルチコアコンピュータに基づいて、プログラマは、アプリケーションの最適なマッピングの方法および通信トポロジを作成しかつ構成する方法を推定して、性能と資源要求のバランスをとる。
【００２５】
ブロック１５、トポロジマップ作成で、トポロジが作成され、ノード（およびリンク）が加えられ、かつ構成される。ノードおよびリンク資源、およびマルチコアコンピュータに対するそれらの結合が、段階的な手順の中に示されているように構成される。一旦トポロジが完了されると、それは検証されかつ保存され、ＸＭＬベースのトポロジマップが生成される。ＸＭＬトポロジマップは、ＸＭＬビューの中で直接見ることもできる。ＸＭＬトポロジマップは、テキストエディタを介して編集され得るし、または他のアプリケーションによって処理され得る。
【００２６】
ブロック２０、トポロジ定義作成で、トポロジマップは、解析され、検証され、ノード間の最短経路が算出され、静的ルーティングテーブルに文書化される。定義、ルーティングテーブル、予め割り当てられたデータ構造、および予め定義された初期化ルーチンを含むトポロジ定義が、開発者ステーションを用いて作成される。通信トポロジは静的で、モデルベースで、かつ予め定義されるので、それは検証され得る。
【００２７】
ブロック２５、マルチコアアプリケーションを構築するで、トポロジ定義が、コンパイラおよびアセンブラのような標準開発ツールを用いて構築される。例示的実施形態において、生成されたトポロジは、Ｃプログラミング言語に基づいてアプリケーションに構築されるが、当業者なら認めるであろうが、他のオブジェクト指向構文も、この説明の範囲に含まれる。このような方法で、トポロジは、先に構築されたアプリケーションおよび通信ランタイムライブラリとリンクされる。
【００２８】
ブロック３０、アプリケーションをテストするで、生成されたアプリケーションは、標準デバッギングツールを用いて、正当性および性能のためにデバッグされる。アプリケーションは、アプリケーション要求、機能、性能に対して検証される。重要な要求は、アプリケーションプログラム速度および電力消費であり得る。
【００２９】
図２のブロックは、単一のパスの説明を示すだけの例示の実施形態を構成しているが、もちろん当業者なら認めるであろうが、代替実施形態、例えば反復的な実施形態も、この構成に含まれる。このような反復的な実施形態は、いくつかのトポロジ仮定および最適なマルチコアトポロジを得るための最適化アルゴリズムを走らせることによって、最適な性能を捜すことができる。反復的な実施形態は、アプリケーションソフトウェアと共に意図されたマルチコアハードウェアに対する通信機能の最適化を提供する。
【００３０】
任意のプロセスの説明またはフローチャート内のブロックは、モジュール、セグメント、コードの部分を表すものとして理解されるべきであり、それは、そのプロセスの中で特定の論理的機能またはステップを実行するための１つ以上の実行可能な命令を含む。そして、示されたかまたは述べられたものから外れた順序で機能が実行され得る代替の実施態様も、本発明の例示的実施形態の範囲内に含まれる。これは、当業者なら理解するであろうが、関係する機能に応じて、実質的に同時に、または逆の順序で機能が実行され得る実施態様も含んでいる。
【００３１】
アプリケーションプログラムに関する知識をもつプログラマが、開発者ステーションを用いてアプリケーションソフトウェアを検査し、分析し、修正し、かつ構成する。再び図２を参照すると、ステップ１０ａにおいて、プログラマが、並列処理および同時処理に対する可能性を見つけるために、アプリケーションを分析する。それは、以下のものに限定されるわけではないが、アプリケーション機能のモジュール性、異なる機能間でのデータ依存性を含み、それは、異なる機能間で共有されるデータ構造を発見すること、および、それらが、応答時間、スループットおよび電力消費に関する特定の性能要求に加えて、データ破壊またはプログラムデッドロックを引き起こし得る競争状態を引き起こし得るかどうかを発見することを含む。プロファイリングツールまたは類似の機能を提供するシミュレータを用いて、アプリケーションの最も計算に強い機能を発見するために、プロファイリングが用いられる。機能の相対的な計算負荷は、分析されて、トポロジ仮定の基準の一部になる。ステップ１０ｂにおいて、プログラマは、アプリケーションを機能モジュールに分割し、通信がモジュールを使用可能にする（通信プリミティブが挿入される）。
【００３２】
【数１】
2012520518.tif 000003
【００３３】
図１の例としてのマルチコアハードウェアを用いて、図３に示すような９つの別個の機能Ｆ１〜Ｆ９を有する例としてのアプリケーションが提供される。図１のマルチコアハードウェアプラットフォームは、それぞれ４つの（均一な）コア４を有する２つのチップ２を有するものとして示されている。開発者の目的は、与えられた電力消費予算の中での最大スループットのために、アプリケーションの負荷を８つのコアに均一に分散させることである。Ｆ１は、前処理機能であり、Ｆ２、Ｆ３およびＦ５は、計算機能であり、Ｆ４、Ｆ７およびＦ９は、例外処理機能であり、Ｆ６およびＦ８は、後処理機能である。機能の相対的な計算負荷は、分析され、機能またはノードは、それに従ってコアに割り当てられる。
【００３４】
ブロック１０において、アプリケーション機能モジュールは、標準開発ツールを用いて構築され、オブジェクトファイルになる。アプリケーションの複数の態様が、アプリケーション開発者によって分析される。これらの態様は、以下のものに限定されるわけではないが、アプリケーション機能のモジュール性、異なる機能間でのデータ依存性を含み、それは、異なる機能間で共有されるデータ構造を発見すること、および、それらが、応答時間、スループットおよび電力消費に関する特定の性能要求に加えて、データ破壊またはプログラムデッドロックを引き起こし得る競争状態を引き起こし得るかどうかを発見することを含む。プロファイリングツールまたは類似の機能を提供するシミュレータを用いて、アプリケーションの最も計算に強い機能を発見するために、プロファイリングが用いられる。例示的実施形態において、それは、最初にアプリケーションのプロファイルを描くために有用であり、アプリケーションの最も計算に強い機能に焦点を合わせる。なぜなら、それらは、他のコアへの再マッピングのための第１の候補であるからである。ステップ１０ｂ〜１０ｃにおいて、アプリケーションの分析の結果は、ノードのコアに対する最適マッピングを推定するために、ハードウェア構成と照合される。もちろん、分析は、ハードウェア構成が固定されているかどうか、または定義されるべきかどうかによる。アプリケーションおよびハードウェアは、次に、静的マルチコア通信トポロジの中のノード、コア、および特性の数に関して最適性能を与えるために、分析され、かつ推定される。ステップ１０ｃにおいて、トポロジ要求が、アプリケーションおよびハードウェア分析に基づいて定義されかつ構成される。または、テストおよびアプリケーション要求に対する照合に基づいて再構成される。
【００３５】
このように、ブロック１０では、アプリケーション分析、アプリケーション分割、およびターゲットマルチコアコンピュータに基づいて、プログラマが、アプリケーションを最適にマッピングする方法および通信トポロジ、トポロジ仮定、性能と資源要求のバランシングを作成しかつ構成する方法を推定する。機能、ノード、およびコアの最初のマッピングが図３に従ってなされるべきであることが、決定される。図３に示すように、オンチップコア間での物理的な相互接続とチップ間での物理的な相互接続は異なる。それは、トポロジを作成する際に説明される必要がある。
【００３６】
ステップ１５ａで、トポロジが作成され、トポロジの特定の基本的な特性が、図３のトポロジに基づいて、図４に示すように定義される。ノードの最初の数は、作成時に特定されるが、図５〜６に示すようなドラッグアンドドロップ機能を用いて、必要に応じて後で修正され得る。通信トポロジは、機能のノードに対するマッピングに適応するように定義されかつ作成される。トポロジの作成は、新しいトポロジを作成することによって、ゼロからなされ得る。または、既存の（ＸＭＬベースの）トポロジテンプレートをインポートすることによって、または既存のトポロジマップを用いて、なされ得る。新しいトポロジの場合には、ノードの数を含む最初のパラメータおよび特性が、ウィザードインターフェースを通して特定される。また、ノードの数は、ＧＵＩの中のトポロジキャンバスの中で、図６に示すようなドラッグアンドドロップまたはコピーアンドペーストを通して便利に修正され得る。コアのタイプ、オペレーティングシステム、リポジトリ、および予め割り当てられたデータ構造を含む、ノードの特性および資源が、ＧＵＩの中の特性ビューの中で特定される。
【００３７】
図７に示すように、リンクが加えられ、かつ定義される。ステップ１５ｂにおいて、ノードおよびリンク資源、およびマルチコアコンピュータに対するそれらの結合が、図７〜８の段階的な手順に示すように構成される。ノード資源は、性能要求を満たすのに十分である一方で、マルチコアコンピュータの利用可能な（メモリ）資源の範囲内にとどまるように、バランスをとる必要がある。リンクは、構成され、リンクのタイプ、方向、サブネット、ハードウェアおよび資源に対するマッピングが定義される。サブネットは、図８に示すような様々な相互接続を表す。ブロック１５において、ノード間のリンクは、トポロジキャンバスビューの中で作成される。リンクのタイプ、特性、パラメータ、および資源が、特性ビューの中で定義される。トポロジは、保存され、トポロジモデル、およびユーザ定義である全ての値が許容された最小および最大の範囲内であることに対して検証される。検証は、値または名前がユニークであり、重複していないと判定することを含む。全てのオブジェクトまたはコンポーネントは、値または名前を１つ有することを要求される。ブロック１５からの出力は、ブロック２０に転送され、静的トポロジマップ定義ノード、リンク、ルーティング、ドライバ、システムソフトウェア、ハードウェア、および資源になる。トポロジマップは、それから、トポロジ、ディスパッチャ、リンク、パラメータ、およびデフォルト値モデルを検査するトポロジモデルに対して更に検証される。
【００３８】
ツリービューは、図９に示すようなトポロジおよび関連する特性の概観を提供する。ステップ１５ｃにおいて、図１０に示すように、完了されたトポロジマップは検証されかつ保存され、ＸＭＬベースのトポロジマップが生成される。もし検証が成功しなかったら、処理は修正動作のためにステップ１５ａに戻る。例示的なＸＭＬベースのトポロジマップが図１１に示されている。
【００３９】
ステップ２０ａにおいて、トポロジマップが解析され、検証され、データ構造が作成され、ノード間の最短経路が計算され、ルーティングテーブルが作成される。ノード間の最短経路（ＳＰＢＮ）は、ダイクストラ最短経路アルゴリズムを用いて計算される。各ノードに対して１セットのファイルが生成される例示的実施形態において、図１２に示すように、Ｃベースのトポロジ定義が生成される。ＳＰＢＮの使用は、最適性能を提供する。ＭＣＴＧのノード間通信で用いられるルーティングテーブルは、最適かつ予測可能なランタイム性能のために構成時に作成されるＳＰＢＮに基づく。当業者なら認めるであろうが、他のＳＰＢＮアルゴリズムも、同様に適用可能である（例えば、ジョンソンのアルゴリズム）。
【００４０】
ステップ２５ａにおいて、トポロジ定義が、標準開発ツール、コンパイラ、およびアセンブラを用いて構築される。Ｃ言語ベースの最適化されたトポロジ定義ファイルが生成される。１つのｃプログラム（.c）および１つのヘッダファイル（.h）が、トポロジの中の各ノードに対して生成される。.cおよび.hファイルは、共にトポロジを構成する定義、データ構造、および初期化ルーチンを含む。ステップ２５ｂにおいて、トポロジは、標準リンカを用いて、前に構築したアプリケーションおよび通信ランタイムライブラリとリンクされる。アプリケーションは、異なるノード上にある機能間でのデータ転送および同期に適応させるために、複数のＭＣＡＰＩ通信可能機能に分割され、通信方法は、アプリケーション要求に基づく。アプリケーションは、ここで、マルチコアコンピュータ上でのテストのための準備ができた。
【００４１】
ステップ２５ａ〜２５ｂにおいて、トポロジ定義の中で定義したような、Ｃベースのトポロジ、分割されたアプリケーション、および（通信ライブラリからの）適切なランタイム通信コンポーネントが構築され、ターゲットマルチコアコンピュータシステムのための標準的な開発ツール（例えば、コンパイラ、アセンブラ、およびリンカ）を用いて、実行可能な（バイナリの）ファイルになる。モジュールは、適切なコア４にロードされ、結果として生じるアプリケーションは、ここで複数のコアにわたって動作するが、初期分析においてなされた仮定およびコアに対するノード（機能）のマッピングが、予想される結果を提供するかどうかを判定するために、再び分析される。結果は、満足なものであるか否かを判定するために、アプリケーション性能要求に対して照合される。もし満足であれば、トポロジ定義、生成、およびアプリケーション統合が完了し、もし満足でなければ、開発者は、トポロジ要求を修正するために、ブロック１０のアプリケーション準備に戻る。トポロジ定義作成において、トポロジは、モデルに対して検証され、トポロジ−マップは、ＳＰＢＮ計算を用いて最適化される。生成されたモデルベースのトポロジコンポーネントは、更に作成されかつ検証される。検証されるコンポーネントは、静的ルーティングテーブル、静的（予め割り当てられている）データ構造、および予め定義されている初期化ルーチンである。
【００４２】
ステップ１３０において、マルチコアアプリケーションに対して最適化されたトポロジの中で、最終的な承認されかつ検証されたトポロジは、意図されたマルチコアコンピュータハードウェア上の意図されたアプリケーションソフトウェアと共に、使用の準備ができている。
【００４３】
ステップ３０ａにおいて、アプリケーションは、標準デバッギングツールを用いて、正当性および性能のためにデバッグされる。ステップ３０ｂにおいて、アプリケーションは、アプリケーション要求に対して検証される。注目に値する要求は、データスループット、アプリケーション応答時間、および電力消費であり得る。ほとんどの場合、最終結果は初期仮定と合わず、トポロジ仮定の修正が要求され、プロセスは所望の結果を成し遂げるために繰り返される。例えば、ここで分散された機能モジュール間の通信が、総合的なアプリケーション性能にいかに影響を与えるかを予測するのは難しい。我々の例の中の２つのチップ間の通信がボトルネックであることがわかり、新たな分析に基づいて、ノードが再マッピングされなければならないか、またはノードまたはリンク資源が修正されなければならないかもしれない。性能は、アプリケーションモジュール間でのデータ交換を修正することによって改善され得る可能性もある。
【００４４】
上述した方法論は、アプリケーション機能を分割すること、ＭＣＡＰＩ通信プリミティブを挿入すること、トポロジを作成すること、および機能を異なるコアにマッピングすることによって、シングルプロセッサアプリケーションのマルチコアコンピュータへの移行に、代わりに適用され得る。アプリケーションは、トポロジを再構成することによって、より多くのノードを加えること、トポロジ資源を修正することによって、そしてトポロジ特性とアプリケーション動作のマッチングによって最適化され得る。ＭＣＴＧは、実質的にこのプロセスの速度を上げて、多くの最適化反復を可能にし、開発時間を減らし、かつ最終結果を改善する。
【００４５】
明らかに、上記の教示に照らして、記載されている本発明の直ちに識別可能な修正および変更は可能である。従って、ここに具体的に記載したようにではなく、添付の請求項の範囲内で本発明が実施され得ることは理解されるべきである。例えば、トポロジのモデリングは、ＸＭＬ以外の構造化された移植可能な言語によっても実施され得るし、標準通信ＡＰＩは、ＭＣＡＰＩ以外のものでもよい。同様に、トポロジ生成方法は、開発者に対する配布のための物理的な記憶媒体上でも実施され得る。このような媒体は、ＣＤ−ＲＯＭ、ＤＶＤ、半導体メモリ、またはダウンロードのためのネットワークアクセスが可能な記憶装置を含む。
【００４６】
このように、前述の説明は、本発明の例示的実施形態を開示しかつ記載するのみである。従って、本発明の開示は、例示することを意図しているのであって、範囲を限定することを意図しているのではない。ここに教示されているものの任意の直ちに識別可能な変形を含む本開示は、部分的に、添付の請求項の用語の範囲を定義する。
【符号の説明】
【００４７】
２  組込型マルチコアプロセッサコンピュータ
４  プロセッサコア
【図１】
2012520518.tif 000004
【図２】
2012520518.tif 000005
【図３】
2012520518.tif 000006
【図４】
2012520518.tif 000007
【図５】
2012520518.tif 000008
【図６】
2012520518.tif 000009
【図７】
2012520518.tif 000010
【図８】
2012520518.tif 000011
【図９】
2012520518.tif 000012
【図１０】
2012520518.tif 000013
【図１１】
2012520518.tif 000014
【図１２】
2012520518.tif 000015
【国際調査報告】
2012520518.tif 000016