JP2014513494A - ポータブルコンピューティングデバイスのスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法およびシステム - Google Patents

Abstract

ポータブルコンピューティングデバイス(「PCD」)のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法およびシステムについて説明する。本システムおよび方法は、マスタースレーブペアを含むクライアント要求を受信するステップと、マスタースレーブペアに対応するスレーブについての検索を実行するステップとを含む。マスタースレーブペアに対応するスイッチファブリック内およびスイッチファブリック間の通信のためのルートが作成される。作成されたルートに対応する1つまたは複数のハンドルまたは配列がメモリデバイスに記憶され得る。次に、ルート上の帯域幅が設定され得る。新たに作成されたルート上の帯域幅が設定された後、作成されたルートを使用して、マスタースレーブペアを発生させたクライアント要求がサービスされ得る。スレーブについての検索を実行するステップは、マスタースレーブ階層における各スレーブに割り当てられた一意の識別子を比較するステップを含むことができる。スイッチファブリック内およびスイッチファブリック間の検索はまた、スイッチファブリック内で問合せ可能なスレーブを求めてファブリックルートチェックテーブルを確認するステップを含むことができる。

Description

ポータブルコンピューティングデバイス(「PCD」)は、個人レベルおよび専門レベルにおいて人々に必要なものになりつつある。これらのデバイスは、セルラー電話、携帯情報端末(「PDA」)、ポータブルゲームコンソール、ポータブルナビゲーションユニット、パームトップコンピュータ、および他のポータブル電子デバイスを含み得る。

PCDは、様々な機能および特徴を提供するための様々なタイプのソフトウェアを実行することができる。たとえば、PCDは、ビデオを見ることやビデオゲームをすることなどの機能を提供し得るエンターテインメントソフトウェアを実行することができる。PCDはまた、ビジネスソフトウェアまたはライティングソフトウェア、たとえばスプレッドシート、電子メール、および/またはワード処理ソフトウェアなどの他のタイプのソフトウェアをサポートすることができる。

通常、PCD上で動作している上述のソフトウェアは、マスタースレーブペアとして互いにリンクされた様々なハードウェアからのアクションを求める。たとえば、マスタースレーブペアは、外部バスインターフェースなどのスレーブにコマンドを出すマスターとして動作するモバイルディスプレイプロセッサを含むことができる。従来型のPCDでは、マスタースレーブペア間の関係は、通常は静的であり、PCDが上述のソフトウェアを実行し始める実行時に先立って確立される。

従来型のPCDでは、マスタースレーブペア間の関係は通常、実行時に先立って作成されるテーブルに記録される。テーブルは通常、特定のマスタースレーブペアに関する異なる作業負荷に対応する異なる帯域幅をサポートするためのいくつかの異なるシナリオを記載する。

従来型のPCDに関連する1つの問題として、マスタースレーブペアが互いに異なるスイッチファブリックに存在するときに、マスタースレーブテーブルが非常に複雑になるということがある。テーブルに関連する別の問題として、テーブルが作成されたときに設定された固定値に基づいて、テーブルが帯域幅需要に対処し得るにすぎないということがある。PCDに新しいマスタースレーブペアが導入されるときに、さらなる問題が生じる。新しいマスタースレーブペアは、PCDがオフラインであるときに書かれた停滞したマスタースレーブテーブルの大幅な書き直しを必要とすることがある。

したがって、当技術分野では、これらの問題に対処する方法およびシステムが必要である。具体的には、当技術分野では、同様のスイッチファブリック内および/または異なるスイッチファブリック間に存在し得るハードウェア構成要素について実行時にマスタースレーブペアを動的に作成するための方法およびシステムが必要である。当技術分野では、停滞したテーブルを使用せずにオンザフライまたはリアルタイムでスイッチファブリックおよびバスのための帯域幅を計算し調整する方法およびシステムも必要である。

ポータブルコンピューティングデバイス(「PCD」)のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法およびシステムについて説明する。本システムおよび方法は、マスタースレーブペアを含むクライアント要求を受信するステップと、マスタースレーブペアに対応するスレーブについての検索を実行するステップとを含む。マスタースレーブペアに対応するスイッチファブリック内およびスイッチファブリック間の通信のためのルートが作成され得る。作成されたルートに対応する1つまたは複数のハンドルまたは配列がメモリデバイスに記憶され得る。次に、ルート上の帯域幅が設定され得る。新たに作成されたルート上の帯域幅が設定された後、作成されたルートを使用して、マスタースレーブペアを発生させたクライアント要求がサービスされ得る。スレーブについての検索を実行するステップは、マスタースレーブ階層における各スレーブに割り当てられた一意の識別子を比較するステップを含むことができる。スイッチファブリック内およびスイッチファブリック間の検索はまた、スイッチファブリック内で問合せ可能なスレーブを求めてファブリックルートチェックテーブルを確認するステップを含むことができる。

図中、別段規定されていない限り、同様の参照番号は、様々な図の全体を通じて、同様の部分を指す。「102A」または「102B」のような文字指定を伴う参照番号について、文字指定は、同じ図に存在する2つの同様の部分または要素を区別し得る。参照番号の文字指定は、参照番号が、すべての図において同じ参照番号を有するすべての部分を包含することが意図される場合には、省略されることがある。

ポータブルコンピューティングデバイス(「PCD」)のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするためのシステムの例示的な要素を示す機能ブロック図である。 PCD100のスイッチファブリック内およびスイッチファブリック間でいくつかの異なるマスタースレーブペアを形成するのを支援する各プロセッサ110に常駐する内部チップバス(「ICB」)ドライバモジュール103を含むマスタースレーブペアを動的に作成しサービスするためのシステム101を示す機能ブロック図である。 バスアーキテクチャに関するスイッチファブリックの詳細を示す機能ブロック図である。 異なるスイッチファブリック内に位置するマスタースレーブペア間の様々なルートをサポートするためのノードグラフの図である。 図4に示す第1のスイッチファブリックのマスターレベルノードに関する第1のルートチェックテーブルである。 図4に示す第2のスイッチファブリックのマスターレベルノードに関する第2のルートチェックテーブルである。 ポータブルコンピューティングデバイス(「PCD」)のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法を示す論理フローチャートである。 スレーブ識別子を使用してスレーブを検索するためのサブ方法またはルーチンを示す論理フローチャートである。 例示的な第1のソフトウェア要求タイプを示す図である。 例示的な第2のソフトウェア要求タイプを示す図である。 図9A〜図9Bに示すソフトウェア要求タイプから導出されたIbおよびAbの値を利用して、PCDのソフトウェア要求からの現在の需要に基づいてバスまたはスイッチファブリックの設定を動的に調整するための、図7に対応する、サブ方法またはルーチンを示す論理フローチャートである。 システムおよび方法によってマスタースレーブペアが作成されるときに作成されるハンドルを示す図である。 図1のポータブルコンピューティングデバイスのリソースを管理するノードアーキテクチャの第1の態様の図である。 図1のPCDのリソースを管理するノードアーキテクチャの第2の態様の一般的な図である。 図1のPCDのリソースを管理するノードアーキテクチャの第2の態様の具体的な図である。 PCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示すフローチャートである。 PCDのリソースを管理するためのノードアーキテクチャを作成するための方法を示す図10Dの続きのフローチャートである。 PCDにおけるソフトウェアアーキテクチャにおけるノード構造データを受信するための図10Dのサブ方法またはルーチンを示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるノードを作成するための図10D〜図10Eのサブ方法またはルーチンを示すフローチャートである。 PCDのソフトウェアアーキテクチャにおけるクライアントを作成するための図12のサブ方法またはルーチンを示すフローチャートである。 PCD向けのソフトウェアアーキテクチャにおけるリソースに対するクライアント要求を作成するための方法を示すフローチャートである。

「例示的な」という言葉は、「一例、実例または例として」を意味するように本明細書で使用される。「例示的な」ものとして本明細書で説明する態様は、必ずしも他の態様よりも好ましい、または有利であると解釈されるわけではない。

本明細書では、「アプリケーション」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「アプリケーション」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。

「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなど、実行可能コンテンツを有するファイルを含むこともある。加えて、本明細書で言及する「コンテンツ」は、開封される必要があり得るドキュメント、またはアクセスされる必要がある他のデータファイルなど、本質的に実行可能ではないファイルを含むこともある。

本明細書で使用される場合、「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、実行中のソフトウェアを問わず、コンピュータ関連のエンティティを指すことが意図されている。たとえば構成要素は、プロセッサ上で作動しているプロセス、プロセッサ、オブジェクト、実行ファイル、実行スレッド、プログラムおよび/またはコンピュータであってよいが、これらであることに限定されない。例を挙げると、コンピューティングデバイス上で作動しているアプリケーションとコンピューティングデバイスの両方が構成要素であり得る。1つまたは複数の構成要素は、プロセスおよび/または実行スレッドの中に存在してよく、1つの構成要素を1つのコンピュータに局在化すること、および/または2つ以上のコンピュータに分散することが可能である。加えて、これらの構成要素は、様々なデータ構造を記憶している様々なコンピュータ可読媒体から実行することができる。各構成要素は、1つまたは複数のデータパケット(たとえば、信号を介してローカルシステム、分散システムにおける別の構成要素と相互作用するある構成要素からのデータ、および/または信号を介してインターネットなどのネットワーク上で他のシステムと相互作用するある構成要素からのデータ)を有する信号に従うなどしてローカルプロセスおよび/またはリモートプロセスを介して通信することができる。

本明細書では、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス電話」、「ワイヤレス通信デバイス」、および「ワイヤレスハンドセット」という用語は交換可能に用いられる。第3世代(「3G」)および第4世代(「4G」)ワイヤレス技術が出現したことによって、利用可能な帯域が拡大されたので、より多くのワイヤレス機能を備えたより携帯が容易なコンピューティングデバイスが利用可能になっている。

本明細書では、「ポータブルコンピューティングデバイス」(「PCD」)という用語は、バッテリーなど限られた容量の電源で動作する任意のデバイスを説明するために使用される。何十年もの間バッテリー式PCDが使用されてきたが、第3世代(「3G」)および第4世代(「4G」)ワイヤレス技術の出現とともにもたらされた充電式バッテリーの技術的進歩は、複数の機能を有する多数のPCDを可能にした。したがって、PCDは、とりわけ、セルラー電話、衛星電話、ページャ、携帯情報端末(「PDA」)、スマートフォン、ナビゲーションデバイス、スマートブックまたはリーダー、メディアプレーヤ、上述のデバイスの組合せ、およびワイヤレス接続を有するラップトップコンピュータであり得る。

図1:PCD100のマスタースレーブペアを動的に作成しサービスするためのシステム要素
図1を参照すると、この図は、スイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法およびシステムを実現するためのワイヤレス電話の形態によるPCD100の例示的で非限定的な態様の機能ブロック図である。図示のように、PCD100は、マルチコアである中央処理装置(「CPU」)110A、グラフィックスプロセッサ110B、およびアナログ信号プロセッサ126を有するオンチップシステム102を含む。これらのプロセッサ110A、110B、および126は結合され得る。

当業者によって理解されるように、CPU110Aは、第0のコア222、第1のコア224、および第Nのコア226を含み得る。代替実施形態では、CPU110Aおよびグラフィックスプロセッサ110Bを使用する代わりに、当業者によって理解されるように1つまたは複数のデジタル信号プロセッサ(「DSP」)を用いることもできる。

PCD100は、プロセッサ110によって実行される内部チップバス(「ICB」)ドライバモジュール103を含み得る。当業者は、本開示から逸脱することなく、様々な部分に分割され、異なるプロセッサ110、126によって実行され得る1つまたは複数のソフトウェアモジュールを各ICBドライバモジュール103が含み得ることを認識されよう。

ICBドライバモジュール103は、アプリケーションプログラムモジュール105によって出されたソフトウェア要求を処理しサポートするためのマスタースレーブペアの動的な作成およびサービスの役目を果たすことができる。2つのタイプのICBドライバモジュール103、すなわち、上位層(「UL」)タイプ103A、および下位層(「LL」)タイプ103Bがあり得る。一般的に、UL ICBドライバタイプ103Aは通常、様々なアプリケーションモジュール105をサポートすることができる1つまたは複数のプロセッサ110、126によって実行される。LL ICBドライバタイプ103Bは通常、リソース電力マネージャ107と呼ばれる1つのハードウェア要素によって実行される。

LL ICBドライバ103Bを実行しているリソース電力マネージャ107は一般に、帯域幅値を適用し設定する役目を果たす。これらの帯域幅値は、リソース電力マネージャ107によって、図2に関連して以下で説明する1つまたは複数のバスおよび/またはスイッチファブリックに適用される。リソース電力マネージャ107は一般に、スイッチファブリックおよびバスのクロック速度ならびにスレーブのクロック速度を設定する役目を果たす。スレーブは一般に、アプリケーションプログラム105を実行しているマスタープロセッサ110からの要求をサポートするハードウェア構成要素である。

ICBドライバ103A、Bは、リソース電力マネージャ107との組合せで、同様のスイッチファブリック内および/または異なるスイッチファブリック間に存在し得るハードウェア構成要素についての実行時におけるマスタースレーブペアの動的な作成を可能にする。ICBドライバ103A、Bおよびリソース電力マネージャ107は、オンザフライまたはリアルタイムでスイッチファブリックおよびバスのための帯域幅を計算し調整することができる。

特定の態様では、本明細書で説明する方法ステップうちの1つまたは複数は、ICBドライバ103A、Bを含むメモリ112に記憶された実行可能命令およびパラメータによって実施され得る。ICBドライバ103A、Bを形成するこれらの命令は、CPU110、アナログ信号プロセッサ126、およびリソース電力マネージャ107によって実行され得る。さらに、プロセッサ110A、126、メモリ112、メモリ112に記憶された命令、またはそれらの組合せは、本明細書で説明する方法ステップのうちの1つまたは複数を実行するための手段として機能し得る。

