(57)【要約】  アプリケーションを処理するための複数のモジュール（Ｍ１〜Ｍ５、ＣＰＵ）と、前記複数のモジュール（Ｍ１〜Ｍ５、ＣＰＵ）によって共用されることが可能なグローバル・メモリ（ＧＭ）と、前記モジュール（Ｍ１〜Ｍ５、ＣＰＵ）同士を互いに接続するための相互接続手段（ＩＭ）と、複数の通信サービス（Ｃ１、Ｃ２）に基づく前記グローバル・メモリ（ＧＭ）とを含む集積回路が提供される。前記集積回路は、前記複数のモジュール（Ｍ１〜Ｍ５）間の通信を管理するための少なくとも１つの通信管理ユニット（ＣＭＵ）をさらに含み、前記通信管理ユニット（ＣＭＵ）は、前記モジュール（Ｍ１〜Ｍ５、ＣＰＵ）の少なくとも２つのモジュール間における通信要求を受信し、前記モジュール（ＭＩ〜Ｍ５、ＣＰＵ）の間における要求された通信のための基礎として、前記複数の通信サービス（Ｃ１、Ｃ２）の１つを動的に選択する。
2007500894.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを処理するための複数のモジュールを含む集積回路であって、
前記複数のモジュールによって共用されることが可能なグローバル・メモリと、
複数の通信サービスに基づき、前記モジュールと前記グローバル・メモリを互いに接続するための相互接続手段と、
少なくとも２つのモジュール間における通信要求を受信し、前記モジュール同士の間における前記要求された通信のための基礎として、前記複数の通信サービスの１つを動的に選択する、前記複数のモジュールの間における前記通信を管理するための少なくとも１つの通信管理ユニットと、を備える集積回路。
【請求項２】
最も少ない相互接続リソースを要求する前記通信サービスが、選択される請求項１に記載の集積回路。
【請求項３】
前記２つのモジュールの粒度（granularity）およびデータ転送速度が合致しない場合、または前記２つのモジュールのいずれかが、十分なローカル・バッファリングを含まない場合に、少なくとも２つのモジュール間でメモリをベースとした通信を可能にする第２の通信サービスが選択される請求項１または２に記載の集積回路。
【請求項４】
前記２つのモジュールの粒度およびデータ転送速度が合致する場合、かつ前記２つのモジュールのいずれかが、十分なローカル・バッファリングを含む場合に、２つのモジュール間で直接通信を可能にする第２の通信サービスが選択される請求項１または２に記載の集積回路。
【請求項５】
前記選択は、前記複数のモジュールの少なくとも２つの間における通信を確立するための要求が、前記通信管理ユニットによって受信されるたびに実行される請求項３または４に記載の集積回路。
【請求項６】
前記２つのモジュール間における前記通信のために確保されたリソースは、前記要求された通信を実行した後に解放される請求項１または５に記載の集積回路。
【請求項７】
前記モジュールの上で実行される前記アプリケーションは、リソースが制約されている請求項１に記載の集積回路。
【請求項８】
アプリケーションを処理するための複数のモジュールと、前記複数のモジュールの間で共用されるように適合されたグローバル・メモリとを含む集積回路において通信サービスを選択するための方法であって、
少なくとも２つのモジュールの間における通信要求を受信すること、および前記モジュール同士の間における前記通信のための基礎として、前記複数の通信サービスの１つを動的に選択することによって、前記複数のモジュールの間における前記通信を管理するステップを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のモジュールを含む集積回路、ならびにそのような集積回路における動的通信サービス選択のための方法に関する。
【背景技術】
【０００２】
計算リソースおよび通信リソースの最近の発展とともに、移動端末装置のアーキテクチャにおいて２つの主な傾向が現れている。第１の傾向は、アプリケーションの収斂と多様性の増大であり、例えば、ますます多様な機能またはサブシステムが、単一の端末装置に組み込まれて、端末装置が、新たなサービスおよびアプリケーションを実行するのを可能にしている。第２の傾向は、アーキテクチャの複雑さの増大に向けられ、例えば、ハードウェア・アーキテクチャとソフトウェア・アーキテクチャの両方の全体的な複雑さが、バスで接続されたコアに基づく従来のアーキテクチャ・スタイルの限度を超えている。
【０００３】
前述した傾向に対処する１つの可能な問題解決法は、モジュール性であるように思われる。モジュールの境界が、ＧＳＭモデム、ディスプレイ、またはオーディオのような機能サブシステムと一致するように選択されると、２つのレベルのハードウェアおよびソフトウェアのアーキテクチャ設計（ａｒｃｈｉｔｅｃｔｉｎｇ）を導出することができる。第１のレベルは、バスで接続されたコアに基づく従来のアーキテクチャ・スタイルを適用することができ、それにより、既存のサブシステムを再使用することができるサブシステム内アーキテクチャである。第２のレベルのアーキテクチャ設計は、ネットワーク・アーキテクチャが適用され、サブシステム間通信が、ＯＳＩのような階層ネットワーク・アーキテクチャ上で実行される、サブシステム間アーキテクチャである。以上２つのレベルのアーキテクチャ設計を使用して、機能サブシステムの開発を、当技術分野で公知のように実行することができ、したがって、知的財産（ＩＰ）ブロックを再使用することができる。
【０００４】
通常、ほとんどの移動端末装置は、ポータブル・オーディオ・プレーヤ（オーディオ・サブシステム、およびＣＤまたはソリッドステート・ストレージ）、移動電話（ＧＳＭモデムおよび音声コーデック）、パームトップ・オーガナイザ（タッチスクリーン＋マイクロプロセッサ）、またはソリッドステート・カメラ（カメラ＋ディスプレイ＋ソリッドステート・ストレージ）のような、いくつかの周辺コンポーネントを基礎として、移動端末装置の機能を提供する。様々なそれらの異なるサブシステム、例えば、周辺コンポーネントは、着実に増加している。それらの異なるサブシステムは、互いに独立に進化し、急速により高度化し、より複雑になっており、したがって、ビットレート、容量、分解能、および品質のような、それらのサブシステムの性能パラメータは、着実に向上している。実際の端末装置は、ますます多くのサブシステムを含み、それらのサブシステムの内部（ｉｎｔｅｒｎａｌ）は、重点が、ソフトウェア、アプリケーション、およびサービスの方に移されているので、それほど重要でなくなっている。
【０００５】
コアおよびバスに基づく従来のアーキテクチャ設計は、限られた計算リソースのセット上での計算、低レーテンシーを有する少数の緊密に結合されたブロックのセット上でのタスクのスケジューリング、および厳しいバスプロトコルに焦点を当ててきたのに対し、サブシステム間のアーキテクチャ設計は、計算にもはや焦点を当てておらず、通信に焦点を当てている。異なるサブシステムによって共用されるリソースが、通信インフラストラクチャであり、場合により、共有メモリである。それらのサブシステムは、比較的長いレーテンシー、および比較的低い同期速度ならびにネットワーク・プロトコルで、通常、緩く結合されている。
【０００６】
端末装置は、通常、ネットワークを介して互いに接続された複数のサブシステムから成る。ＵＭＴＳモデムまたはビデオ・コーデックのようなサブシステムは、独立に設計されることが可能である。サブシステムは、１つまたは複数のプログラマブル・コア、いくつかのコプロセッサ、ローカル・メモリ、およびＩ／Ｏを含んでもよい。サブシステムを接続するのに、ネットワークが使用される。データ、命令、メモリ・トラフィック、および制御情報のような、すべてのサブシステム間通信が、ネットワークを介して実行される。
【０００７】
いわゆるシステムオンチップＳｏｃは、相互接続スキームによって接続された複数のサブシステム、例えば、ローカル・メモリを有する機能要素群またはモジュール群を通常、含む。システムオンチップＳｏｃは、サブシステム・セットにマップされることが可能な、異なるアプリケーションを実行するように適合される。サブシステムによって実行されるすべての機能は、機能の処理の実行のために、ある量のメモリを要する。メモリの正確な量は、ビデオ復号化のためのスクリーン・サイズ、モデムに関するデータ転送速度、または同様のパラメータのような、複数のパラメータに依存する。したがって、異なるアプリケーションは、メモリに対する異なるデマンドを有する。現在、家庭用電化製品の分野におけるほとんどのアプリケーション・ドメインは、システム費用、および電力消費が最小限に抑えらえることを要求する。前述した制約環境において競争力があるためには、要求されるメモリ量（オンチップ、または外部の両方で）が、特定のアプリケーションに関して最適化されることが不可欠である。他方、移動電話、ＰＤＡ、ＭＰ３プレーヤ、または同様の家庭用電化製品のような、多くの家庭用電化製品市場が収斂する前述した傾向とともに、単一の特定のアプリケーション、または単に限られたアプリケーション・セットに注目することは、もはや実現可能ではない。端末装置の実現はいずれも、低費用、かつ低電力でなければならず、ここで、費用は、資材、すなわち、チップ面積、チップ・カウント、ピン・カウント、およびＰＣＢ配線層の請求金額によって実質的に定義される。
【０００８】
前述のメモリ要件に加えて、システム内の相異なるブロックまたはモジュールが、異なる速度、および異なる粒度（granularity）で処理データを生成することが可能なオンチップ通信に対処するのに、いくつかの異なる通信サービスが要求される。１つの通信サービスは、モジュールのローカルメモリ内に位置する小さいバッファだけとの直接的な接続に基づくものでありうる。このサービスでは、２つのハードウェア・ブロックまたはハードウェア・モジュールが、低い粒度のデータ交換、および高い同期速度を特徴とするネットワークを介して、互いの間で直接に通信する。第２の通信サービスは、メモリをベースとした接続に基づくものでありうる。このサービスでは、２つの通信するブロックまたはモジュールを減結合するために、データが、バッファの中に格納される。メモリをベースとした通信は、粗い粒度のデータ交換、および低い同期速度を特徴とする。というのは、共有メモリ内で、より大きいバッファが割り当てられることが可能だからである。
【０００９】
知られているシステムは、モジュール間の可能なすべての接続が、システムの設計中に既に評価済みであり、各通信が、ある通信サービスに静的にリンクされるように、通常、設計される。通常、リソースが制約されたシステムは、リソースの使用に大いに最適化され、通信は、周知で、静的であり、さらに、動的な接続生成は、全く存在しない。これは、既知のアプリケーション群を有するシステムの場合、実現可能であるかもしれないが、最終的なアプリケーション群が、まだ知られていない、またはアプリケーション群の存続期間中に変更されることがあるシステムの場合、ブロック間、またはモジュール間の通信は、より柔軟でなければならない。したがって、システムは、通信リソースの動的な割り当てを提供することができなければならない。ときとして、そのようなシステムにおける接続は、動的に生成されるものの、１つだけの事前定義された接続サービスが使用される。特に、リソースが制約されたシステムオンチップＳｏＣ、すなわち、リソースが少ないシステムオンチップＳｏＣの場合、通信リソースの動的な割り当ては、低費用、かつ低電力のデバイスを提供するために、不可欠である。ある通信要求に、その要求の現在のパラメータに関わらず、常に同一の形で（場合により、最悪ケースで）対応が行われると、すべてのリソースが既に占有されている一部のケースが出現することがある。したがって、すべてのリソースが占有されているので、他の通信要求が、拒否されるかもしれない。特に、電力制約が大きいポータブル・デバイスの場合、およびいくつかのデバイスの機能が収斂し、利用可能なリソースの有効な使用が、その特定の領域で競争に有利であるのに不可欠な場合である。したがって、通信要求のより柔軟性のある処理、および対応する通信リソースの授与が、有益であるように思われる。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
したがって、本発明の目的は、複数のモジュールを有するシステムオンチップにおいて通信サービスの動的選択を提供することである。
【課題を解決するための手段】
【００１１】
したがって、複数のモジュールＭ１〜Ｍ５と、アプリケーション群を処理するためのＣＰＵと、前記複数のモジュールＭ１〜Ｍ５、ＣＰＵによって共用されることが可能なグローバル・メモリＧＭと、複数の通信サービスＣ１、Ｃ２に基づき、前記モジュールＭ１〜Ｍ５、ＣＰＵ、および前記グローバル・メモリＧＭを互いに接続するための相互接続手段ＩＭとを含む集積回路が提供される。前記集積回路は、前記複数のモジュールＭ１〜Ｍ５の間における通信を管理するための、少なくとも１つの通信管理ユニットＣＭＵをさらに含み、前記通信管理ユニットＣＭＵは、前記Ｍ１〜Ｍ５、ＣＰＵの少なくとも２つの間における通信要求を受け取り、前記モジュールＭ１〜Ｍ５、ＣＰＵの間における要求された通信のための基礎として、前記複数の通信サービスＣ１、Ｃ２の１つを動的に選択する。
【００１２】
したがって、システムは、モジュール間における通信の変化に動的に対応することができる。
【００１３】
本発明の態様によれば、最も少ない相互接続リソースを要する通信サービスＣ１、Ｃ２が選択される。したがって、より良好なリソース使用が可能になり、このため、より多くの通信チャネルが、リソースが制約された環境において開かれてもよい。
【００１４】
本発明のさらなる態様によれば、２つのモジュールＭ１〜Ｍ５、ＣＰＵの粒度およびデータ転送速度が合致しない場合、または前記２つのモジュールＭ１〜Ｍ５、ＣＰＵのいずれかが、十分なローカル・バッファリングを含まない場合、前記モジュール（Ｍ１〜Ｍ５、ＣＰＵの少なくとも２つの間におけるメモリをベースとした通信を可能にする第１の通信サービスＣが選択され、２つのモジュールＭ１〜Ｍ５、ＣＰＵの粒度およびデータ転送速度が合致する場合、かつ前記２つのモジュールＭ１〜Ｍ５、ＣＰＵのいずれかが、十分なローカル・バッファリングを含む場合、直接通信を可能にする第２の通信サービスが選択される。したがって、直接通信サービスは、可能な場合、選択され、これにより、要求される帯域幅、メモリ割り当て量、およびさらに、システムの電力使用量が低減される。
【００１５】
本発明のさらなる態様によれば、選択は、前記複数のモジュールＭ１〜Ｍ５、ＣＰＵの少なくとも２つの間で通信を確立するための要求が、通信管理ユニットＣＭＵによって受け取られるたびに、実行される。したがって、システムが、すべての要求された通信に最適なリソースを動的に割り振ることを可能にし、これにより、最適なリソース使用を可能にする。
【００１６】
本発明のさらなる態様によれば、前記複数のモジュールの前記２つの間における通信のために確保されていたリソースが、要求された通信を実行した後、解放される。したがって、確保されたリソースは、即時に解放されて、リソースが、他の要求された通信のために再び再使用されることが可能になる。
【００１７】
また、本発明は、前述した集積回路において通信サービスを選択するための方法にも関する。前記複数のモジュールＭ１〜Ｍ５の間における通信は、前記モジュールＭ１〜Ｍ５、ＣＰＵの少なくとも２つの間における通信要求を受け取ること、および前記モジュールＭ１〜Ｍ５、ＣＰＵの間における通信のための基礎として、前記複数の通信サービスＣ１、Ｃ２の１つを動的に選択することにより、管理される。
【００１８】
次に、本発明を、図を参照して詳細に説明する。
【発明を実施するための最良の形態】
【００１９】
本発明によるシステムオンチップは、リソースが少なくてもよく、すなわち、移動電話またはポータブル・デバイスのような、低費用および低電力のためのシステムであってもよい。しかし、本発明の諸原理は、また、それほど制約されていない環境に適用されてもよい。
【００２０】
図１は、本発明の第１の実施形態によるシステムオンチップＳｏＣのブロック図を示す。システムは、２つのモジュールＭ１、Ｍ２と、中央処理装置ＣＰＵと、グローバル・メモリＧＭと、相互接続手段ＩＭとを含む。第２のモジュールＭ２は、メモリ・バッファＭＢを含む。グローバル・メモリＧＭは、グローバル・バッファＦＢを含み、ＣＰＵ、または２つのモジュールＭ１、Ｍ２がデータを格納することができる共有メモリとして使用される。通信管理ユニットＣＭＵが、ソフトウェア・ベースで中央処理装置ＣＰＵ上で実施され、ＣＰＵとモジュール群の間の通信、ならびにモジュール間通信を管理するのに使用される。
【００２１】
異なるモジュールは、モジュール上で実行されているアプリケーション群に依存して、異なる速度、および異なる粒度（granularity）でデータをもたらすことが可能である。モジュール間通信は、２つの手法で、すなわち、直接のブロック−ブロックの、もしくはモジュール−モジュールの通信で、またはメモリをベースとした通信で実施されることが可能である。直接ブロック−ブロック通信は、小さいトークンの交換のためにほとんど使用される。この通信は、かなり高い同期速度を有するが、ブロック群の１つのブロックにローカルである、小さいバッファ群だけしか使用されない。メモリをベースとした通信は、はるかに低い同期速度で、ただし、より大きいバッファ群が、メイン・メモリ内、すなわち、共有メモリＧＭ内に配置されて、大きいトークンのために主に使用される。直接ブロック−ブロック通信だけを使用することは、それが柔軟でないシステムをもたらす。というのは、一部の特定の接続が、メモリをベースとしたサービスを使用してしか確立されることが可能でないからである。しかし、メモリをベースとした通信だけが実行される場合、これは、より低い通信要求を有するケースに関して、共有メモリ、および要求される電力の過度の使用をもたらし、これにより、また、他の通信要求の扱いも妨げられるか、阻止される。
【００２２】
通信管理ユニットＣＭＵを実装することにより、システムオンチップは、要求される通信の実際の粒度およびデータ転送速度に依存して、直接ブロック−ブロック通信またはメモリをベースとした通信を動的に割り当てることができる。したがって、いずれの通信スキームまたは通信サービスが実施されるかの判定は、要求される通信の実際のパラメータの分析に基づく。第１の実施形態によれば、第１のモジュールＭ１と第２のモジュールＭ２の間における通信の管理は、ＣＰＵ上で実施される通信管理ユニットＣＭＵによって実行される。２つのモジュールＭ１、Ｍ２の間の通信は、接続Ｃ１を介して、または接続Ｃ２を介して実行されることが可能である。接続Ｃ１は、メモリをベースとした通信として実施され、すなわち、モジュールＭ１が、データをグローバル・バッファＦＢに書き込み、モジュールＭ２が、グローバル・バッファＦＢからそれらのデータを読み取る。接続Ｃ２は、モジュールＭ１からモジュールＭ２への直接通信として実施され、この場合、データは、メモリ・バッファＭＢに直接に書き込まれることが可能である。第１の実施形態によれば、いずれの接続（Ｃ１またはＣ２）を使用するかの判定は、ＣＰＵ上で実行されているソフトウェア・タスクとして実施される通信管理ユニットＣＭＵによって実行される。したがって、判定プロセスは、システム内の中心的場所で実行される。
【００２３】
システム上のアプリケーションの処理中に、モジュールＭ１とモジュールＭ２の間で通信または接続を確立する要求が、ＣＰＵから通信管理ユニットＣＭＵに発行されることが可能である。また、代替として、この要求は、モジュールＭ１、Ｍ２のいずれかから送信されることも可能である。通信管理ユニットＣＭＵは、アプリケーション、または送信側モジュールから、要求された通信のパラメータを取得する。それらのパラメータは、要求される通信の粒度または帯域幅であってもよい。
【００２４】
通信のパラメータが、互いに合致し、モジュールの１つ、すなわち、受信側モジュールが、十分なローカル・バッファリング、すなわち、モジュール・バッファＭＢを有する場合、直接モジュール−モジュール通信が、接続Ｃ２を確立するのに使用される。しかし、パラメータが合致しない場合、次いで、メモリをベースとした接続Ｃ１が選択される。前述した通信スキームのいずれが使用されるべきかの判定は、好ましくは、接続を確立するための要求が、通信管理ユニットＣＭＵによって受信されるたびに実行される。したがって、システムは、最適なリソースを通信要求に動的に割り当てることができる。モジュール間、またはＣＰＵとモジュールのいずれか１つとの間における通信の実行に成功した後、グローバル・メモリＧＭ内のグローバル・バッファＦＢのような、その通信のために確保されていたリソースが解放されて、それらのリソースが、他の接続のために使用されることが可能になる。したがって、システム・メモリ、およびシステムの帯域幅が、最適な形で使用されることが可能であり、メモリの全体的な使用量のリソース割り当てとともに、通信スキームの要求される帯域幅も小さくなり、静的な状況と比べて、より多くの通信チャネルが同時に開かれることが可能になる。さらに、より少ないリソースが占有されるので、システムの消費電力が抑えられる。
【００２５】
２つのモジュール間の直接通信は、メモリをベースとしたサービスと比べて、より小さい遅延、つまりレーテンシーを有し、これにより、システム・パフォーマンスが高められることが可能である。しかし、通信が確立されることが可能になる前に行われる判定プロセスは、通信に初期遅延を導入し、また、通信管理ユニットを実施することによって、制御オーバーヘッドも要する。その反面、接続は、リアルタイムで確立されなくてもよく、さらに、それらの接続を確立することは、たまにしか行われず、したがって、いくらかの遅延は、許容できることがある。
【００２６】
図２は、本発明の第２の実施形態によるシステムオンチップのブロック図を示す。システムオンチップは、２つのモジュールＭ３、Ｍ４と、相互接続手段ＩＭと、グローバル・メモリＧＭとを含む。グローバル・メモリＧＭは、グローバル・バッファＦＢを含む。モジュールＭ３は、前記モジュールＭ３上でソフトウェア・タスクとして実施される通信管理ユニットＣＭＵを含む。モジュールＭ４は、モジュール・バッファＭＢを含み、ハードウェア・ブロックとして実施される通信管理ユニットＣＭＵが、モジュールＭ４に関連する。通信管理ユニットＣＭＵ、または２つのモジュールＭ３、Ｍ４が、モジュール群の通信を管理するのに使用される。２つのモジュールＭ３、Ｍ４の間の通信は、接続Ｃ１、すなわち、メモリをベースとした通信を介して、または接続Ｃ２、すなわち、直接通信を介して行われることが可能である。
【００２７】
第２の実施形態によれば、第１の実施形態の場合のような中央通信管理ユニットは、全く存在しない。モジュール群の通信の管理は、モジュール群の各モジュール上で／または各モジュールに関して、分散されて実行される。通信管理は、通信を開始するモジュール上で実行されるか、または通信を受信するモジュール上で、すなわち、スレーブ上で実行されることが可能である。代替として、通信管理は、開始側モジュール上で実行されるとともに、受信側モジュール上で実行されてもよい。そのような状況では、判定機構は、すべてのモジュールに関して実施されなければならない。通信管理は、ソフトウェア・タスク（モジュールＭ３）として、またはモジュールと相互接続手段ＩＭの間のシェルとして構成されるハードウェア要素として実施されてもよい。
【００２８】
実際の判定機構は、第１の実施形態で説明したとおり実行される。最初に、２つのモジュール間で通信を確立する要求が受信される。この要求は、ブロックの１つから送信されても、またはシステムオンチップ上でペアレントな形で（ｐａｒｅｎｔｌｙ）実行されるアプリケーションから送信されてもよい。開始側モジュール（代替として、これもまた、受信側モジュールであってもよい）に好ましくは関連する通信管理ユニットＣＭＵが、その通信に要求されるパラメータを調べなければならない。前述したとおり、パラメータは、粒度または帯域幅であってもよい。送信側モジュールと受信側モジュールの通信パラメータが合致した場合、かつ受信側モジュールが、受信側モジュールのモジュール・バッファＭＢ内に十分なローカル・バッファリングを有する場合、直接モジュール−モジュール通信が選択され、対応する接続、すなわち、Ｃ２が、モジュール間で確立される。しかし、それらのモジュールの通信パラメータが合致しない場合、またはモジュール・バッファＭＢ内に十分なローカル・バッファリングが存在しない場合、次いで、メモリをベースとした通信が選択され、接続Ｃ１が使用される。
【００２９】
代替の実施形態によれば、第１の実施形態と第２の実施形態の組み合わせに基づくシステムオンチップＳｏＣが提供される。したがって、通信サービスの選択は、中央で実行されても、または分散で実行されてもよい。
【００３０】
図３は、本発明の第３の実施形態によるシステムオンチップを示す。第３の実施形態は、第１の実施形態に基づく。システムは、モジュールＭ５と、シェルＳと、相互接続手段ＩＭと、グローバル・メモリＧＭと、リソース管理ユニットＲＭＵとを含む。モジュールＭ５は、シェルＳおよび相互接続手段ＩＭを介して、グローバル・メモリＧＭに接続される。モジュールＭ５は、プロセッサＰＲＯＣと、命令キャッシュＩと、データ・キャッシュＤと、ローカル・メモリＬＭとを含む。プロセッサＰＲＯＣとローカル・メモリＬＭは、バスＢを介して互いに接続される。ローカル・メモリＬＭは、プリフェッチバッファＰＢを含む。ローカル・メモリＬＭは、モジュールＭのためだけの専用（ｐｒｉｖａｔｅ）メモリとして使用される。ローカル・メモリＬＭは、低いメモリ・デマンドを有するアプリケーション群を実行するのに十分な小さいメモリとしての大きさにされる。このメモリ空間の量は、モジュールＭ５上で実行されるアプリケーションに依存することが可能である。
【００３１】
さらに、図１に示すとおり、システムは、中央処理装置ＣＰＵと、２つのモジュールＭ１、Ｍ２とをさらに含む。第２のモジュールＭ２は、メモリ・バッファＭＢを含む。グローバル・メモリＧＭは、グローバル・バッファＦＢを含み、ＣＰＵ、または２つのモジュールＭ１、Ｍ２が、データを格納することができる共有メモリとして使用される。通信管理ユニットＣＭＵが、ソフトウェア・ベースで、中央処理装置ＣＰＵ上で実施され、ＣＰＵとモジュール群との間の通信、ならびにモジュール間通信を管理するのに使用される。通信サービスの選択は、第１の実施形態に従って実行される。
【００３２】
モジュールＭ５は、任意のサブシステムであってもよく、その他の機能ブロックをさらに含んでもよく、専用アプリケーション群、またはいくつかの異なるアプリケーション群を実行する。シェルＳは、モジュールＭ５と相互接続スキームＩＭの間で提供され、モジュールと相互接続スキームの間における通信を管理するのに使用される。シェルＳの考え方は、相互接続スキームのプロパティをモジュールに隠すことである。したがって、既存のモジュール群が、それらのモジュールの通信を再設計する必要なしに使用されることが可能である。というのは、シェルＳが、インタフェースとして使用されるからである。相互接続スキームＩＭは、好ましくは、チップ上のネットワークであるが、また、バス・ベースのスキームであってもよい。
【００３３】
シェルＳは、メモリ管理ユニットＭＭＵと、アドレス変換ユニットＡＴＵとを含む。メモリ管理ユニットＭＭＵは、ローカル・メモリＬＭ内の空きメモリ空間を監視し、ローカル・メモリＬＭ内の利用可能なメモリ空間が、所定の最小値より低くなるとすぐに、グローバル・メモリＧＭ内のグローバル・バッファＦＢの割り当てを要求する。この背景にある考え方は、ローカル・メモリＬＭ内に十分な空間が存在しない、モジュールＭ上で実行されるアプリケーションからの処理データをアウトソーシングすることである。次いで、モジュールＭ上で実行されるアプリケーションによって使用されるアドレスを、グローバル・メモリＧＭに対応するグローバル・アドレス・マップのアドレスに変換するアドレス変換ユニットＡＴＵが提供される。
【００３４】
前述したとおり、メモリ管理ユニットＭＭＵは、そのモジュールからの処理データだけのために確保されるべき、グローバル・メモリＧＭ内のバッファを求める要求を送信する。メモリ管理ユニットＭＭＵからのこの要求は、リソース管理ユニットＲＭＵに送信される。リソース管理ユニットＲＭＵは、システムにおける全体的リソースを管理するために提供される。さらに、メモリ管理ユニットＭＭＵが、相互接続スキームＩＭを介して、モジュールＭとグローバル・メモリＧＭの間における保証されたデータ・パスの提供を要求する。リソース管理ユニットＲＭＵが、それらの要求を受信し、要求されたサイズのバッファを確保するのに十分な空間がグローバル・メモリＧＭ内で利用可能であるかどうか、ならびに相互接続スキームＩＭが、モジュールＭ５とグローバル・メモリＧＭの間における要求された通信パスのために十分な帯域幅を提供することができるかどうかを判定する。リソース管理ユニットＲＭＵが、グローバル・メモリＧＭ内で十分な空間が利用可能であり、通信パスのために十分な通信リソースが利用可能であると判定した場合、リソース管理ユニットＲＭＵは、メモリ管理ユニットＭＭＵに応答を送信する。リソース管理ユニットＲＭＵは、グローバル・メモリＧＭ内のグローバル・バッファＦＢの利用可能な空間、ならびにその空間のアドレスを応答の中に含める。メモリ管理ユニットＭＭＵは、その肯定的な応答をリソース管理ユニットＲＭＵから受信するとすぐに、アドレス変換ユニットＡＴＵをアクティブにすることができる。アドレス変換ユニットＡＴＵは、モジュールＭ上で実行されるアプリケーションからの処理データのアウトソーシングを隠すのに使用される。この隠蔽を行うため、ローカル・メモリＬＭの中にもはや格納されることが可能でない処理データのアドレスに、オフセットが与えられる。ローカル・メモリＬＭの中に格納されることが可能でない、それらの処理データのアドレスのオフセットは、リソース管理ユニットＲＭＵによって戻される、グローバル・メモリＧＭ内のグローバル・バッファＦＢのアドレスに基づいて計算される。
【００３５】
このシステムのパフォーマンスのさらなる向上を実現するため、グローバル・バッファＦＢの中に格納されたデータが、モジュールＭ上で実行されるアプリケーションによってそれらのデータが使用される前に、プリフェッチされ、ローカル・メモリＬＭ内のプリフェッチバッファＰＢの中に格納されることが可能である。そのデータをプリフェッチすることにより、グローバル・メモリＧＭ内のグローバル・バッファＦＢのより長いパスが、アプリケーションから隠され、また、処理データをアウトソーシングすることによって導入されるレーテンシーも、アプリケーションから隠されることが可能である。
【００３６】
グローバル・メモリＧＭ内のグローバル・バッファＦＢの割り当ては、あるアプリケーションのランタイムで実行されることが可能であり、または所定の期間の後に実行されてもよく、または代替として、前述したとおり、一部のイベントに基づいて実行されてもよい。
【００３７】
オンチップ・グローバル・メモリとともに、オフチップ・グローバル・メモリもシステム内に存在する場合、グローバル・メモリ内のバッファの割り当ては、費用、電力、および帯域幅リソースを最適化するように行われる。
【００３８】
本発明による動的メモリ割り当ての欠点は、アドレス変換ユニットＡＴＵを導入することにより、モジュールＭのインタフェースまたはシェルにさらなる複雑さが加えられることである。さらに、リソース管理ユニットＲＭＵは、利用可能な通信リソースを常に把握するために、システムオンチップに組み込まれる必要がある。データのエクスポートおよびアウトソーシングは、さらなるレーテンシーを導入する。さらに、リソース管理ユニットＲＭＵは、グローバル・メモリにおいてアクセス調停を実行して、要求された通信パスが保証されることが可能であるようにする必要がある。
【００３９】
本発明のさらなる実施形態によれば、第３の実施形態の動的メモリ割り当てもまた、第２の実施形態によるシステムオンチップＳｏＣにおいて、または代替として、第１の実施形態と第２の実施形態の組み合わせに基づくシステムオンチップＳｏＣにおいて適用されてもよい。
【００４０】
また、本発明の諸実施形態による通信管理ユニットＣＭＵは、第３の実施形態によるシェルＳにおいて、メモリ管理ユニットＭＭＵおよびアドレス変換ユニットＡＴＵとともに実施されてもよい。
【００４１】
モジュール間の通信のパラメータ、モジュール群のパラメータ、またはモジュール群の上で実行されるアプリケーション群のパラメータは、リソース管理ユニットＲＭＵによって格納され、管理されてもよい。したがって、通信パラメータを求めるＣＭＵの問い合わせは、代替として、それらのパラメータを求める要求をＲＭＵに対して発行することによって実行されることも可能である。
【００４２】
また、モジュール間の通信は、２つより多くのモジュール間で、例えば、マルチキャストによって、すなわち、１つの送信側モジュールといくつかの受信側モジュールによって実行されてもよい。
【００４３】
また、以上の諸実施形態で説明した通信管理ユニットＣＭＵは、モジュール群（Ｍ１〜Ｍ５）と通信することもできる。それらのモジュールは、例えば、要求を送信してもよく、ＣＭＵは、許可またはプログラム・バッファ・サイズを送信する。また、これは、実際のデータ交換中にも行われることがある。というのは、モジュール群は、例えば、バッファがいっぱいにされており、他方のモジュールによって空にされることが可能であることを他方のモジュールに通知するため、互いの間で通信して、同期しなければならないからである。この通信は、データ通信とは逆方向で実行され、制御通信として実施されてもよい。基本的に、要求を送信すること、モジュール（Ｍ１〜Ｍ５）をプログラミングすること、またはモジュール間で同期することなどの制御トラフィックは、グローバル・メモリの中に入ることなしに、直接に行われる。また、このトラフィックのために、ときとして、別個の通信媒体（バス）が使用されてもよい。
【００４４】
さらに、相互接続ＩＭは、ネットワークとして実現されてもよく、その場合、このネットワークを経由するパスは、例えば、レーテンシーに基づき、動的に割り当てられることが可能である。また、そのような相互接続手段ＩＭは、例えば、帯域幅、遅延、減結合（グローバル・メモリ内のバッファを使用した）のような異なるパラメータも、通信チャネルに提供することができる。あるパラメータを有するあるタイプの通信に対して適切なチャネル（適切なパラメータを有するチャネル）が、動的に選択されてもよい。
【００４５】
前述した諸実施形態は、本発明を限定するものではなく、例示するものであること、および当業者は、添付の特許請求の範囲を逸脱することなく、多くの代替の実施形態を設計することができることに留意されたい。特許請求の範囲では、括弧内に入れられたあらゆる符号は、特許請求の範囲を限定するものと解釈されてはならない。「含む（ｃｏｍｐｒｉｓｉｎｇ）」という語は、特許請求の範囲で列挙される要素またはステップ以外の要素またはステップの存在を除外しない。要素の前に付く「１つの（ａ）」または「１つの（ａｎ）」という語は、複数のそのような要素の存在を除外しない。いくつかの手段を列挙するデバイス請求項において、それらの手段のいくつかが、同じ１つのハードウェア・アイテムによって実施されることが可能である。単に、いくつかの手段（ｍｅａｓｒｕｅ）が、互いに異なる従属請求項に記載されているということは、それらの手段の組み合わせが、有利に使用されることが可能でないことを意味しない。
【００４６】
さらに、特許請求の範囲におけるいずれの符号も、本発明の範囲を限定すると解釈されてはならない。
【図面の簡単な説明】
【００４７】
【図１】第１の実施形態によるシステムオンチップを示すブロック図である。
【図２】第２の実施形態によるシステムオンチップを示すブロック図である。
【図３】第３の実施形態によるシステムオンチップを示すブロック図である。
【図１】
2007500894.tif 000003
【図２】
2007500894.tif 000004
【図３】
2007500894.tif 000005
【国際調査報告】
2007500894.tif 000006
2007500894.tif 000007