図1:PCD100の他の要素
図1に示すように、ディスプレイコントローラ128およびタッチスクリーンコントローラ130が、マルチコアCPU110Aに結合される。オンチップシステム102の外部にあるタッチスクリーンディスプレイ132が、ディスプレイコントローラ128およびタッチスクリーンコントローラ130に結合される。

図1はまた、マルチコア中央処理装置(「CPU」)110Aに結合された、ビデオコーダ/デコーダ(「コーデック」)134、たとえば位相反転線(「PAL」)エンコーダ、順次式カラーメモリ(「SECAM」)エンコーダ、全米テレビジョン方式委員会(「NTSC」)エンコーダ、または任意の他のタイプのビデオエンコーダ134を示している。ビデオ増幅器136が、ビデオエンコーダ134およびタッチスクリーンディスプレイ132に結合される。ビデオポート138がビデオ増幅器136に結合される。図2に示すように、ユニバーサルシリアルバス(「USB」)コントローラ140がCPU110Aに結合される。また、USBポート142がUSBコントローラ140に結合される。加入者識別モジュール(SIM)カード146も、CPU110Aに結合され得る。さらに、図1に示すように、デジタルカメラ148がCPU110Aに結合され得る。例示的な態様では、デジタルカメラ148は、電荷結合デバイス(「CCD」)カメラまたは相補型金属酸化膜半導体(「CMOS」)カメラである。

図1にさらに示されるように、ステレオオーディオコーデック150が、アナログ信号プロセッサ126に結合され得る。さらに、オーディオ増幅器152が、ステレオオーディオコーデック150に結合され得る。例示的な態様では、第1のステレオスピーカー154および第2のステレオスピーカー156が、オーディオ増幅器152に結合される。図1は、マイクロフォン増幅器158もステレオオーディオコーデック150に結合され得ることを示している。加えて、マイクロフォン160が、マイクロフォン増幅器158に結合され得る。特定の態様では、周波数変調(「FM」)無線チューナー162がステレオオーディオコーデック150に結合され得る。また、FMアンテナ164がFM無線チューナー162に結合される。さらに、ステレオヘッドフォン166がステレオオーディオコーデック150に結合され得る。

図1は、図1は、高周波(「RF」)トランシーバ168がアナログ信号プロセッサ126に結合され得ることをさらに示している。RFスイッチ170が、RFトランシーバ168およびRFアンテナ172に結合され得る。図1に示すように、キーパッド174がアナログ信号プロセッサ126に結合され得る。また、マイクロフォンを備えたモノヘッドセット176が、アナログ信号プロセッサ126に結合され得る。さらに、バイブレータデバイス178が、アナログ信号プロセッサ126に結合され得る。図1は、たとえばバッテリーなどの電源180がオンチップシステム102に結合されることも示している。特定の態様では、電源180は、充電式DCバッテリー、または交流(「AC」)電源に接続されたAC-DC変換器から導出されたDC電源を含む。

図1に示されるように、タッチスクリーンディスプレイ132、ビデオポート138、USBポート142、カメラ148、第1のステレオスピーカー154、第2のステレオスピーカー156、マイクロフォン160、FMアンテナ164、ステレオヘッドフォン166、RFスイッチ170、RFアンテナ172、キーパッド174、モノヘッドセット176、バイブレータ178、熱センサ157B、および電源180は、オンチップシステム102の外部にある。

図2は、マスタースレーブペアを動的に作成しサービスするためのシステム101を示す機能ブロック図である。このシステムは、たいていは各プロセッサ110に常駐する上位層(「UL」)内部チップバス(「ICB」)ドライバモジュール103Aを含む。ICBドライバモジュール103Aは、PCD100のスイッチファブリック内およびスイッチファブリック間でいくつかの異なるマスタースレーブペアを形成するのを支援することができる。システム101はまた、たいていはリソース電力マネージャ102内に常駐する下位層(「LL」)ICBドライバ103Bを含む。

上記のように、ICBドライバモジュール103は一般にソフトウェアを含む。ただし、ドライバモジュール103は、ハードウェアおよび/またはハードウェアとソフトウェアの組合せで実装され得る。各UL ICBドライバモジュール103Aは、それぞれのプロセッサ110によって実行されるそれぞれのアプリケーションプログラムモジュール105に結合され得る。たとえば、第1のUL ICBモジュール103A1は、第1のアプリケーションプログラムモジュール105A1および第2のアプリケーションプログラムモジュール105A2に結合され得る。

アプリケーションプログラムモジュール105は、PCD100のために利用可能な任意の数の異なるタイプのプログラムモジュールを含み得る。たとえば、プログラムモジュール105は、限定はしないが、ビデオゲーム、オーディオファイル、およびビデオのようなエンターテインメントプログラミングをサポートするためのグラフィックス処理ソフトウェア、ワード処理、電子メール、スプレッドシート、カレンダーなどのようなビジネスアプリケーションをサポートするためのビジネスソフトウェアを含み得る。他のプログラムモジュール105は、限定はしないが、全地球測位衛星(「GPS」)プログラムなどのナビゲーションプログラム、ショッピング用、学習用などのダウンロード可能なカスタマイズされたアプリケーションなどを含む。

図2には、4つの中央処理装置(「CPU」)110A、110B、110C、および110Nが示されている。各CPU110は、それぞれのスイッチファブリック107に結合され得る。スイッチファブリック107に関するさらなる詳細については、図3に関連して以下で説明する。

第1のスイッチファブリック107Aは、第1および第2のCPU110A、110B、モバイルディスプレイプロセッサ110D、ダブルデータレート同期型ダイナミックランダムアクセスメモリ(「DDR SDRAM」)112、構成ポート111、およびリソース電力マネージャ102に結合され得る。第2のスイッチファブリック107Bは、第3のCPU110C、動的メモリ割振り/アクセス(「DMA」)エンジン109、リソース電力マネージャ102、外部バスインターフェース113、およびデジタル信号プロセッサ114に結合され得る。第3のスイッチファブリック107Nは、第4のCPU110N、マスターハードウェア要素115、およびスレーブハードウェア要素117に結合される。

第1のCPU110Aは、システム101のマスタースレーブ階層における第1のマスターと呼ばれ得る。第2のCPU110B、第3のCPU110C、および第4のCPU110Nは、それぞれ第2、第3、および第4のマスターと呼ばれ得る。他のマスターは、限定はしないが、第5のマスターとして動作するモバイルディスプレイプロセッサ110D、第6のマスターとして動作するデジタル信号プロセッサ(「DSP」)、および第7のマスターとして動作する動的メモリ割振り/アクセス(「DMA」)エンジン109を含み得る。

一方、構成ポート111、DDRメモリ112、および外部バスインターフェース113は、システム101のマスタースレーブ階層における第1、第2、および第3のスレーブと呼ばれ得る。これらのスレーブの各々は、それぞれのマスターによって生成されたソフトウェア要求をサービスすることができる。

前記のように、7つのマスターが図2に示されている。当業者は、より少ない数またはより多い数のマスターを、システム101においてその範囲を変えることなく用いてもよいことを諒解されよう。これはスレーブにも当てはまり、当業者によって理解されるように、より少ない数またはより多い数のスレーブを用いてもよい。

CPU110上に常駐するUL ICBドライバ103Aは、それぞれのマスターCPU110の各アプリケーションプログラムモジュール105によって出されたソフトウェア要求を確認することができる。UL ICBドライバ103Aはまた、LL ICBドライバ103Bとの組合せで、ソフトウェア要求の確認およびそれらの対応する需要に応答して、スイッチファブリック107の設定を調整することもできる。

PCD100の例示的な実施形態では、システム101におけるマスターの数はしばしば、スレーブの数を上回る。たとえば、システム101を有するPCD100は、約40から約50の間の数のマスター、および約10から約15の間の数のスレーブを有し得る。

例示的なシステム101によれば、UL ICBドライバ103は、アプリケーションプログラムモジュール105からクライアント要求を受信し得る。たとえば、第1のUL ICBドライバ103A1は、第1のアプリケーションプログラムモジュール105A1からクライアント作成要求(create client request)を受信し得る。クライアント作成要求は、モバイルディスプレイプロセッサ(「MDP」)110D(マスター)および外部バスインターフェース113(スレーブ)などのマスタースレーブペアを含むことができる。

MDP110D(マスター)は第1のスイッチファブリック107A内に常駐し、外部バスインターフェース113(スレーブ)は第2のスイッチファブリック107B内に常駐する。従来技術では、クライアント要求の作成に先立つ実行時に先立って、静的な、または停滞したテーブルが作成される必要がある。この静的なテーブルには、MDP110D(マスター)と外部バスインターフェース113(スレーブ)との間の関係およびルートが記載される。

この時点で静的なテーブルにアクセスする代わりに、システム101は、MDP110D(マスター)と外部バスインターフェース113(スレーブ)との間の1つまたは複数の通信ルートを決定するために、スイッチファブリック107で検索を実行することができる。マスターとスレーブとの間のこのルートが決定されると、システム101は、異なるスイッチファブリック107内および異なるスイッチファブリック107間で伸び得る通信ルートのための帯域幅を設定することができる。PCD100のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法のさらなる詳細については、図4〜図10に関連して以下で説明する。

図3は、図2の第1のスイッチファブリック107Aの詳細を示す機能ブロック図である。スイッチファブリック107Aは一般に、当業者によって理解されるように、バスアーキテクチャと呼ばれ得る。この図における文字「M」は、スイッチファブリック107Aのマスタースレーブ階層におけるマスターを表し、この図における文字「S」はスレーブを表す。

第1のスイッチファブリック107Aは、ネットワークノード(M1、M2、M5、S1、S2)がクロスバースイッチ307などの1つまたは複数のネットワークスイッチを介して互いに接続されるネットワークトポロジーを含む。図3に示すこの第1のスイッチファブリック107Aは全般的に、図2の第1のスイッチファブリック107Aに対応する。スイッチファブリック107Aは、トラフィックが複数の物理リンクに拡散されるので、他のバス設計と比較して、より良好な総スループットをもたらすことができる。

図3の例示的な実施形態では、第1のマスター1 110Aは、第1のスレーブ1 111および第2のスレーブ2 112に結合され得る。同様に、第2のマスター2 110Bは、第1のスレーブ1 111および第2のスレーブ2 112に結合され得る。以下同様である。本明細書執筆時点でスイッチファブリック107の例示的な実装形態は、PCI Expressである。図3に示すように、例示的な第1のスイッチファブリック107Aの3つのマスターM1、M2、およびM5は、それぞれのスレーブに接続するために、様々なクロスバースイッチ307A、307B、および307Cの各々を利用することができる。

図4は、3つの異なるスイッチファブリック107A、107B、および107C内に位置するマスタースレーブペア間の様々なルートをサポートするためのノードグラフまたはノードアーキテクチャ403の図である。ノードアーキテクチャ403は、異なるスイッチファブリック107内および異なるスイッチファブリック107間に位置するマスタースレーブペア間の関係をICBドライバ103がどのように特徴付けるかを示している。

ノードアーキテクチャ403は、第1のスイッチファブリック107Aに結合されたアービタノード405を含む。アービタノード405は、各スイッチファブリック107のために存在し得る。ただし、図4は、第1のスイッチファブリック107Aのための単一のアービタノード405のみを示している。アービタノード405は、特定のマスターハードウェアデバイス上で動作しているアプリケーションモジュール105の各々からソフトウェア要求を受信し得る。

第1のスイッチファブリックは、3つのマスター、すなわち、図2の第1のCPU110Aに対応する第1のマスターノードM1 110A、第2のCPU110Bに対応する第2のマスターノードM2 110B、およびMDP110Dに対応する第5のマスターノードM5 110Dを含む。

第1のスイッチファブリック107Aは、2つのスレーブ、すなわち、図2の構成ポート111に対応する第1のスレーブノードS1 111、およびDDR SDRAM112に対応する第2のスレーブノードS2 112を有する。第1のスイッチファブリック107は、第1のゲートウェイノードG1 400A1および第2のゲートウェイノードG2 402A1をさらに含むことができる。スイッチファブリック107の各第2のゲートウェイノードG2 402は、別のスイッチファブリックの第1のゲートウェイノードG1 400に結合される。各第2のゲートウェイノードG2 402は、2つの異なるスイッチファブリック107間の通信を発生させ、一方で、各対応する第1のゲートウェイノードG1 400は、その通信を受信する。

たとえば、第1のスイッチファブリック107Aの第2のゲートウェイノードG2 402A1は、第1のスイッチファブリック107Aから第2のスイッチファブリックの第1のゲートウェイノードG1A 400B1に送られる通信を発生させ得る。逆に、第2のゲートウェイノードG2A 402B1は、第2のスイッチファブリック107Bから第1のスイッチファブリック107Aの第1のゲートウェイノードG1 400A1に送られる通信を発生させ得る。

特定のスイッチファブリック107の各第2のゲートウェイノードG2 402は、特定のスイッチファブリック107のマスターに対するスレーブとして機能することができ、そして、第2のゲートウェイノードG2 402が別のスイッチファブリック107上の第1のゲートウェイノードG1 400などの別のゲートウェイノードとの通信を確立しているときに、マスターとして機能することができる。たとえば、第2のマスターM2 110Bから第2のゲートウェイノードG2 402A1に流れる通信の場合、第2のゲートウェイノードG2 402A1は、第2のマスターM2 110Bに対するスレーブとして機能する。一方、第2のスイッチファブリック107B上の第1のゲートウェイノードG1A 400B1に対して、第2のマスターM2 110Bはマスターとして機能し、第1のゲートウェイノードG1A 400B1は、第2のゲートウェイノードG2 402A1に対するスレーブとして機能する。他の例示的な実施形態では、異なるスイッチファブリック107間の第1および第2のゲートウェイG1 400およびG2 402の間のこれらのペアリングは、スレーブとしてもマスターとしても動作する単一のゲートウェイノード(図示せず)によってソフトウェアで表され得る。

第1および第2のゲートウェイノードG1 400およびG2 402は、異なるスイッチファブリック107間の通信を可能にする。第1および第2のゲートウェイノードG1 400およびG2 402を使用することによって、第1のファブリック107AのマスターMは、図4に示すように第2のスイッチファブリック107Bなどの異なるスイッチファブリック107に常駐し得る特定のスレーブノードSの位置を特定し得る。

たとえば、第1のファブリック107のためのアービタノード405から発生するソフトウェア要求が、第1のスイッチファブリック107Aの第5のマスターノードM5 110Dおよび第2のスイッチファブリック107Bの第3のスレーブノードS3 113を含むマスタースレーブペアを要求したと仮定する。ICBドライバ103は最初に、要求された第3のスレーブノードS3 113が第1のスイッチファブリック107Aの一部であるか否かを判断する。ICBドライバ103は、要求された第3のスレーブS3 113の識別子を、第1のスイッチファブリック107Aの第1および第2のスレーブノードS1およびS2の識別子と比較する。

要求された第3のスレーブノードS3 113が第1のスイッチファブリック内に存在しないとICBドライバ103が判断すると、ICBドライバ103は、(ラインセグメントAに沿って)第2のゲートウェイノードG2 402A1に対し、次のスイッチファブリック107Bで検索を実行するよう求める要求を出す。次いで、第2のゲートウェイノードG2 402A1は、第1のゲートウェイ400B1に対し(ラインセグメントBに沿って)、要求された第3のスレーブノードS3 113について第2のスイッチファブリック107Bの検索を実行するよう求めるコマンドまたは命令を出す。次いで、第2のスイッチファブリック107Bの第1のゲートウェイ400B1は、第3のスレーブノードS3 113についての検索を、第2のスイッチファブリック107BのスレーブノードSに対する比較の土台として、第3のスレーブノードS3の一意の識別子を使用して実行する。

第3のスレーブノードS3 113が発見されると、第1のゲートウェイG1A 400B1は、(ラインセグメントCに沿って)第3のスレーブノードS3 113と第1のスイッチファブリック107Aの第5のマスター110Dとの間の通信リンクを確立するよう求めるコマンドを出す。したがって、ICBドライバ103は、第1のスイッチファブリック107Aの第5のマスター110Dと第2のスイッチファブリック107Bの要求された第3のスレーブS3 113との間で確立されたルートを記録する。

図4に示すように、第2のスイッチファブリック107Bは、3つのマスターノードM3 110C、M6 114、およびM7 109を含むことができ、マスターノードM3 110Cは、図2の第3のプロセッサ110Cに対応し、マスターノードM6は、図2のDSP114に対応し、マスターノードM7 109は、図2のDMAエンジン109に対応する。第2のスイッチファブリック107Bは、第2のスイッチファブリック107Bを第3のスイッチファブリック107Cに結合する追加のゲートウェイノードG1B 400B2およびG2B 402B2をさらに含むことができる。同様に、第3のスイッチファブリック107Cは、2つのマスターノードM4 110NおよびMN 115ならびに単一のスレーブノードSN 117を含み得る。

ノードアーキテクチャ403は、RPMノード102に結合される3つのスイッチファブリックノード407A、407B、および407Cをさらに含み得る。スイッチファブリックノード407は、図2のスイッチファブリック107に対応し得る。同様に、RPMノード102は、図2のリソース電力マネージャ102に対応し得る。

RPMノード102はスイッチファブリックノード407に対し、特定のスイッチファブリック107内のノードのためのそれぞれの帯域幅パラメータを制御するためにコマンドを出すことができる。図4に示すように、スイッチファブリック107の各スレーブSまたは第2のゲートウェイG2は、対応するファブリックノード407に結合される。

図5は、図4に示す第1のスイッチファブリック107Aのマスターレベルノードに関する第1のルートチェックテーブル507である。第1のルートチェックテーブル507は、それぞれのマスターによってチェックされ得る第1のスイッチファブリック107Aのスレーブを記載しており、ICBドライバモジュール103が、オンザフライで、または動的にマスタースレーブペアを形成している。このルートチェックテーブル507は、ICBドライバモジュール103によって、特定のソフトウェアアプリケーションモジュール105によって出されたソフトウェア要求において要求された特定のスレーブを第1のスイッチファブリック107A内で検索するときに使用される。テーブル507における1の値は、特定のスレーブがソフトウェア要求におけるスレーブと合致するか否かを判断するために、それぞれのマスターが特定のスレーブに尋ねることができることを示している。テーブル507における0の値は、特定のスレーブがソフトウェア要求におけるスレーブと合致するか否かを判断するために、それぞれのマスターが特定のスレーブに尋ねることができないことを示している。

たとえば、図4の第1のゲートウェイG1 400A1が第2のスイッチファブリック107Bの第2のゲートウェイG2A 402B1から発生する通信のマスターとして動作しているとき、第1のゲートウェイG1 400A1は、テーブル507の第2の行の第3の列に0で表されているように、第2のゲートウェイG2 402A1でスレーブについての検索を実行することを許容されない。第2のゲートウェイG2 402A1に対するスレーブについての検索のブロックにより、そのような検索が第1のゲートウェイG1 400A1と第2のゲートウェイG2 402A1との間で許容された場合に生じるとみられる無限のプログラミングループを防ぐことができる。

図6は、図4に示す第2のスイッチファブリック107Bのマスターレベルノードに関する第2のルートチェックテーブル607である。第2のルートチェックテーブル607は、それぞれのマスターによってチェックされ得る第2のスイッチファブリック107Bのスレーブを記載しており、ICBドライバモジュール103が、オンザフライで、または動的にマスタースレーブペアを形成している。このルートチェックテーブル607は、ICBドライバモジュール103によって、特定のソフトウェアアプリケーションモジュール105によって出されたソフトウェア要求において要求された特定のスレーブを第2のスイッチファブリック107B内で検索するときに使用される。テーブル607における1の値は、特定のスレーブがソフトウェア要求におけるスレーブと合致するか否かを判断するために、それぞれのマスターが特定のスレーブに尋ねることができることを示している。テーブル607における0の値は、特定のスレーブがソフトウェア要求におけるスレーブと合致するか否かを判断するために、それぞれのマスターが特定のスレーブに尋ねることができないことを示している。

たとえば、図4の第1のゲートウェイG1B 400B2が第3のスイッチファブリック107Cの第2のゲートウェイG2 402C1から発生する通信のマスターとして動作しているとき、第1のゲートウェイG1B 400B2は、テーブル607の第4の行の第3の列に0で表されているように、第2のゲートウェイG2B 402B2でスレーブについての検索を実行することを許容されない。第2のゲートウェイG2B 402B2に対するスレーブについての検索のブロックにより、そのような検索が第1のゲートウェイG1B 400B2と第2のゲートウェイG2B 402B2との間で許容された場合に生じるとみられる無限のプログラミングループを防ぐことができる。第3のスイッチファブリック107Cもルートチェックテーブルを有する。ただし、第3のスイッチファブリック107のそのようなルートテーブルは、図示されておらず、当業者によって理解されるように容易に生成される。

図7は、ポータブルコンピューティングデバイス(「PCD」)のスイッチファブリック107内およびスイッチファブリック107間でマスタースレーブペアを動的に作成しサービスするための方法700を示す論理フローチャートである。ブロック705が、方法700の最初のステップである。ブロック705において、ICBドライバモジュール103は、マスタースレーブペアを含むクライアント要求を受信することができる。クライアント要求は、図2に示すような第1のCPU110などのプロセッサ上で動作しているアプリケーションプログラムモジュール105によって生成され得る。

次に、ルーチンブロック710において、ICBドライバモジュール103は、ブロック705においてクライアント要求で提供されたマスタースレーブペアにおけるスレーブについての検索を実行することができる。ICBドライバ103は、検索を実行するために、要求されたスレーブに対応する一意の識別子を使用することができる。このルーチンブロック710において、ICBドライバモジュール103は、要求されたスレーブについての検索を実行するために、図4に示すノードアーキテクチャ403を利用する。このルーチンブロック710のさらなる詳細について、図8に関連して以下で説明する。通常、図2に示すような対応するCPU110上に常駐し得る上位層ICB(「UL ICB」)ドライバ103Aが、このルーチンブロック710のステップを実行することができる。

ルーチンブロック710の後、ブロック715において、ICBドライバモジュール103は、ルーチンブロック710において実行された検索に基づいて、マスタースレーブペアのためにスイッチファブリック107内およびスイッチファブリック107間でルートを作成する。このルートは、図4に示すように、第5のマスターM5 110Dなどのマスターを通常含む開始点を記録する。ルートはまた、選択されたマスタースレーブペア間の通信を確立するように横断する図4に示すような3つのセグメントA、B、およびCを含む。

次に、ブロック720において、異なるスイッチファブリック107内および/または異なるスイッチファブリック107間に存在し得るマスタースレーブペアを形成する特定のノードを記載したハンドルまたは配列が、クライアント要求を発生させたアプリケーションプログラムモジュール105に戻される。その後、ルーチンブロック725において、ICBドライバモジュール103は、任意のスイッチファブリック107内およびスイッチファブリック107間で確立されたルートの帯域幅を設定することができる。このルーチンブロック725によれば、下位層ICB(「LL ICB」)ドライバモジュール103Bがこのルーチンのステップを実行する。RPM102上に常駐するLL ICBドライバモジュール103Bは、図4に示すように、RPMノード102からファブリックノード407および特定のファブリック107のノードにコマンドを出すことによって、確立されたルート上の帯域幅を設定する。ルーチンブロック725に関するさらなる詳細については、図9に関連してさらに詳しく説明する。

次にブロック730において、次いで、クライアント要求内の要求されたアクションが、異なるスイッチファブリック107内および/または異なるスイッチファブリック107間に存在し得るマスタースレーブペアによって実行される。方法700はブロック705に戻るか、または終了し得る。

図8は、スレーブ識別子を使用してマスタースレーブペアのスレーブを検索するためのサブ方法またはルーチン715を示す論理フローチャートである。ブロック805が、サブ方法またはルーチン715の最初のステップである。ブロック805において、ICBドライバモジュール103Aは、クライアント要求からのマスタースレーブペアの要求されたスレーブを識別するために、特定のファブリック107内でどのスレーブに問合せ可能であるかを判断するために、それぞれ図5および図6に示すテーブル500およびテーブル600などのファブリックルートチェックテーブルを確認する。

次に、ブロック810において、ICBドライバモジュール103Aは、要求されたスレーブのスレーブ識別子を、ルートチェックテーブルに記載されたスレーブ識別子と比較することができる。次に、決定ブロック815において、ICBドライバモジュール103Aは、現在のスレーブ識別子間で合致があるか否かを判断する。決定ブロック815への照会が肯定である場合、「はい」の分岐がブロック825に至る。決定ブロック815への照会が否定である場合、「いいえ」の分岐が決定ブロック820に至る。

ブロック825において、ICBドライバ103Aは、合致したスレーブに到達するように横断しているルートを記録する。このルートは、単一のスイッチファブリック107内でのみ生じる通信セグメント、または1つもしくは複数の異なるスイッチファブリック107を横断する通信セグメントを含むことができる。次に、ブロック830において、ICBドライバモジュール103Aは、アプリケーションプログラムモジュール105によって出されたクライアント要求に含まれていたマスタースレーブペアを確立するように横断するノードのすべてを記載したハンドルまたは配列を返すことができる。次いで、サブ方法またはルーチン715は図7のステップ715に戻る。

決定ブロック815の否定状態に達したときに生じる決定ブロック820を再び参照すると、ICBドライバモジュール103Aは、要求されたスレーブに関して、特定のスイッチファブリックのスレーブのすべてに問い合わせているか否かを判断する。決定ブロック820への照会が否定である場合、「いいえ」の分岐がブロック805に戻る。決定ブロック820への照会が肯定である場合、「はい」の分岐がブロック835に至り、ICBドライバモジュール103Aは、図4に示すようなゲートウェイノードG2 402A1などのゲートウェイノードに進む。

次に、ブロック840において、ゲートウェイ識別子がICBドライバモジュール103Aによって記憶される。次いでブロック845において、ICBドライバモジュール103Aは、第2のスイッチファブリック107Bなどの次のスイッチファブリック107に入り、ブロック805に戻ることによって新しい検索を開始する。ブロック845は一般に、ICBドライバモジュール103Aがマスターとして第1のゲートウェイノードG1A 400B1を利用することに対応し得る。ブロック805において、第1のゲートウェイG1A 400B1が検索に利用される現在のマスターであると仮定すると、ICBドライバモジュール103Aは、図6に示すファブリックルートチェックテーブル600の第3の行を見る。

以下でさらに詳細に説明するように、方法700およびシステム101は、スイッチファブリック107内およびスイッチファブリック107間で帯域幅を管理するために、あるメトリクスを利用する。図9A〜図9Bは、特定のプロセッサ110上で動作しているアプリケーションプログラムモジュール105によって出される任意のソフトウェア要求の一部であるのが普通である帯域幅要件を管理するために、方法700およびシステム101によって使用されるメトリクスを示している。

具体的には、図9Aは、例示的な第1のソフトウェア要求タイプ401を示している。この第1のソフトウェア要求タイプ401は、「バースト的」と特徴付けられるものから発生し得る。第1の「バースト的」ソフトウェア要求タイプ401などの各ソフトウェア要求は、2つの異なるメトリクス、すなわち瞬時帯域幅(Ib)および平均帯域幅(Ab)により測定され得る。

瞬時帯域幅(Ib)は、スイッチファブリック107のマスタースレーブ階層におけるすべてのマスターにわたるスイッチファブリック107に関する最悪状況ニーズ/シナリオを表し得る。Ibは、スイッチファブリック107の周波数を設定するためにICBドライバモジュール103によってこのパラメータが使用され得るので、一般にバスまたはスイッチファブリックの「制限速度」と特徴付けられ得る。Ibを決定するための計算および/または対応する式は、特定のアプリケーションプログラムモジュール105から発生するソフトウェア要求の各タイプに固有であり得る。

平均帯域幅(Ab)は、1つまたは複数のスイッチファブリック107で伝播される実際のデータサイズを表し得る。Abは、1つまたは複数のスイッチファブリック107のマスターおよびスレーブの間でアービトレーションルールを設定するために、ICBドライバモジュール103によって使用され得る。

第1のソフトウェア要求タイプ401は、1つまたは複数のスイッチファブリック107の不連続使用をもたらすソフトウェア要求に対処するために「バースト的」と特徴付けられた。これらのソフトウェア要求タイプは、極めて短い時間間隔内にスイッチファブリック107間で大きいデータブロックを送信し、次いである期間、休止状態にとどまることがある。休止段階は通常、大きいデータブロックを送信するために使用される活動時間よりも長く続き得る。

第1の「バースト的」ソフトウェア要求タイプ401の場合、Ib値は以下の式によって決定され得る。
式:1 Ib=BS/W

式中、「Ib」は瞬時帯域幅であり、「BS」はバイト数で表現されるブロックサイズであり、「W」はミリ秒などの時間単位で表現されるウィンドウサイズである。

第1の「バースト的」ソフトウェア要求タイプのAb値は、以下の式によって決定され得る。
式:2 Ab=BS/P

式中、「Ab」は平均帯域幅であり、「BS」はバイト数で表現されるブロックサイズであり、「P」はミリ秒などの時間単位で表現される期間である。

図9Aは、2つの異なる「バースト的」ソフトウェア要求401A、401Bを示している。第1のソフトウェア要求401Aは第1のデータブロック402Aを有し、第2のソフトウェア要求401Bは第2のデータブロック402Bを有する。

この例示的な実施形態では、第1および第2の期間P1 404A、P2 404Bの大きさは等しく、(期間P1およびP2の中の時間枠である)第1および第2のウィンドウW1 406A、W2 406Bは、互いに異なる大きさを有する。第1および第2のブロックサイズBS1 408A、BS2 408Bも、互いに異なる大きさを有する。

第1のブロックサイズBS1 408Aの大きさは第1の期間P1 404Aに対して比較的小さいので、第1のバースト的ソフトウェア要求401Aの平均帯域幅Ab値は、このソフトウェア要求タイプに関する式(2)に鑑みてそれほど大きくはならない。一方、第2のブロックサイズBS2 408Bの大きさは第2の期間P2 404Bに対して比較的大きいので、第2のバースト的ソフトウェア要求401Bの平均帯域幅Ab値は、第1のソフトウェア要求401Aよりも少し大きくなる。

各ソフトウェア要求401A、401BのブロックサイズBSは、それらのウィンドウサイズW1 406A、W2 406Bに近い大きさを有するので、これら2つの要求401の瞬時帯域幅値Ibは、このソフトウェア要求タイプに関する式(1)に鑑みて大きくなり得る。これらの要求401A、401Bの両方のIb値はまた、互いに極めて近い大きさになり得る。

図9Bは、「CPU」タイプ501と特徴付けられ得る例示的な第2のソフトウェア要求タイプ501を示している。CPUソフトウェア要求タイプ501は通常、中央処理装置(CPU)110から発生する。瞬時帯域幅Ib値は次のように決定され得る。
式3: Ib=スループット帯域幅

式中、「Ib」は瞬時帯域幅であり、スループット帯域幅はCPU110の所望のクロック速度である。

CPUソフトウェア要求タイプ501の平均帯域幅Ab値は、次のように決定され得る。
式4: Ab=T×Z%(割合)

式中、「Ab」は平均帯域幅であり、「T」は上述のスループット帯域幅であり、「Z%」は図9Bに示すように使用の割合、またはキャッシュミスの割合である。

たとえば、50%の使用率により毎秒100Mbでデータを移動させるDMAエンジン109の場合、平均帯域幅Ab値は100×0.50、すなわち毎秒50Mbに等しくなる。このDMAエンジン109の瞬時帯域幅Ibは、毎秒100Mbに等しくなる。

一方、1GHzで動作しているCPU110は、毎秒800Mbのスループットに変わる。このスループット値は瞬時帯域幅Ibに等しくなる。キャッシュミス率が10%であるキャッシュをCPU110が利用する場合、平均帯域幅Ab値は(800×0.10)、すなわち毎秒80Mbに等しくなる。

当業者は、他のソフトウェア要求タイプが瞬時帯域幅Ibおよび平均帯域幅Abの値で別様に定義され得ることを認識されよう。これらのまだ決定されていないソフトウェア要求タイプは、IbおよびAbの値に到達するための異なる式を含み得る。しかし、ソフトウェア要求タイプはIbおよびAbの値で表現されることになるので、異なるソフトウェア要求タイプを総合して、バス107に対する現在の需要の良好な推定値をICBドライバモジュール103にもたらすことができる。

図9Cは、PCD100のソフトウェア要求からの現在の需要に基づいてバスまたはスイッチファブリックの設定を動的に調整するための(図7に対応する)サブ方法またはルーチン725を示す論理フローチャートである。このサブ方法725では、通常、図2に示すRPM102上に常駐するLL ICBドライバモジュール103Bがこれらのステップを実行する。ただし、当業者は、本開示の範囲から逸脱することなく、CPU110上に常駐するUL ICBドライバ103Aを使用してもよいことを認識する。

決定ブロック915が、サブ方法725の最初のステップである。ブロック915において、ICBドライバモジュール103Bは、標準化された瞬時帯域幅(Ib)および平均帯域幅(Ab)の値にソフトウェア要求が変換される必要があるか否かを判断する。決定ブロック915への照会が否定である場合、「いいえ」の分岐がブロック925に至る。決定ブロック915への照会が肯定である場合、「はい」の分岐がブロック920に至る。

ブロック920において、ICBドライバモジュール103Bは、ソフトウェア要求の帯域幅パラメータを、ソフトウェア要求タイプならびに図9Aおよび図9Bに関連して上述した式(1)〜(4)などの対応する式に基づいて、瞬時帯域幅(Ib)および平均帯域幅(Ab)の値に変換する。

ブロック925において、ICBドライバモジュール103Bは、PCD100のそれぞれのマスター110によって出されたすべてのソフトウェア要求に関するすべての平均帯域幅(Ab)値の合計を計算する。次に、ブロック930において、ICBドライバモジュール103Bは、2つの値の間、すなわち、最大瞬時帯域幅(Ib)値とすべてのソフトウェア要求に関するすべての平均帯域幅(Ab)値の合計(これはブロック925で計算された値である)とを比較した場合の最大値を判断する。

次に、ブロック935において、ICBドライバモジュール103Bは、ブロック930で計算された最大値(単一の最大Ib値とすべてのAb値の合計との間の最大値)に基づいて、バス周波数を設定する。ブロック940において、ICBドライバモジュール103Bは、すべてのソフトウェア要求にわたって合計された平均帯域幅(Ab)およびブロック935で確立されたクロック周波数値に基づいて、バス107のバスアービトレーション構成を設定する。

ブロック945において、ICBドライバモジュール103Bは、バス周波数およびバスアービトレーション構成を各スイッチファブリック107に送信する。そして、サブ方法725はブロック730に戻る。

図9Dは、システム101および方法700によってマスタースレーブペアが作成されるときに形成されるハンドルまたは配列データ構造1002を示す図である。ハンドル1002は、図4に示すノードに関連してICBドライバモジュール103Bによって使用される。図4に示す各ノードは、形成されるマスタースレーブペアに対するハンドル1002を提供される。図9Dに示すハンドル1002の特定のセットは、図4に示す第1のスイッチファブリック107Aの第5のマスターM5 110Dと第2のスイッチファブリック107Bの第3のスレーブS3 113との間のマスタースレーブペア形式に対応する。

図9Dに示すように、第1のスイッチファブリック107Aのアービタノード405に、図4のマスタースレーブペアM5/S3に関する第1のハンドル1002Aが割り当てられる。図4に示す第1のスイッチファブリック107の第5のマスターM5 110Dに、第2のハンドル1002Bが割り当てられる。同様に、図4の第1のスイッチファブリック107Aの第2のゲートウェイG2 402A1に、第3のハンドル1002Cが割り当てられる。図4の第2のスイッチファブリック107Bの第1のゲートウェイG1A 400B1に、第4のハンドル1002Dが割り当てられる。以下同様である。

各ハンドル1002は、ハンドル1002に割り当てられた現在のノードおよび現在のノードから情報を受信するか、または現在のノードに情報を送信する他のノードを含み得る。たとえば、第2のハンドル1002Bは、第1のスイッチファブリック107Aの第5のマスター110Dに対応する割り当てられたノードM5および第1のスイッチファブリック107Aの第2のゲートウェイノードG2 402A1を含み得る。

同様に、第4のハンドル1002Dは、第4のハンドル1002Dが割り当てられる第2のスイッチファブリック107Bの第1のゲートウェイG1A 400B1である現在のノードを含み得る。第4のハンドル1002Dは、第1のスイッチファブリック107Aの第2のゲートウェイG2 402A1をさらに含み得る。第4のハンドル1002Dは、第1のスイッチファブリック107Aの第2のゲートウェイノードG2 402A1と第2のスイッチファブリック107Bの第1のゲートウェイノードG1A 400B1との間に存在する図4の通信セグメント「B」に対応する。これらのハンドル1002の各々は、ICBドライバモジュール103によってメモリに記憶され得る。

以下で説明する図10A〜図13は、図4のノードアーキテクチャがどのように確立され維持されるかを説明するために提供される。図10Aは、図4に示すノードアーキテクチャを確立し維持するためのソフトウェアアーキテクチャ500Aの第1の態様の図である。

図10Aは、ソフトウェアまたはハードウェア(または両方)を表す機能ブロックを含む図である。図10Aは、限定はしないが以下のような複数のハードウェア要素およびソフトウェア要素に結合されたアーキテクチャまたはフレームワーク管理プログラム440を示している。ICBドライバモジュール103、一般に第1のハードウェア要素(ハードウェア要素#1)とも呼ばれる中央処理装置110、一般に第2のハードウェア要素(ハードウェア要素#2)とも呼ばれるCPU110のクロック442、一般に第3のハードウェア要素(ハードウェア要素#3)とも呼ばれるバスアービタまたはスケジューラ422、一般に第1のソフトウェア要素(ソフトウェア要素#1)とも呼ばれるバスプログラムA-444A、一般に第2のソフトウェア要素(ソフトウェア要素#2)とも呼ばれるバスプログラムB-444B、一般に第3のソフトウェア要素(ソフトウェア要素#3)とも呼ばれるクロックプログラムAHB、一般にキープレスとして示されるソフトウェア要素によって監視されるアクションまたは機能448、およびソフトウェア要素またはハードウェア要素または両方を含むレガシー要素450。

レガシーソフトウェア要素の一例には、限定はしないが、Dynamic Environment Manager(DEM)がある。これは、プロセッサスリープイベントのプロセッサ間通知を処理するソフトウェアモジュールである。たとえば、第1のプロセッサAはDEMを使用して、第2のプロセッサBがアイドル状態になった/アイドル状態から復帰したとの通知を受信する。より新しいハードウェアでは、このソフトウェア機能は、ルートプロセッサモジュール(RPM)サブシステム/通信プロトコルに組み込まれている。他のレガシーソフトウェア要素も存在し、本発明の範囲内に含まれる。

レガシーハードウェア要素の一例には、限定はしないがAMBA(Advanced Microcontroller Bus Architecture)のAdvanced High-performance Bus(AHB)がある。より古いPCD100では、AHBは一次システムバスを含み得るのに対し、より新しいPCD100では、システムバス構造(system bus fabric)107は完全に異なり、AHBバスは、新しいシステムバス構造を介して通信するように更新されてはいないモジュールと通信する特別なアプリケーションにのみ使用される。他のレガシーハードウェア要素も存在し、本発明の範囲内に含まれる。

フレームワーク管理プログラム440は、前述のハードウェア要素およびソフトウェア要素の各々と通信するノードのようなデータ構造を管理するコンピュータ命令のライブラリを含むことができる。フレームワーク管理プログラム440は、図10Aの破線Aの右側に示されているノード602、622、642、および646を形成し得る1つまたは複数のリソースの作成を担当することができる。

フレームワーク管理プログラム440は、CPU110上に常駐する各ICBドライバモジュール103と直接通信することができる。図10Aの右側にある各ノード602、622、642、および646は、図10Aの破線Aの左側にある各ソフトウェア要素またはハードウェア要素の代表またはモデルである。図10Aの右側は全般的に、上述の図4に反映されているノードアーキテクチャに対応する。本開示の残りについては、一般的なノードまたは不特定のノードが、図10Bに示す参照番号601により指定される。

すでに述べたように、図10Aの例示的な各ノード602、622、642、および646は、1つまたは複数のリソースを含むことができる。リソースは、ソフトウェア要素またはハードウェア要素または両方を含むことができる。たとえば、第1のノード602は、第1のハードウェア要素または中央処理装置110に概ね対応する単一のリソースを含む。本開示で説明するソフトウェアアーキテクチャでは、ノード601の各リソースは、1つまたは複数の英数字文字を含む一意の名前を与えられ得る。図10Aに示す例示的な実施形態では、第1のノード602のリソースは、「core/cpu」というリソース名を割り当てられている。この例示的なリソース名は、当業者に知られている従来型のファイル命名構造に概ね対応する。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本発明の範囲内に十分に入る。

図10Aの例示的な実施形態では、第2のノード622は複数のリソースを含む。詳細には、この特定の例示的な実施形態では、第2のノード622は、バスアービタまたはスケジューラ422に対応する単一のハードウェア要素を含む第1のリソースを有する。第2のノード622の第2のリソースは、バスプログラムA 444Aの第1のソフトウェア要素に概ね対応するソフトウェア要素を含む。第2のノード622の第3のリソースは、バスプログラムB 444Bの第2のソフトウェア要素に概ね対応する別のソフトウェア要素を含む。当業者は、所与のノード601に関するリソースおよびリソースタイプの任意の組合せおよび任意の数が本発明の範囲内に十分に入ることを認識する。

ノード601を作成することに加えて、フレームワーク管理プログラム440はマーカー650を作成またはインスタンス化することもできる。マーカーは、ハードウェア要素またはソフトウェア要素(またはこれらの要素の両方および複数のこれらの要素)などの1つまたは複数のレガシー要素を含むことができ、それらの要素は、それら自体を容易にはマップしないか、またはフレームワーク管理プログラム440によって管理されるソフトウェアアーキテクチャに容易には適合しない。マーカー650は、ノード601のリソースをサポートすることができ、これは、ノード601のリソースがマーカー650に従属し得ることを意味する。マーカー650の一例として、ストリングドライバがあり得る。ストリングドライバは、図10Aに関連して説明したアーキテクチャに容易には嵌合しないことがある。マーカー650は、ノード601および図11のブロック1125で収集されたその従属性配列データによって参照され得る。

図10Aはまた、2つのソフトウェア要素448、450のアクションまたは機能に概ね対応する第1のクライアント648を示している。図10Aに示す例示的な実施形態では、第1のクライアント648は、ポータブルコンピューティングデバイス100によってサポートされる特定のアプリケーションプログラムモジュール105内で生じ得るキープレスアクションに概ね対応する。ただし、キープレス以外のソフトウェア要素の他のアクションおよび/または機能が本発明の範囲内に十分に入ることを、当業者は認識する。クライアント要求648およびそれらのそれぞれの作成については、図13に関連して以下でさらに詳しく説明する。

図10Aはまた、特定のアーキテクチャの要素間の関係を示している。たとえば、図10Aは、クライアント648と第1のノード602との間の関係を示している。詳細には、第1のクライアント648は、破線で示されているクライアント要求675Aを生成することができ、この要求は、リソース「/core/cpu」を含む第1のノード602によって管理または処理される。一般に、所定のまたは決められた数のタイプのクライアント要求675がある。クライアント要求675については、図13に関連して以下でさらに詳しく説明する。

図10Aに表示されている他の関係は、破線で示されている従属性680を含む。従属性は、別のノード601のそれぞれのリソースの間の関係である。従属関係は通常、第1のリソース(A)に情報を提供し得る第2のリソース(B)に第1のリソース(A)が依存していることを示す。この情報は、第2のリソース(B)によって実行された動作の結果である場合、またはそれは、第1のリソース(A)が必要とするステータス情報を含むにすぎない場合、またはそれらの任意の組合せである場合がある。第1のリソース(A)および第2のリソース(B)は、同じノード601の一部である場合、または異なるノード601の一部である場合がある。

図10Aでは、第1のノード602で始まり、第2のノード622まで延びている従属性矢印680Bによって示されるように、第1のノード602は第2のノード622に従属している。図10Aはまた、従属性矢印680Aによって示されるように、第1のノード602が第3のノード642にも従属していることを示している。図10Aはまた、従属性矢印680Cによって示されるように、第2のノード622が第4のノード646に従属していることを示している。当業者は、図10Aの破線矢印で示されている従属性680が本質的に例にすぎないこと、およびそれぞれのノード601間の従属性の他の組合せが本発明の範囲内にあることを認識する。

アーキテクチャまたはフレームワーク管理プログラム440は、限定はしないが、図10Aに示すクライアント要求675、および従属性680を含む上述の関係を維持することを担当する。フレームワーク管理プログラム440は、所与のノード601の従属性680が完全である限り、できるだけ多くのノード601をインスタンス化または作成することを試みる。従属性をサポートするリソースが、存在するか、従属性680に関係する情報を処理する準備ができた状態にあるときに、従属性680は完全である。

たとえば、第1のノード602と第3のノード642との間に存在する従属関係680Aを理由に、単一のリソース「/clk/cpu」を含む第3のノード642が作成されていない場合には、単一のリソース「/core/cpu」を含む第1のノード602がフレームワーク管理プログラム440によって作成または確立され得ない。第3のノード642がフレームワーク管理プログラム440によって作成されると、従属関係680Aを理由に、フレームワーク管理プログラム440は第1のノード602を作成することができる。

従属性680のうちの1つまたは複数が不完全であることから、フレームワーク管理プログラム440が特定のノード601を作成またはインスタンス化することができない場合、フレームワーク管理プログラム440は、フレームワーク管理プログラム440によってうまく作成されたノード601に対応するステップを引き続き実行する。フレームワーク管理プログラム440は通常、従属リソースが作成されていない不完全な従属性のために存在し得ない特定のノード601に対するコールを飛ばし、不完全なステータスを反映する当該コールに対するメッセージを返信する。

図1に示すようなマルチコア環境では、フレームワーク管理プログラム440は、図1の第0のコア222、第1のコア224、および第Nのコア226のような別個のコアでノード601を作成またはインスタンス化することができる。ノード601は一般に、ノード601が互いに従属していない限り、かつ後述するように特定のノードの対応する従属性のすべてが完全である場合に、マルチコア環境において別個のコアで並行して作成され得る。

図10Bは、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの第2の態様の一般的な図500B1である。この一般的な図では、各ノード601の1つまたは複数のリソースは、一意の名前を与えられていない。図10Bのノードまたはリソースグラフ500B1は、アーキテクチャまたはフレームワーク管理プログラム440によってサポートされるノード601、マーカー650、クライアント648、イベント690、および照会機能695のみ含む。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。

図10A〜図10Bに示されているノードアーキテクチャ内のコールは、ノード601内のリソースのエイリアス、または実際のリソース名に対し行われ得る。例示的な一実施形態によれば、クライアント648とマーカー650との間のインターフェースがないので、マーカー650に対してクライアント要求675を行う方法がなく、そのためこれは一般に、マーカー650との間で交換される情報の発生元が通常はノード601またはリソースであり、クライアント648ではないことを意味する。

たとえば、図10Bの第1のノード601Aは、第1のノード601Aが第2のノード601Bの2つのリソース(リソース#2および#3)に従属していることを示す従属性矢印680Aを有する。同様に、第1のノード601Aは、第1のノード601Aが、ハードウェアまたはソフトウェアまたはそれらの組合せのレガシー要素を一般に含む第1のマーカー650にも従属していることを示す従属性矢印680Bを有する。

図10Bはまた、第1のノード601Aのクライアント648がどのようにしてクライアント要求675を第1のノード601Aに出し得るかを示している。これらのクライアント要求675が出された後、第2のノード601Bは、イベント690をトリガするか、応答を照会695に提供することができ、この場合、イベント690および照会695に対応するメッセージがクライアント648に還流する。

図10Cは、図1のPCD100のリソースを管理するシステム向けのソフトウェアアーキテクチャの第2の態様の具体的な図500B2である。図10Cは、具体的でありながらも例示的なリソース名を有するノード601、ならびにクライアント648、イベント690、および照会機能695(図10Aのそれらに対応するもの)のみ含むノードまたはリソースグラフ500B2を示している。各ノード601は、卵形およびノード601内のリソース間のそれぞれの従属性を表す特定の方向を有する矢印680により示されている。

たとえば、第1のノード602は、第1のノード602が第2のノード622の3つのリソースに従属していることを示す従属性矢印680Bを有する。同様に、第2のソフトウェア要素444Bを含み、図10Cにおいて全体的に参照文字「C」で表される第3のリソース「/bus/ahb/sysB/」は、第3のリソース(C)が第4のノード646の単一の「/clk/sys/ahb」リソースに従属していることを示す従属性矢印680Cを有する。

図10Cはまた、1つまたは複数のイベント690または照会機能695を含み得るノード601からの出力データを示している。照会機能695は、イベント690と類似している。照会機能695は、固有であるか固有でない照会ハンドルを有し得る。照会機能は一般的に、外部では識別されず、一般的に照会機能は状態を有さない。照会機能695を使用して、ノード601の特定のリソースの状態を判断することができる。照会機能695およびイベント690は、既存クライアント648との関係を有することがあり、これらの関係は、それぞれのイベント690および照会機能695からの情報が特定のクライアント648に渡されることを示す方向矢印697によって表されている。図10Cはまた、図10Cの第2のノード622がどのように従属性矢印680Dを介して第1のマーカー650に従属しているかを示している。

図10B〜図10Cのノードまたはリソースグラフ500Bは、メモリ内に存在する関係を表し、この関係はフレームワーク管理プログラム440およびノード601を含み得る関連データ構造によって管理される。ノードまたはリソースグラフ500Bは、フレームワーク管理プログラム440によって管理されるそれぞれの要素間の関係を識別するための、かつソフトウェアチームによるトラブルシューティングのための有用なツールとして、フレームワーク管理プログラム440によって自動生成され得る。

図10Dは、PCD100のリソースを管理するための図4に示すものなどのソフトウェアアーキテクチャを作成するための方法1000Aを示すフローチャートである。ブロック1005は、PCD100のリソースを管理するための方法またはプロセス1000の第1のルーチンである。ルーチンブロック1005において、ノード構造データを受信するためにフレームワーク管理プログラム440によってルーチンが実行され得る。ノード構造データは、特定のノード601が他のノード601との間で有し得る従属性を略述する従属性配列を含むことができる。ノード構造データおよびこのルーチンまたはサブ方法705に関するさらなる詳細は、図11に関連して以下でより詳細に説明する。

次に、ブロック1010において、フレームワーク管理プログラム440は、ブロック1005において受信されたノード構造データの一部である従属性データをレビューすることができる。決定ブロック1015において、フレームワーク管理プログラム440は、ノード構造データがリーフノード601を定義しているか否かを判断することができる。リーフノード601は一般に、ノード構造データに基づいて作成されるノードが従属性をまったく有さないことを意味する。決定ブロック1015への照会が肯定である場合、最新ノードを作成するためのノード構造データが従属性をまったく有さないことを意味し、フレームワーク管理プログラム440はルーチンブロック1025に続く。

決定ブロック1015への照会が否定である場合、「いいえ」の分岐が決定ブロック1020に至り、フレームワーク管理プログラムがノード構造データ内のハードな従属性のすべてが存在するか否かを判断する。ハードな従属性は、リソースがそれなしでは存在できないものを含むことができる。一方、ソフトな従属性は、リソースが随意のステップとして従属リソースを使用できるものを含むことができる。ソフトな従属性は、ソフトな従属性を有するノード601またはノード601のリソースが、ソフトな従属性が存在しないときでもノードアーキテクチャ内に作成またはインスタンス化され得ることを意味する。マーカー650は、上述のようにソフトな従属性と呼ばれ得る。

ソフトな従属性の一例として、複数のリソースを含むリソース指向(resource oriented)601の動作に不可欠ではない最適化特徴が挙げられる。フレームワーク管理プログラム440は、存在するすべてのハードな従属性に関して、作成されないソフトな従属性を有するノードまたはリソースに関してソフトな従属性が存在しないときでも、ノードまたはリソースを作成またはインスタンス化することができる。コールバック特徴を使用してソフトな従属性を参照することができ、それにより、ソフトな従属性をフレームワーク管理プログラム440が利用できるようになったとき、フレームワーク管理プログラム440は、ソフトな従属性が現在利用可能であるという、ソフトな従属性を参照する各コールバックを知らせる。

決定ブロック1020への照会が否定である場合、「いいえ」の分枝がブロック1027に至り、ノード構造データがフレームワーク管理プログラム440によってメモリなどの一時記憶装置に記憶され、フレームワーク管理プログラム440はこのインスタンス化されないノードに関連するコールバック特徴を作成する。

決定ブロック1015への照会が肯定である場合、「はい」の分枝はルーチン1025に至り、ルーチンブロック1005において受信されたノード構造データに基づいてノード601が作成またはインスタンス化される。ルーチンブロック1025のさらなる詳細については、図13に関連して以下で説明する。次に、ブロック1030において、フレームワーク管理プログラム440は、新規作成されたノード601を、その一意のリソース名を使用して公開し、それにより他のノード601が、新規作成されたノード601に情報を送ること、または新規作成されたノード601から情報を受信することができるようになる。

次に図10Dの続きのフローチャートである図10Eを参照すると、ブロック1035において、フレームワーク管理プログラム440は、新規作成されたノード601に従属する他のノード601に対し、新規作成されたノード601がインスタンス化されており、情報を送受信する準備ができていることを通知する。例示的な一態様によれば、図10Bのノード601Bのような従属ノードが作成されたときにただちに通知が開始される、すなわち、通知が再帰的に実行される。したがって、図10Bのノード601Bが構築された場合、ノード601Aはただちに通知される。この通知により、(ノード601Bはノード601Aが最後に従属するものであったので)ノード601Aを構築することができる。ノード601Bの構築により他のノード601が通知される、といった状況が生じ得る。ノード601Bに従属する最後のリソースが完成するまで、ノード601Bは完成しない。

第2の、前記実装形態よりも若干複雑な実装形態では、通知のすべてを個別の通知キューに配置し、次いで一時点でキューを通読する(run through)、すなわち、通知は反復的に実行される。したがって、図10Bのノード601Bが構築されたとき、ノード601Aに対する通知がリストに渡される。次いで、そのリストが実行され、ノード601Aが通知を受ける。これにより、(図10Bに示されていない、ノード601A以外の)他の追加ノード601に対する通知が同じリストに掲載され、次いでその通知は、ノード601Aに対する通知が送られた後に送られる。(ノード601Aに対する通知以外の)他のノード601に対する通知は、ノード601Bおよびノード601Aに関連する作業がすべて完了するまで生じない。

論理的には、これら2つの実装形態はまったく同等であるが、実施されたときのメモリ消費特性が異なる。再帰的実現は単純であるが、恣意的なスタックスペース量を消費する可能性があり、スタック消費は従属性グラフの深さの関数である。反復的実装形態はこれよりも若干複雑になっており、これよりも若干多くのスタックメモリ(通知リスト)を必要とするが、図10Bに示すように従属性グラフの深さにかかわりなくスタック使用は一定である。

また、ブロック1035におけるノード作成の通知は他のノードに限定されない。これはエイリアス構築に内部使用できる。他のノードにとどまらず、システム500における任意の恣意的な要素が同じ機構を使用して、ノード(またはマーカー)が利用可能になったときの通知を要求することができる。ノードと非ノードの両方が同じ通知機構を使用することができる。

決定ブロック1040において、フレームワーク管理プログラム440は、最新ノード601の作成に基づいて作成またはインスタンス化するために他のノード601またはソフトな従属性が現在解放されているか否かを判断する。作成またはインスタンス化を最近経験している最新ノードによっていくつかの従属関係680が満たされていることを理由にリソースが現在作成可能であるか否かを、決定ブロック1040は一般に判断している。

決定ブロック1040への照会が肯定である場合、「はい」の分枝はルーチンブロック1025に戻り、作成されたばかりのノード601による従属性の充足を理由に、解放されているノード601を現在作成またはインスタンス化することができる。

決定ブロック1040への照会が否定である場合、「いいえ」の分枝はブロック1045に至り、フレームワーク管理プログラム440は、図4に示すようにソフトウェアアーキテクチャの要素間の通信を管理することができる。次に、ブロック1050において、フレームワーク管理プログラム440は、特定のリソースに関連するリソース名を使用することによって、リソースによって行われるアクションを引き続きログ記録または記録することができる。フレームワーク管理プログラム440、またはリソース、ノード601、クライアント648、イベント690、および照会機能695のような、フレームワーク管理プログラム440によって管理される要素のうちのいずれかによって行われる任意のアクションの後、フレームワーク管理プログラム440によってブロック1045が実行され得る。ブロック1045は、ノードアーキテクチャのさらに1つの重要な態様であり、ここではフレームワーク管理プログラム440は、ノード601のリソースのような特定の要素を作成したオーサーによって提供される一意の識別子または名前に従って各要素によって実行されるアクションを列挙する活動の実行ログを維持することができる。

従来技術と比較して、システムの各リソースに割り当てられた一意の名前を列挙するブロック1050における活動のログ記録は固有のものであり、デバッギングおよび誤りトラブルシューティングで使用されるような、大きい利点をもたらすことができる。ノードアーキテクチャ500を固有のものにする多くのものの別の態様は、別個のチームが互いに独立して異なるハードウェア要素および/またはソフトウェア要素に取り組めることであり、この場合、各チームは、他のチームおよび/または相手先商標製造会社(OEM)によって割り当てられたさほど有意義ではなく一般にまぎらわしいリソース名を翻訳するためのテーブルを作成する必要なく、一意で追跡しやすいリソース名を使用することができる。

次に、決定ブロック1055において、フレームワーク管理プログラム440は、フレームワーク管理プログラム440によって記録された活動のログが要求されているか否かを判断する。決定ブロック1055への照会が否定である場合、「いいえ」の分枝はプロセスの最後に至り、プロセスはルーチン1005に戻る。決定ブロック1055への照会が肯定である場合、「はい」の分枝はブロック1060に至り、フレームワーク管理プログラム440は、有意義なリソース名およびリソース名によって実行されるそれぞれの活動を含む活動ログを、プリンタまたはディスプレイスクリーンおよび/または両方などの出力デバイスに送る。次いで、プロセスは上述のルーチンブロック1005に戻る。

図11は、PCD100のソフトウェアアーキテクチャにおけるノード構造データを受信するための図10Dのサブ方法またはルーチン1005を示すフローチャートである。ブロック1105は、図10Dのサブ方法またはルーチン1005における第1のステップである。ブロック1105において、フレームワーク管理プログラム440は、図10DのCPU110およびクロック442のようなソフトウェア要素またはハードウェア要素の一意の名前を受信することができる。前に説明したように、ノード601は少なくとも1つのリソースを参照しなければならない。各リソースは名前を有し、その名前はシステム500において一意でなければならない。システム500内のすべての要素が一意の名前により識別され得る。各要素は、文字の観点から一意の名前を有する。言い換えれば、一般に、同じ名前を有する2つの要素はシステム500内に存在しない。システムの例示的な態様によれば、ノード601のリソースは一般にシステム全体で一意の名前を有することができるが、クライアントまたはイベントの名前は、要望に応じて一意であってもよいが、一意である必要はない。

便宜上、限定はしないが、CPU110の「/core/cpu」およびクロック442の「/clk/cpu」のような、一意の名前を作成するための前スラッシュ「/」文字を用いる従来型のツリーファイル命名構造またはファイル命名「メタファー」を用いることができる。ただし、当業者が認識するように、英数字文字および/または記号の任意の他の組合せを含む他のタイプのリソース名も、本発明の範囲内に十分に入る。

次に、ブロック1110において、フレームワーク管理プログラム440は、作成されるノード601の1つまたは複数のリソースに関連する1つまたは複数のドライバ機能に関するデータを受信することができる。ドライバ機能は一般に、特定のノード601に関する1つまたは複数のリソースによって完了するアクションを含む。たとえば、図10A〜図10Bにおいて、ノード602のリソース/core/cpuに関するドライバ機能は、要求されている所要量の処理を提供するために必要とする量のバス帯域幅およびCPUクロック周波数を要求することができる。これらの要求は、ノード642およびノード622におけるリソースのクライアント(不図示)を介して行われる。ノード642における/clk/cpuに関するドライバ機能は通常、ノード602の/core/cpuリソースから受信した要求に従って物理クロック周波数を実際に設定することを担当する。

ブロック1115において、フレームワーク管理プログラム440はノード属性データを受信することができる。ノード属性データは一般に、安全性(ユーザ空間アプリケーションを介してノードにアクセスできるか)、遠隔性(システムにおいて他のプロセッサからノードにアクセスできるか)およびアクセス可能性(リソースは複数の並列クライアントをサポートできるか)などのノードポリシーを定義するデータを含む。フレームワーク管理プログラム440はまた、要求評価またはログ記録ポリシーなど、リソースがデフォルトフレームワーク行動を無効にすることを許容する属性を定義することができる。

その後、ブロック1120において、フレームワーク管理プログラム440は、作成される特定のノード601に関するカスタマイズされたユーザデータを受信することができる。ユーザデータは、「C」プログラミング言語に関して当業者によって理解されている空の「スター(star)」フィールドを含むことができる。ユーザデータはまた、「トラストミー(trust me)」フィールドとして当業者に知られている。例示的なカスタマイズされたユーザデータは、限定はしないが、テーブル、たとえば周波数テーブル、レジスタマップなどを含むことができる。ブロック1120において受信されたユーザデータは、システム500によって参照されないが、リソースのカスタマイズを、カスタマイズがフレームワーク管理プログラム440によって認識されていないか、十分にサポートされていない場合に許容する。このユーザデータ構造は、特別な使用または特定の使用のために拡張されることが意図された「C」プログラミング言語における基本クラスである。

当業者は、特定のクラスの特定の使用を拡張するための他の種類のデータ構造が、本発明の範囲内にあることを認識する。たとえば、プログラミング言語「C++」(C-プラス-プラス)において、同等の構造が、ノード601内のリソースの拡張機構になるキーワード「パブリック(public)」を含むことができる。

次に、ブロック1125において、フレームワーク管理プログラム440は従属性配列データを受信することができる。従属性配列データは、作成されるノード601が従属する1つまたは複数のリソース601の一意かつ特定の名前を含むことができる。たとえば、図10Cの第1のノード602が作成されている場合、このブロック1125において、従属性配列データは、第1のノード602が従属する第2のノード622の3つのリソースのリソース名および第3のノード642の単一のリソース名を含むことができる。

続いて、ブロック1130において、フレームワーク管理プログラム440はリソース配列データを受信することができる。リソース配列データは、作成される最新ノードに関するパラメータ、たとえば、図10B〜図10Cの第1のノード602が作成されている場合にこの第1のノード602に関連するパラメータを含むことができる。リソース配列データは、以下のデータのうちの1つまたは複数を含むことができる。他のリソースの名前、ユニット、最大値、リソース属性、プラグインデータ、およびブロック1120のカスタマイズユーザデータに類似した任意のカスタマイズされたリソースデータ。プラグインデータは、一般に、ソフトウェアライブラリから取り出された機能を識別し、通常、作成される特定のノードまたは複数のノードによってサポートされ得るクライアントタイプを列挙する。プラグインデータはまた、クライアントの作成および破壊のカスタマイズを可能にする。ブロック1130の後、プロセスは図10Dのブロック1010に戻る。

図11において、属性データブロック1115、カスタマイズユーザデータブロック1120、および従属性配列データブロック1125は、これらの特定のステップが随意であり、所与のノード601に必要なものではないことを示すために破線で示されている。一方、一意の名前ブロック1105、ドライバ機能ブロック1110、およびリソース配列データブロック1130は、ルーチン1005のこれらのステップがノード601を作成するために一般に必須であることを示すために実線で示されている。

図12は、PCD100向けのソフトウェアアーキテクチャにおけるノードを作成するための図10Dのサブ方法またはルーチン1025を示すフローチャートである。ルーチンブロック1205は、例示的な一実施形態によるノード601をインスタンス化または作成するためのサブ方法またはルーチン1025における第1のルーチンである。ルーチンブロック1205において、インスタンス化されているノード601に関連する1つまたは複数のクライアント648が、このステップで作成される。ルーチンブロック1205に関するさらなる詳細については、図13に関連して以下でさらに詳しく説明する。

ブロック1210において、フレームワーク管理プログラムは、ブロック705のノード構造データに対応する1つまたは複数のリソースを作成またはインスタンス化することができる。次に、ブロック1215において、フレームワーク管理プログラム440は、ルーチンブロック1005のルーチンブロック1110において受信されたドライバ機能をアクティブ化することができる。例示的な一態様によれば、ドライバ機能は、ルーチンブロック1005のリソース配列データブロック1130において受信された最大値を使用してアクティブ化され得る。別の好ましい例示的な態様によれば、各ドライバ機能は、ルーチン1005からノード構造データとともに渡された随意の初期値によりアクティブ化され得る。初期データが提供されない場合、ドライバ機能は最小値0に初期設定される。ドライバ機能はまた、通常は、初期設定されていることがわかるようにアクティブ化される。これによりリソースは、初期設定に固有であるが、通常動作またはルーチン動作中に実行される必要のない動作を実行することができる。そして、プロセスは図10Dのステップ1030に戻る。

図13は、PCD100のソフトウェアアーキテクチャにおけるクライアント648を作成するための図12のサブ方法またはルーチン1205を示すフローチャートである。ブロック1305は、1つまたは複数のリソース601のクライアント648が作成されるルーチンブロック1205の第1のステップである。ブロック1305において、フレームワーク管理プログラム440は、作成されるクライアント648に割り当てられた名前を受信する。リソース名と同様に、クライアント648の名前は、任意のタイプの英数字および/または記号を含むことができる。

次に、ブロック1310において、作成されるこのクライアント648に関する特定のカスタマイズがある場合に、カスタマイズされたユーザデータがフレームワーク管理プログラム440によって受信され得る。ブロック1310は、このステップが随意であることを示すために破線で示されている。ブロック1310のカスタマイズされたユーザデータは、ノード601のリソースの作成に関連して上述したカスタマイズされたユーザデータに類似している。

ブロック1315において、フレームワーク管理プログラム440は、作成される特定のクライアントに割り当てられたクライアントタイプカテゴリーを受信する。本明細書執筆時点でクライアントタイプカテゴリーは、4つのタイプのうちの1つを含むことができる。(a)必須、(b)インパルス、(c)ベクトル、および(d)等時性。クライアントタイプカテゴリーのリストは、システム101によって管理されているリソースに応じて、またノード601のリソースに依存するアプリケーションプログラムに応じて、拡大し得る。

必須カテゴリーは、必須クライアント648から特定のリソース601に渡されるスカラー値の処理に概ね対応する。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。一方、インパルスカテゴリーは、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求の処理に概ね対応する。

等時性カテゴリーは、通常は再発しており、明確な開始時間および明確な終了時間を有するアクションに対する要求に概ね対応する。ベクトルカテゴリーは、直列または並列に要求される複数のアクションの一部であるのが普通であるデータの配列に概ね対応する。

続いて、ブロック1320において、フレームワーク管理プログラム440は、クライアント648が同期に指定されているか、それとも非同期に指定されているかを示すデータを受信する。同期クライアント648は、リソース601が同期クライアント648から要求されたタスクを完了したことを示すデータおよび指示をリソース601が返信するまで、ノード601のリソースをロックすることをフレームワーク管理プログラム440に対し通常要求するクライアントである。

一方、非同期クライアント648は、フレームワーク管理プログラム440によってアクセスされる1つまたは複数のスレッド436(図4参照)によって並列に処理され得る。フレームワーク管理プログラム440は、スレッド436に対するコールバックを作成することができ、コールバックがそれぞれのスレッド436によって実行されているときに値を戻すことができる。当業者は、同期クライアント648のタスクが実行されているときに同期クライアント648がリソースをロックするように、非同期クライアント648がリソースをロックすることはないことを認識する。

ブロック1320の後、決定ブロック1325において、フレームワーク管理プログラム440は、クライアント648によって識別されるリソースが利用可能であるか否かを判断する。決定ブロック1325への照会が否定である場合、「いいえ」の分岐がブロック1330に至り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージがユーザに返信される。

決定ブロック1325への照会が肯定である場合、「はい」の分岐が決定ブロック1335に至り、フレームワーク管理プログラム440は、クライアント648によって識別される各リソースがブロック1315において提示されたクライアントタイプをサポートするか否かを判断する。決定ブロック1335への照会が否定である場合、「いいえ」の分岐がブロック1330に戻り、クライアント648をこの時点で作成できないことを示すヌル値またはメッセージが返信される。

決定ブロック1335への照会が肯定である場合、「はい」の分岐がブロック1340に至り、フレームワーク管理プログラム440はメモリ内にクライアント648を作成またはインスタンス化する。次に、ブロック1345において、随意の引数のような任意のカスタマイズされたユーザデータがブロック1310において受信された場合、これらの随意の引数が特定のノード601のそれぞれのリソースにマップされ得る。次に、ブロック1350において、新規作成されたクライアント648が、アイドル状態において、または上記の図10Cで示したように要求された状態において、その対応する1つまたは複数のリソースに結合される。そして、プロセスは図12のブロック1210に戻る。

図14は、PCD100向けのソフトウェアアーキテクチャにおけるリソース601に対するクライアント要求675を作成するための方法1400を示すフローチャートである。方法1400は一般に、図10D〜図10Eおよび図13に関連して上述したようにクライアント作成およびノード作成の後、実行される。

ブロック1405は、リソース601に対するクライアント要求675を作成するための方法1400における第1のステップである。方法1400は、以下の3つのタイプの要求675がフレームワーク管理プログラム440によってどのように処理されるかを表している。(a)必須、(b)インパルス、および(c)ベクトル。第4のタイプの要求675、すなわち(d)等時性要求の処理については、図15に関連して後述する。前記の要求675の名前が示唆するように、クライアント要求675は、作成され、図14に関連して上述したクライアントタイプに概ね対応する。

ブロック1405において、フレームワーク管理プログラム440は、上述した3つ、すなわち(a)必須、(b)インパルス、および(c)ベクトルのうちの1つのような特定のクライアント要求675に関連するデータを受信することができる。必須要求に関連するデータは一般に、必須クライアント648から特定のリソース601に渡されるスカラー値を含む。たとえば、必須要求は、数百万命令毎秒(MIPS)を含むことができる。一方、インパルス要求は、開始時間または停止時間の指定のない一定期間内に何らかの活動を完了させるよう求める要求を含む。ベクトル要求に関するデータは一般に、直列または並列に完了することが求められる複数のアクションの配列を含む。ベクトル要求は、値の任意の長さを含むことができる。ベクトル要求は通常、サイズ値および値の配列を有する。ノード601の各リソースは、ベクトル要求をサポートするためにポインタフィールドを有するように拡張され得る。「C」プログラミング言語では、ポインタフィールドは、当業者によって理解されているように、統合機能(union function)によってサポートされている。

次に、ブロック1410において、フレームワーク管理プログラム440は、図13に関連して上述した方法によって作成されたクライアント648を通じて要求を出す。続いて、ブロック1415において、フレームワーク管理プログラム440は、要求が必須タイプまたはベクトルタイプである場合に、クライアントを通じて渡されている要求データを二重バッファする。要求がインパルスタイプである場合、ブロック1415はフレームワーク管理プログラム440によって飛ばされる。

必須要求の場合、このブロック1415において、先行する要求からの値がメモリ内に維持され、それによりフレームワーク管理プログラム440は、以前の要求された値と要求された値の現在のセットとの間に差異があるか否かを判断することができる。ベクトル要求の場合、先行する要求は通常、メモリ内に維持されないが、ノード601のリソースは、特定の実装形態で望まれるように、それを維持することができる。したがって、ブロック1415はベクトルタイプの要求の場合には随意である。

ブロック1420において、フレームワーク管理プログラム440は、要求された値の以前のセットと要求された値の現在のセットとの間のデルタまたは差異を計算する。決定ブロック1425において、フレームワーク管理プログラムが、要求された値の現在のセットが要求された値の以前のセットと同じであるか否かを判断する。言い換えれば、フレームワーク管理プログラム440は、要求された値の現在のセットと要求された値の以前のセットとの間に差異があるか否かを判断する。要求された値の現在のセットと以前のセットとの間に差異がない場合、「はい」の分枝が(ブロック1430〜ブロック1470を飛ばして)ブロック1475に至り、プロセスは終了する。

決定ブロック1425への照会が否定である場合、要求された値のセットが以前の要求された値のセットと異なることを意味し、「いいえ」の分枝が決定ブロック1430に至る。

決定ブロック1430において、フレームワーク管理プログラム440は、現在の要求が非同期要求であるか否かを判断する。決定ブロック1430への照会が否定である場合、「いいえ」の分枝がブロック1440に至り、クライアント要求675に対応するリソース601がフレームワーク管理プログラム440によってロックされる。決定ブロック1430への照会が肯定である場合、現在の要求が非同期要求タイプであることを意味し、「はい」の分枝がブロック1435に至り、図1のマルチコアシステムのようなマルチコアシステムがフレームワーク管理プログラム440によって現在管理されている場合に、要求を別のスレッドに渡すことができ、別のコアによって実行することができる。ブロック1435は、PCD100が単一コア中央処理システムである場合にこのステップが随意であり得ることを示すために破線で示されている。

続いて、ブロック1440において、要求675に対応するリソース601がフレームワーク管理プログラム440によってロックされる。次に、ブロック1445において、リソース601は、図11のブロック1130において受信されたリソース配列データのプラグインデータに概ね対応する更新機能を実行する。更新機能は一般に、新しいクライアント要求に照らして新しいリソース状態を確保する機能を含む。更新機能は、クライアント要求における要求された状態と以前の状態とを比較する。要求された状態が以前の状態よりも大きい場合、更新機能はクライアント要求を実行する。一方、要求された状態が現在の状態以下であり、現在の状態でリソースが動作している場合、古い状態は要求された状態を達成しているか満たしているので、効率性を高めるためにクライアント要求を実行することはない。更新機能は、クライアントからの新しい要求を受け取り、それを他のアクティブな要求すべてと統合して、リソースの新しい状態を判断する。

一例として、複数のクライアントがバスクロック周波数を要求していることがある。バスクロックの更新機能は通常、最大限のすべてのクライアント要求を受け取り、バスクロックの新しい所望の状態としてそれを使用する。すべてのリソースが同じ更新機能を使用する場合は該当しないが、複数のリソースによって使用される更新機能がいくつかある。いくつかの共通する更新機能は、最大限のクライアント要求を受け取ること、最小限のクライアント要求を受け取ること、およびクライアント要求を合算することである。あるいは、リソースは、何らかの固有の方法で要求を統合する必要がある場合に、それら自体のカスタム更新機能を定義することができる。

次に、ブロック1450において、フレームワーク管理プログラム440は、クライアント要求648に対応するリソースにデータを渡して、リソースがノード601のリソースに固有のドライバ機能を実行できるようにする。ドライバ機能は、更新機能によって計算される通りにリソース状態を適用する。これは、ハードウェア設定を更新すること、従属リソースに要求を出すこと、レガシー機能を呼び出すこと、または前記の何らかの組合せを伴うことがある。

前述の例では、更新機能は、要求されたバスクロック周波数を計算した。ドライバ機能は、その要求された周波数を受信することができ、クロック周波数制御ハードウェアを更新して、その周波数で作動させることができる。更新機能が計算した正確な要求された状態をドライバ機能が満たすことは不可能な場合もあることに留意されたい。この場合、ドライバ機能は、要求を最も満たす周波数を選択することができる。たとえば、バスクロックハードウェアは128MHzおよび160MHzでのみ作動できるが、要求された状態は150MHzである場合がある。この場合、ドライバ機能は、要求された状態を上回る160MHzで作動すべきである。

次に、ブロック1455において、フレームワーク管理プログラム440は、ブロック1450においてドライバ機能を実行したリソースから状態制御を受信する。続いて、ブロック1460において、リソースに対して定義されている場合、イベント690をトリガすることができ、それによりデータは、イベント690に対応するクライアント648に戻される。イベントは別のスレッドで処理され得る。これにより、ロックされたリソースで費やされる時間量を最小限に抑えることができ、図1に示したようなマルチコアシステムにおけるさらなる並列的な動作が可能になる。本方法1400で説明するようにリソースに対して要求を定義できる方法と同様に、リソースに対して1つまたは複数のイベント690を定義することができる。言い換えれば、イベント作成プロセスは、クライアント作成プロセスに概ね匹敵する。イベントと異なる1点は、いくつかのしきい値を超えたときのみトリガされるイベントを定義することが可能である点である。

しきい値に基づいてのみトリガされるイベントのこの定義により、システムの過負荷状態を示す、リソースがオーバーサブスクライブされている(サポートできる数を超える同時ユーザを有する)時期、または他の物が断たれること、システムがオーバーサブスクライブされたときに無効になった機能を回復させることなどが可能になる、リソースが低水準/オフになる時期を通知することができる。イベント登録はしきい値により行うことができるので、システムがイベント通知に関して行わなければならない作業の量が減り、本当に必要なものがあるときのみイベント通知が生じるようになる。あらゆる状態変化に関するイベントを登録することも可能である。

次に、随意のブロック1465において、処理されている要求がベクトル要求である場合、この随意のブロック1465はたいてい実行される。随意のブロック1465は一般に、ベクトルポインタが依然として、ユーザがベクトルに渡した同じデータに位置付けられているか否かを査定するチェックまたは判断を含む。この随意のブロック1465への照会が肯定である場合、ポインタは依然として、ユーザによってベクトルに渡された同じデータを指していることを意味し、古いデータの参照が維持されないようにポインタが除去される。この随意のブロック1465は一般に、インパルス要求および必須要求と比較して、ベクトル要求が処理されているときに上述の二重バッファリングブロック1415を考慮して(account for)実行される。

続いて、ブロック1470において、フレームワーク管理プログラム440は、要求されたリソースのロックを解除し、それにより他のクライアント要求648は、特定のノード601の現在のものであるが今解放された要求されたリソースによって処理され得る。次いでプロセスは、次のクライアント要求を受信するために第1のブロック1405に戻る。

上記の開示を考慮して、プログラミングの当業者は、たとえば本明細書のフローチャートおよび関連する説明に基づいて、コンピュータコードを書くか、または適切なハードウェアおよび/もしくは回路を特定し、開示された発明を容易に実施することができる。したがって、特定の1組のプログラムコード命令または詳細なハードウェアデバイスの開示が、本発明をどのように製作し使用すべきかについて適切に理解するうえで必要であるとは見なされない。特許請求されるコンピュータで実施される処理の発明性のある機能は、上の説明において、かつ、様々な処理の流れを示し得る図面とともに、より詳細に説明される。

1つまたは複数の例示的な態様では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せで実装することができる。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体上で送信され得る。コンピュータ可読媒体は、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む、コンピュータ記憶媒体と通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の使用可能な媒体とすることができる。限定ではなく、例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROM、または他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または、命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用され得るとともに、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。

また、任意の接続をコンピュータ可読媒体と呼ぶのが妥当である。たとえば、ソフトウェアが同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、またはワイヤレス技術、たとえば赤外線、無線、およびマイクロ波を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は媒体の定義内に含まれる。

本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フレキシブルディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

選択された態様について詳細に説明し、詳述してきたが、以下の請求項によって定義されるような本発明の趣旨および範囲から逸脱することなく、本明細書において様々な置換および改変を実施できることが理解されよう。

100 PCD
101 システム
102 オンチップシステム、リソース電力マネージャ、RPMノード、RPM
103 内部チップバス(「ICB」)ドライバモジュール、ドライバモジュール、UL ICBドライバ、ICBドライバ
103A 上位層(「UL」)タイプ、UL ICBドライバタイプ、ICBドライバ、上位層(「UL」)内部チップバス(「ICB」)ドライバモジュール、ICBドライバモジュール、UL ICBドライバ
103A1 第1のUL ICBモジュール、第1のUL ICBドライバ
103B 下位層(「LL」)タイプ、LL ICBドライバタイプ、ICBドライバ、下位層(「LL」)ICBドライバ、下位層ICB(「LL ICB」)ドライバモジュール、ICBドライバモジュール
105 アプリケーションプログラムモジュール、プログラムモジュール、アプリケーションモジュール、ソフトウェアアプリケーションモジュール
105A1 第1のアプリケーションプログラムモジュール
105A2 第2のアプリケーションプログラムモジュール
107 リソース電力マネージャ、スイッチファブリック、バス
107A 第1のスイッチファブリック、スイッチファブリック、第1のファブリック
107B 第2のスイッチファブリック、スイッチファブリック
107C 第3のスイッチファブリック、スイッチファブリック
107N 第3のスイッチファブリック
109 動的メモリ割振り/アクセス(「DMA」)エンジン、マスターノードM7
110 プロセッサ、マスタープロセッサ、CPU、マスターCPU、中央処理装置(CPU)、マスター
110A 中央処理装置(「CPU」)、プロセッサ、マルチコア中央処理装置(「CPU」)、第1のCPU、第1のマスター1、第1のマスターノードM1
110B グラフィックスプロセッサ、プロセッサ、中央処理装置(「CPU」)、第2のCPU、第2のマスター2、第2のマスターノードM2、第2のマスターM2
110C 中央処理装置(「CPU」)、第3のCPU、マスターノードM3、第3のプロセッサ
110D モバイルディスプレイプロセッサ(「MDP」)、第5のマスターノードM5、第5のマスター、第5のマスターM5
110N 中央処理装置(「CPU」)、第4のCPU、マスターノードM4
111 構成ポート、第1のスレーブ1、第1のスレーブノードS1
112 メモリ、ダブルデータレート同期型ダイナミックランダムアクセスメモリ(「DDR SDRAM」)、DDRメモリ、第2のスレーブ2、第2のスレーブノードS2
113 外部バスインターフェース、第3のスレーブノードS3、第3のスレーブS3
114 デジタル信号プロセッサ、マスターノードM6、DSP
115 マスターハードウェア要素、マスターノードMN
117 スレーブハードウェア要素、スレーブノードSN
126 アナログ信号プロセッサ、プロセッサ
128 ディスプレイコントローラ
130 タッチスクリーンコントローラ
132 タッチスクリーンディスプレイ
134 ビデオコーダ/デコーダ(「コーデック」)、ビデオエンコーダ
136 ビデオ増幅器
138 ビデオポート
140 ユニバーサルシリアルバス(「USB」)コントローラ
142 USBポート
146 加入者識別モジュール(SIM)カード
148 デジタルカメラ、カメラ
150 ステレオオーディオコーデック
152 オーディオ増幅器
154 第1のステレオスピーカー
156 第2のステレオスピーカー
157B 熱センサ
158 マイクロフォン増幅器
160 マイクロフォン
162 周波数変調(「FM」)無線チューナー
164 FMアンテナ
166 ステレオヘッドフォン
168 高周波(「RF」)トランシーバ
170 RFスイッチ
172 RFアンテナ
174 キーパッド
176 マイクロフォンを備えたモノヘッドセット、モノヘッドセット
178 バイブレータデバイス、バイブレータ
180 電源
222 第0のコア
224 第1のコア
226 第Nのコア
307 クロスバースイッチ
307A クロスバースイッチ
307B クロスバースイッチ
307C クロスバースイッチ
400 第1のゲートウェイノードG1、第1のゲートウェイG1
400A1 第1のゲートウェイノードG1、第1のゲートウェイG1
400B1 第1のゲートウェイノードG1A、第1のゲートウェイ、第1のゲートウェイG1A
400B2 ゲートウェイノードG1B、第1のゲートウェイG1B
401 第1のソフトウェア要求タイプ、第1の「バースト的」ソフトウェア要求タイプ、ソフトウェア要求タイプ、要求
401A 「バースト的」ソフトウェア要求、第1のソフトウェア要求、第1のバースト的ソフトウェア要求、ソフトウェア要求、要求
401B 「バースト的」ソフトウェア要求、第2のソフトウェア要求、第2のバースト的ソフトウェア要求、ソフトウェア要求、要求
402 第2のゲートウェイノードG2、第2のゲートウェイG2
402A データブロック
402A1 第2のゲートウェイノードG2、第2のゲートウェイG2
402B データブロック
402B1 第2のゲートウェイノードG2A、第2のゲートウェイG2A
402B2 ゲートウェイノードG2B、第2のゲートウェイG2B
402C1 第2のゲートウェイG2
403 ノードグラフまたはノードアーキテクチャ
404A 第1の期間P1
404B 第2の期間P2
405 アービタノード
406A 第1のウィンドウW1、ウィンドウサイズW1
406B 第2のウィンドウW2、ウィンドウサイズW2
407 スイッチファブリックノード、ファブリックノード
407A スイッチファブリックノード
407B スイッチファブリックノード
407C スイッチファブリックノード
408A 第1のブロックサイズBS1
408B 第2のブロックサイズBS2
422 バスアービタまたはスケジューラ
440 フレームワーク管理プログラム
442 クロック
444A バスプログラムA
444B バスプログラムB
448 ソフトウェア要素によって監視されるアクションまたは機能
450 レガシー要素
500A ソフトウェアアーキテクチャ
501 「CPU」タイプ、第2のソフトウェア要求タイプ、CPUソフトウェア要求タイプ
507 第1のルートチェックテーブル、ルートチェックテーブル、テーブル
601 ノード
601A 第1のノード
601B 第2のノード
602 ノード
607 第2のルートチェックテーブル、ルートチェックテーブル、テーブル
622 ノード、第2のノード
642 ノード
646 ノード
648 クライアント
650 マーカー、第1のマーカー
675 クライアント要求
680A 従属性矢印
680B 従属性矢印
680D 従属性矢印
690 イベント
695 照会機能
697 方向矢印
1002 配列データ構造、ハンドル
1002A 第1のハンドル
1002B 第2のハンドル
1002C 第3のハンドル
1002D 第4のハンドル

Claims (40)

1. ポータブルコンピューティングデバイス（PCD）のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするための方法であって、
   マスタースレーブペアを含むクライアント要求を受信するステップと、
   前記マスタースレーブペアに対応するスレーブについての検索を実行するステップと、
   前記マスタースレーブペアに対応する通信のルートを作成するステップと、
   前記ルートに対応する1つまたは複数のハンドルをメモリデバイスに記憶するステップと、
   前記ルートの帯域幅を設定するステップと、
   前記作成されたルートを使用して、前記ルートの前記帯域幅が設定された後に前記クライアント要求を処理するステップと
   を含む方法。
2. 前記スレーブについての前記検索を実行するステップは、マスタースレーブ階層における各スレーブに割り当てられた一意の識別子を比較するステップを含む、請求項1に記載の方法。
3. 前記スレーブについての前記検索を実行するステップは、スイッチファブリック内で問合せ可能なスレーブを求めてファブリックルートチェックテーブルを確認するステップを含む、請求項1に記載の方法。
4. 前記スレーブについての前記検索を実行するステップは、前記PCDの1つまたは複数の異なるスイッチファブリックで検索するステップを含む、請求項1に記載の方法。
5. 各マスターがノードによって表され、各スレーブがノードによって表される通信を追跡するためのノードアーキテクチャを利用するステップをさらに含む、請求項1に記載の方法。
6. 前記ルートの前記帯域幅を設定するステップは、前記クライアント要求のパラメータを瞬時帯域幅(Ib)および平均帯域幅(Ab)の値に変換するステップをさらに含む、請求項1に記載の方法。
7. 前記瞬時帯域幅(Ib)は以下の式:
   Ib=BS/W
   によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「W」は時間単位で表現されるウィンドウサイズである、請求項6に記載の方法。
8. 前記平均帯域幅(Ab)は以下の式:
   Ab=BS/P
   によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「P」は時間単位で表現される期間である、請求項6に記載の方法。
9. 前記平均帯域幅(Ab)は以下の式:
   Ab=T×(Z%)
   によって決定され、式中、「Ab」は平均帯域幅であり、「T」はソフトウェア要求を出している中央処理装置の所望のクロック速度であり、「Z%」は使用の割合およびキャッシュミスの割合のうちの少なくとも1つである、請求項6に記載の方法。
10. 前記平均帯域幅(Ab)は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の合計から計算され、前記瞬時帯域幅は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の最大値から計算される、請求項6に記載の方法。
11. ポータブルコンピューティングデバイス（PCD）のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするためのコンピュータシステムであって、
    プロセッサを含み、前記プロセッサは、
    マスタースレーブペアを含むクライアント要求を受信するステップと、
    前記マスタースレーブペアに対応するスレーブについての検索を実行するステップと、
    前記マスタースレーブペアに対応する通信のルートを作成するステップと、
    前記ルートに対応する1つまたは複数のハンドルをメモリデバイスに記憶するステップと、
    前記ルートの帯域幅を設定するステップと、
    前記作成されたルートを使用して、前記ルートの前記帯域幅が設定された後に前記クライアント要求を処理するステップと
    を行うように動作可能である、システム。
12. 前記スレーブについての前記検索を実行するステップは、マスタースレーブ階層における各スレーブに割り当てられた一意の識別子を比較するステップを含む、請求項11に記載のシステム。
13. 前記スレーブについての前記検索を実行するステップは、スイッチファブリック内で問合せ可能なスレーブを求めてファブリックルートチェックテーブルを確認するステップを含む、請求項11に記載のシステム。
14. 前記スレーブについての前記検索を実行するステップは、前記PCDの1つまたは複数の異なるスイッチファブリックで検索するステップを含む、請求項11に記載のシステム。
15. 前記プロセッサは、各マスターがノードによって表され、各スレーブがノードによって表される通信を追跡するためのノードアーキテクチャを利用するステップを行うようにさらに動作可能である、請求項11に記載のシステム。
16. 前記ルートの前記帯域幅を設定するステップは、前記クライアント要求のパラメータを瞬時帯域幅(Ib)および平均帯域幅(Ab)の値に変換するステップをさらに含む、請求項11に記載のシステム。
17. 前記瞬時帯域幅(Ib)は以下の式:
    Ib=BS/W
    によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「W」は時間単位で表現されるウィンドウサイズである、請求項16に記載のシステム。
18. 前記平均帯域幅(Ab)は以下の式:
    Ab=BS/P
    によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「P」は時間単位で表現される期間である、請求項16に記載のシステム。
19. 前記平均帯域幅(Ab)は以下の式:
    Ab=T×(Z%)
    によって決定され、式中、「Ab」は平均帯域幅であり、「T」はソフトウェア要求を出している中央処理装置の所望のクロック速度であり、「Z%」は使用の割合およびキャッシュミスの割合のうちの少なくとも1つである、請求項16に記載のシステム。
20. 前記平均帯域幅(Ab)は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の合計から計算され、前記瞬時帯域幅は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の最大値から計算される、請求項16に記載のシステム。
21. ポータブルコンピューティングデバイス（PCD）のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを動的に作成しサービスするためのコンピュータシステムであって、
    マスタースレーブペアを含むクライアント要求を受信するための手段と、
    前記マスタースレーブペアに対応するスレーブについての検索を実行するための手段と、
    前記マスタースレーブペアに対応する通信のルートを作成するための手段と、
    前記ルートに対応する1つまたは複数のハンドルをメモリデバイスに記憶するための手段と、
    前記ルートの帯域幅を設定するための手段と、
    前記作成されたルートを使用して、前記ルートの前記帯域幅が設定された後に前記クライアント要求を処理するための手段と
    を含むシステム。
22. 前記スレーブについての前記検索を実行するための前記手段は、マスタースレーブ階層における各スレーブに割り当てられた一意の識別子を比較するための手段をさらに含む、請求項21に記載のシステム。
23. 前記スレーブについての前記検索を実行するための前記手段は、スイッチファブリック内で問合せ可能なスレーブを求めてファブリックルートチェックテーブルを確認するための手段をさらに含む、請求項21に記載のシステム。
24. 前記スレーブについての前記検索を実行するための前記手段は、前記PCDの1つまたは複数の異なるスイッチファブリックで検索するための手段をさらに含む、請求項21に記載のシステム。
25. 各マスターがノードによって表され、各スレーブがノードによって表される通信を追跡するためのノードアーキテクチャを利用するための手段をさらに含む、請求項21に記載のシステム。
26. 前記ルートの前記帯域幅を設定するための前記手段は、前記クライアント要求のパラメータを瞬時帯域幅(Ib)および平均帯域幅(Ab)の値に変換するための手段をさらに含む、請求項21に記載のシステム。
27. 前記瞬時帯域幅(Ib)は以下の式:
    Ib=BS/W
    によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「W」は時間単位で表現されるウィンドウサイズである、請求項26に記載のシステム。
28. 前記平均帯域幅(Ab)は以下の式:
    Ab=BS/P
    によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「P」は時間単位で表現される期間である、請求項26に記載のシステム。
29. 前記平均帯域幅(Ab)は以下の式:
    Ab=T×(Z%)
    によって決定され、式中、「Ab」は平均帯域幅であり、「T」はソフトウェア要求を出している中央処理装置の所望のクロック速度であり、「Z%」は使用の割合およびキャッシュミスの割合のうちの少なくとも1つである、請求項26に記載のシステム。
30. 前記平均帯域幅(Ab)は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の合計から計算され、前記瞬時帯域幅は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の最大値から計算される、請求項26に記載のシステム。
31. コンピュータにより実行可能なコンピュータ可読プログラムコードを含むコンピュータプログラムであって、前記コンピュータ可読プログラムコードは、ポータブルコンピューティングデバイス（PCD）のスイッチファブリック内およびスイッチファブリック間でマスタースレーブペアを作成しサービスするための方法を実施するために実行されるように適合し、前記方法は、
    前記マスタースレーブペアに対応するスレーブについての検索を実行するステップと、
    前記マスタースレーブペアに対応する通信のルートを作成するステップと、
    前記ルートに対応する1つまたは複数のハンドルをメモリデバイスに記憶するステップと、
    前記ルートの帯域幅を設定するステップと、
    前記作成されたルートを使用して、前記ルートの前記帯域幅が設定された後にクライアント要求を処理するステップと
    を含む、コンピュータプログラム。
32. 前記スレーブについての前記検索を実行するステップは、マスタースレーブ階層における各スレーブに割り当てられた一意の識別子を比較するステップを含む、請求項31に記載のコンピュータプログラム。
33. 前記スレーブについての前記検索を実行するステップは、スイッチファブリック内で問合せ可能なスレーブを求めてファブリックルートチェックテーブルを確認するステップを含む、請求項31に記載のコンピュータプログラム。
34. 前記スレーブについての前記検索を実行するステップは、前記PCDの1つまたは複数の異なるスイッチファブリックで検索するステップを含む、請求項31にコンピュータプログラム。
35. 前記方法を実施する前記コンピュータ可読プログラムコードは、
    各マスターがノードによって表され、各スレーブがノードによって表される通信を追跡するためのノードアーキテクチャを利用するステップをさらに含む、請求項31に記載のコンピュータプログラム。
36. 前記ルートの前記帯域幅を設定するステップは、前記クライアント要求のパラメータを瞬時帯域幅(Ib)および平均帯域幅(Ab)の値に変換するステップをさらに含む、請求項31に記載のコンピュータプログラム。
37. 前記瞬時帯域幅(Ib)は以下の式:
    Ib=BS/W
    によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「W」は時間単位で表現されるウィンドウサイズである、請求項36に記載のコンピュータプログラム。
38. 前記平均帯域幅(Ab)は以下の式:
    Ab=BS/P
    によって決定され、式中、「BS」はバイト数で表現されるブロックサイズであり、「P」は時間単位で表現される期間である、請求項36に記載のコンピュータプログラム。
39. 前記平均帯域幅(Ab)は以下の式:
    Ab=T×(Z%)
    によって決定され、式中、「Ab」は平均帯域幅であり、「T」はソフトウェア要求を出している中央処理装置の所望のクロック速度であり、「Z%」は使用の割合およびキャッシュミスの割合のうちの少なくとも1つである、請求項36に記載のコンピュータプログラム。
40. 前記平均帯域幅(Ab)は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の合計から計算され、前記瞬時帯域幅は、前記作成されたルートに対応するスイッチファブリック内およびスイッチファブリック間のすべてのクライアント要求の最大値から計算される、請求項36に記載のコンピュータプログラム。

Images