JP2002041308A - マルチプロセッサ・オブジェクト制御 - Google Patents

Abstract

(57)【要約】 【課題】 オーバーヘッドを低減しスループット向上を
図ったクライアント−サーバ・システムを提供する。 【解決手段】 クライアント−サーバ・システムは、２
フェーズでサーバ・タスクのスケジューリングを行い、
クライアント・デッドライン・フェーズ情報を第２のフ
ェーズのサブタスク・サーバ・スケジューリングで用い
る。また、システムのオブジェクト・ブローカは、クラ
イアント要求コールおよびリターンを崩壊させ、コプロ
セッサにおいてデータを維持する。マルチタスキング用
のサーバ・メモリ管理および多数のプロセッサの共有メ
モリを用いたデータ・フローにより、一次プロセッサ・
バスの輻輳を回避する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電子デバイスに関
し、特に、マルチプロセッサおよびディジタル信号プロ
セッサ分散オブジェクトおよび方法に関する。

【０００２】

【従来の技術】インターネットの成長は、高速ネットワ
ーク・アクセスと相俟って、分散計算環境を主流に押し
上げた。共通オブジェクト要求ブローカ・アーキテクチ
ャ（ＣＯＲＢＡ）および分散コンポーネント・オブジェ
クト・モデル（ＤＣＯＭ）規格が生まれ、オブジェクト
指向ネットワーク・プログラミングおよびコンポーネン
ト・ソフトウエア手法が簡略化された。したがって、ク
ライアント・アプリケーションは、リモート・サーバ・
オブジェクトにデータまたは機能性を与えるように要求
し、これによって、アプリケーションのプログラミング
を簡略化することが可能となる。図２４は、汎用リモー
ト・プロシージャ・コール・アーキテクチャを示す。実
際には、オブジェクト指向プログラミングは詳細をカプ
セル化し、これによって、他のオブジェクトとのクエリ
または双方向処理に対してオブジェクト・インターフェ
ースのみを提示し、かかる分散計算環境を可能としてい
る。

【０００３】ＣＯＲＢＡの中核は、オブジェクト要求ブ
ローカ（ＯＲＢ）であり、これはローカルおよびリモー
トのオブジェクト間の双方向処理に「バス」を提供す
る。ＣＯＲＢＡオブジェクトは、一組のメソッドおよび
インターフェースである。ＣＯＲＢＡオブジェクトのク
ライアントは、オブジェクトがクライアントのアドレス
空間に位置するかのように、オブジェクトのリファレン
スをメソッド・コール用のハンドルとして用いる。ＯＲ
Ｂは、（可能なリモート・サーバ上の）オブジェクト・
インプリメンテーションを発見し、クライアント・アプ
リケーションからのコール要求を受信するようにオブジ
ェクトの準備を行い、クライアントからの要求（例え
ば、パラメータ）をオブジェクトに転送し、何らかの回
答をオブジェクトからクライアントに戻す役割を果た
す。オブジェクト・インプリメンテーションは、ＯＲＢ
インターフェースまたはオブジェクト・アダプタ（Ｏ
Ａ）のいずれかによってＯＲＢと双方向処理を行う。図
２５は、ＣＯＲＢＡアーキテクチャ全体を示す。

【０００４】インターフェース定義言語（ＩＤＬ）は、
オブジェクト指向プログラミングでは常にそうであるよ
うに詳細（データ，インプリメンテーション）を隠しつ
つクライアントによって呼び出されるべきメソッドを含
むオブジェクトのインターフェースを定義する。通常で
は、ＩＤＬは、データ・カプセル化，ポリモーフィズム
（polymorphism）およびインヘリタンス（inheritanc
e）を規定する。図２４に示すように、クライアント
は、まずクライアント・スタブ（プロクシ）にコールす
ることによってオブジェクトの関数を呼び出す。スタブ
はコール・パラメータをメッセージ内に整列させ、ワイ
ヤ・プロトコルはメッセージをサーバ・スタブ（スケル
トン）に送り、サーバ・スタブはメッセージからコール
・パラメータを抜き取る（unmarshal）とともにオブジ
ェクトの関数をコールする。図２５における最上層は基
本プログラミング・アーキテクチャであり、中間層はリ
モーティング・アーキテクチャであり、最下位層はワイ
ヤ・プロトコル・アーキテクチャである。クライアント
・プログラムおよびサーバ・オブジェクト・プログラム
の開発者は基本プログラミング・アーキテクチャを用い
て作業を行い、リモーティング・アーキテクチャはイン
ターフェース・ポインタ，オブジェクト・リファレンス
およびハンドルをクライアントとサーバ・プロセスとの
間で意味のあるものにする。ワイヤ・プロトコルはリモ
ーティング・アーキテクチャを種々のハードウエア・デ
バイス間に効果的に拡張する。

【０００５】Cheung らの“DCOM and CORBA Side by Si
de, Step by Step, and Layer by Layer”に記載されて
いるように、ＣＯＲＢＡイネーブルされたクライアント
およびサーバ・プロセッサによってリモート・オブジェ
クトを用いる簡単なアプリケーションは、次の５つのフ
ァイルで作成することができる。（１）オブジェクトに
対するインターフェースを定義するＩＤＬファイル。Ｉ
ＤＬコンパイラは、クライアントおよびサーバの双方に
よって用いられるインターフェース・ヘッダ・ファイル
とともにクライアント・スタブおよびオブジェクト・ス
ケルトン・コードを発生する。（２）インターフェース
からのオブジェクトに対してサーバ・インプリメンテー
ション・クラスを導出するインプリメンテーション・ヘ
ッダ・ファイル。本質的に、インプリメンテーション・
クラスは、ＩＤＬコンパイラによって作成されたインタ
ーフェース・クラスと（インヘリタンスによって）関連
付けられている。（３）サーバ・クラスのメソッドのイ
ンプリメンテーション。（４）サーバ用の主プログラ
ム。このプログラムはサーバ・クラスのインスタンス
（オブジェクト）をインスタンス化する。（５）クライ
アント・スタブに対するコールによってオブジェクトの
メソッドを呼び出すクライアント・アプリケーション。

【０００６】静的なオブジェクトの呼出しでは、コンパ
イル後ではあるが実行前に、ＣＯＲＢＡはインターフェ
ース名とインプリメンテーション・レポジトリ（図２５
参照）で実行可能なサーバのパス名との間の連携を登録
する。動的なオブジェクト呼出しでは、ＩＤＬコンパイ
ラは、インターフェースのメソッド毎にタイプ情報も発
生し、それをインターフェース・レポジトリに格納す
る。クライアントは、インターフェース・レポジトリに
問い合わせして特定のインターフェースに関するランタ
イム情報を獲得し、それを用いて動的呼出しインターフ
ェースを介して動的にオブジェクト上のメソッドを呼び
出す。同様に、サーバ側では、動的スケルトン・インタ
ーフェースは、それが実行しているオブジェクトのタイ
プのコンパイル時知識を有さないオブジェクト上で動作
をクライアントが呼び出すことを可能にする。

【０００７】図２６ａは、オブジェクトのクライアント
要求のＣＯＲＢＡ最上層（基本プログラミング・アーキ
テクチャ）アクティビティおよびそれのメソッドの呼出
しと、サーバのオブジェクト・インスタンスの作成およ
びそれのクライアントへの利用可能性とを示す。特に、
オブジェクト活性化（activation）は次のように行われ
る。（１）クライアントがオブジェクト・インターフェ
ースに対するクライアント・スタブの静的関数をコール
する。（２）ＯＲＢは、オブジェクト・インターフェー
スをサポートするオブジェクトを含むサーバを起動す
る。（３）サーバ・プログラムは、オブジェクトをイン
スタンス化するとともに、オブジェクト・リファレンス
を登録する。（４）ＯＲＢはオブジェクト・リファレン
スをクライアント・アプリケーションに戻す。続いて、
オブジェクト・メソッド呼出し［１］，［２］のため
に、クライアントは、最終的にサーバのメソッドを呼び
出すオブジェクト・インターフェースのメソッドをコー
ルする。メソッドが値を戻すならば、サーバはこれらを
クライアントに返送する。

【０００８】図２６ｂは、オブジェクト活性化に伴うＣ
ＯＲＢＡ中間層（リモーティング・アーキテクチャ）を
示す。（１）コールの受信時、クライアント・スタブは
タスクをＯＲＢに任命する。（２）ＯＲＢは、インプリ
メンテーション・レポジトリを参照してコールをそれの
サーバ・パス名にマップするとともに、サーバ・プログ
ラムを活性化する。（３）サーバは、オブジェクトをイ
ンスタンス化するとともに、一意のリファレンスＩＤを
作成してオブジェクト・リファレンスを得る。オブジェ
クト・リファレンスをＯＲＢに登録する。（４）サーバ
・クラス用のコンストラクタ（constructor）もスケル
トン・クラスのインスタンスを作成する。（５）ＯＲＢ
は、オブジェクト・リファレンス・タックをクライアン
トに送るとともに、クライアント・スタブ・クラスのイ
ンスタンスを作成し、対応するオブジェクト・リフェレ
ンスとともにそれをクライアント・スタブ・オブジェク
ト・テーブルに登録する。（６）クライアント・スタブ
はクライアントにオブジェクト・リファレンスを戻す。
続いて、オブジェクト・メソッドのクライアント呼出し
を進め、［１］クライアント・コールの受信時に、クラ
イアント・スタブは、要求疑似オブジェクトを作成し、
コールのパラメータを疑似オブジェクト内に整列させ、
疑似オブジェクトをサーバーへのチャンネルにおけるメ
ッセージに置くようにコールし、回答を待つ。［２］メ
ッセージがサーバに到達すると、ＯＲＢは、ターゲット
・スケルトンを発見し、要求疑似オブジェクトを再構築
し、それをスケルトンに転送する。［３］スケルトン
は、要求疑似オブジェクトからパラメータを抜き取り、
サーバ・オブジェクトのメソッドを呼び出し、（ある場
合には）戻り値を整列させ、スケルトン・メソッドから
戻る。ＯＲＢは、回答メッセージを構築するとともに、
それを送信バッファに入力する。［４］回答がクライア
ント側に到達すると、ＯＲＢコールは、受信バッファか
らの回答メッセージを読んだ後にリターンする。続い
て、クライアント・スタブは、戻り値を抜き取るととも
に、それらをクライアントに戻してコールを完了する。

【０００９】図２６ｃに示すように、オブジェクト活性
化用の最下位層（ワイヤ・プロトコル・アーキテクチ
ャ）は、（１）要求の受信時に、クライアント側ＯＲＢ
がオブジェクトをサポートする機械を選択するととも
に、ＴＣＰ／ＩＰを介してサーバ側ＯＲＢに要求を送る
ことを含む。（２）サーバ側ＯＲＢがサーバを起動する
と、オブジェクトはサーバによってインスタンス化さ
れ、ＯＲＢコンストラクタがコールされ、作成機能（cr
eate function）が呼び出される。作成機能の内部では
ソケット終点が作成され、オブジェクトはオブジェクト
・アイデンティティが割り当てられ、インターフェース
名およびインプリメンテーション名とリファレンス・ア
イデンティティと終点アドレスを含むオブジェクト・リ
ファレンスが作成される。オブジェクト・リファレンス
にはＯＲＢが登録される。（３）オブジェクト・リファ
レンスがクライアント側に戻されるとき、クライアント
・スタブは、終点アドレスを抽出するとともに、サーバ
へのソケット接続を確立する。続いて、メソッド呼出し
を進め、［１］コールの受信時に、クライアント・スタ
ブはパラメータを共通データ表現（ＣＤＲ）フォーマッ
トで整列させる。［２］要求は、確立されたソケット接
続を介してターゲット・サーバに送られる。［３］ター
ゲット・スケルトンは、リファレンス・アイデンティテ
ィまたはインターフェース・インスタンス識別子のいず
れかによって識別される。［４］サーバ・オブジェクト
上で実際のメソッドを呼び出した後に、スケルトンは戻
り値をＣＤＲフォーマットで整列させる。

【００１０】ＣＯＲＢＡのリアル・タイム拡張は、通
常、予測可能な処理能力，安全な動作およびリソース割
当てというようなサービス品質（ＱｏＳ）アスペクトを
備えている。例えば、Gillらの“Applying Adaptive Mi
ddleware to Manage End-to-End QoS for Next-generat
ion Distributed Applications”。

【００１１】ＣＯＲＢＡコンポーネントはメタタイプと
して導入され、また、関連するコンポーネント・インプ
リメンテーション定義言語（ＣＩＤＬ）はインプリメン
テーションを記述するために利用可能である。図２７
は、プログラミング・ステップを示す。ＤＣＯＭは、同
様に、３つのレイヤと、ＣＯＲＢＡにいくらか類似した
アーキテクチャとを有する。

【００１２】Notenboomの米国特許第５，７４８，４６
８号とEquator Technologies のＰＣＴ公開ＷＯ９９／
１２０９７号はそれぞれ、プロセッサ・リソースを多数
のタスクに割り当てる方法について記載している。Note
nboomは、優先度システムに従ってコプロセッサ・リソ
ースを割り当てられたタスクとともにホスト・プロセッ
サおよびコプロセッサを考慮する。Equator Technologi
esは、サポートされた少なくとも１つのサービス・レベ
ル（プロセッサ・リソース消費レート）を各タスクが提
示するタスク時間消費に従ってプロセッサ・リソースを
スケジュール化し、また、リソース・マネージャは、サ
ポートされたサービス・レベルに十分なリソースが存在
するならば、タスクを受け入れる。

【００１３】各プロセッサがそれ自体のオペレーティン
グ・システムまたはＢＩＯＳを有する２つ以上のプロセ
ッサを持つシステムは、インターネットを介して接続さ
れた広分散プロセッサを有するシステムや、ＲＩＳＣ
ＣＰＵおよび１つ以上のＤＳＰのような同じ半導体ダイ
上に２つ以上のプロセッサが集積されたシステムも含ま
れる。

【００１４】ＸＤＡＩＳ規格は、ＤＳＰ上で走るアルゴ
リズム用のインターフェースを規定する。これは再使用
可能なオブジェクトを備える。ＸＤＡＩＳは、アルゴリ
ズムが標準的なインターフェースＩＡＬＧおよびそのア
ルゴリズムを走らせるための拡張部を実装することを要
求する。ＸＤＡＩＳは、リロケータブル・コードや命名
慣例のようなある種の柔軟性規則に従うことも要求す
る。クライアント・アプリケーションは、関数ポインタ
のテーブル内にコールすることによってアルゴリズムの
インスタンスを管理することができる。ＸＤＡＩＳ規格
／指針では、アルゴリズム開発者は、ｉＤＳＰメディア
・プラットフォームＤＳＰフレームワークのようなＤＳ
Ｐアプリケーション・フレームワークへのプラグがもっ
と容易になるように、アルゴリズムを開発または変換す
ることができる。

【００１５】フレームワーク・ノード（クライアント／
サーバ）内のサービス品質（ＱｏＳ）マネージャの必要
性は、具体的には、全てのストリーミング・メディア系
アプリケーションのリアル・タイム・サービス要求から
生じた。ストリーミング・メディア・アプリケーション
は、異種コデック（エンコーダ／デコーダ）を扱わなけ
ればならないとともに、一意のレンダリング・デッドラ
イン（rendering deadline）でフィルタをかける。これ
らのアプリケーションも、人間の知覚特性を利用してサ
ービス品質におけるグレースフル・デグラデーション
（graceful degradation）に変換することができるべき
である。それらは、それらの処理およびレンダリング・
サイクルにおいて適量のジッタを扱うことができるべき
である。例えば、ビデオ・アプリケーションでは、レン
ダリング用フレーム・レートを３０フレーム／秒（ｆｐ
ｓ）に維持しなければならず、これは３３ｍｓのフレー
ム期間に換算される。しかしながら、アプリケーション
は、サーバとネゴシエート（negotiate）して、限られ
た瞬時的な変動には耐えることができなければならな
い。また、３０ｆｐｓでは、人間の視覚は約６フレーム
／秒のフレーム欠落に耐えることができる。クライアン
ト・アプリケーションも、処理（瞬時的なフレームの欠
落）におけるグレースフル・デグラデーションをサポー
トすることができるとともに、サーバとネゴシエートさ
れた特定の許容度以内でレンダリングの定常状態を維持
しなければならない。ＱｏＳマネージャとは、そのよう
なリアル・タイム・システムを実現するための必要な機
能および能力を備える機構のことである。

【００１６】ＤＳＬやケーブル・モデムのような広帯域
通信が新たなマーケットに激増しかつ空前の量のデータ
を処理および消費用の消費者デバイスに配信するにつれ
て、もっと効率的なデータ処理，ルーティングおよび処
理技術がこれを支えるために必要となる。

【００１７】図２０は、データがどのように現行の異種
システムの処理エレメントを流れるかを示す図である。
各データ・トランザクションは番号付けされて時間順序
を示す。各トランザクション毎に、データは中央制御プ
ロセッサ（ＣＣＰ）の制御の下でシステム・バスを通過
しなければならない。ＣＣＰは、制御パスを介してメッ
セージまたはトリガをシステム内の種々の処理エレメン
トに送ることによってトランザクションを開始する。

【００１８】図２０の処理エレメントは、規定された一
組のタスクを実行することができる別個のプロセッサ
（例えば、ＤＳＰ，ＡＳＩＣ，ＧＰＰなど）として示さ
れている。これは、各々がそれ自体のメモリとともに示
されている理由である。処理エレメントは、同一プロセ
ッサ上で走る個々のタスクとすることも可能である。

【００１９】

【発明が解決しようとする課題】場合によっては、同じ
データが多数回（例えば、トランザクション１および
２，３および４，５および６）システム・バスを通過し
なければならない。そのようなシステムでは、データは
合計２＋（２×ｎ）回（すなわち、この場合には６回）
システム・バスを通過しなければならない。システム・
バスを通過しＣＣＰによる介入がある毎に、データ・フ
ロー・オーバーヘッドをもたらすとともに、全体的なシ
ステム・スループットを低下する。

【００２０】データ・フロー・オーバーヘッドは、所与
の時間フレームにおいてシステムを移動できるデータ量
に悪影響を及ぼし、それにより、システムが処理できる
データ量を制限する。おそらく、そのようなシステム
は、さもなければそれのエレメントのケーパビリティの
合計が示すよりももっと少ない有用なタスクを実行する
であろう。

【００２１】

【課題を解決するための手段】本発明は、サーバ・タス
クの２フェーズ・スケジューリングとサーバＤＳＰ上に
おけるタスクの連鎖を用いたクライアント−サーバ・シ
ステム用オブジェクト要求ブローカとプロセッサ・オー
バーヘッドおよび一度に単一の実行タスクに属するタス
ク・ワークスペースへの内部メモリ区分によるマルチタ
スク・プロセッサ内部メモリ管理と中央制御プロセッサ
およびバス接続された処理エレメントおよび処理エレメ
ント用共有メモリを含んで中央制御プロセッサ・バスを
回避する異種システムにおけるデータ・フローとを含む
特徴の１つ以上を有するクライアント−サーバ・システ
ムを提供する。

【００２２】

【発明の実施の形態】１．概要 好適な実施形態のシステムは、通常、クライアント・ア
プリケーションを走らせるホスト・プロセッサとサーバ
・アルゴリズムを走らせる１つ以上のサーバ・プロセッ
サとを有し、また、アルゴリズム・オブジェクト用のオ
ブジェクト要求ブローカとオブジェクト要求ブローカ用
のサービス品質制御とアルゴリズム・オブジェクト用の
メモリ・ページングとアルゴリズム・オブジェクト用の
データ・フローとを含む。ｉＤＳＰＯｒｂと称する好適
な実施形態は、一次プロセッサと１つ以上のＤＳＰコプ
ロセッサとを備えたシステムに適用される。

【００２３】ｉＤＳＰＯｒｂは、ＤＳＰオブジェクトの
作成とマルチプロセッサ環境における汎用プロセッサ
（ＧＰＰ）または他のＤＳＰからのＤＳＰオブジェクト
へのアクセスをサポートする高性能ＤＳＰオブジェクト
要求ブローカ（ＤＳＰＯＲＢ）である。ｉＤＳＰＯｒｂ
は、ＣＯＲＢＡに類似した全体的アーキテクチャおよび
動作を有する。ｉＤＳＰＯｒｂは、以下のＤＳＰＯＲＢ
機能を有する。 （１）ｉＤＳＰＯｒｂは、プロセッサ境界を越えたオブ
ジェクト結束および呼出し（ＤＳＰオブジェクト・プロ
シージャ・コール）をサポートする。 （２）ｉＤＳＰＯｒｂは、静的呼出し用のコンパイル時
ヘッダおよびスタブとランタイム動的呼出しインターフ
ェースとの双方からなるＧＰＰ側プロクシ・インターフ
ェースを備えている。 （３）ｉＤＳＰＯｒｂは、ｉＤＳＰサーバを構築するた
めのＤＳＰ側アルゴリズム・インターフェース（スタブ
およびヘッダ）を備えている。 （４）ｉＤＳＰＯｒｂは、同期および非同期の双方の呼
出しを行うことができる。 （５）ｉＤＳＰＯｒｂは、リアル・タイムＱｏＳを保証
する。 （６）ｉＤＳＰＯｒｂは、フレーム単位処理およびスト
リーム単位処理の双方を可能にする。 （７）ｉＤＳＰＯｒｂは、オブジェクト連鎖データ・フ
ロー（中間結果はＤＳＰメモリに留まる）に対応する。 （８）ｉＤＳＰＯｒｂは、広帯域幅マルチチャネルＧＰ
Ｐ／ＤＳＰ Ｉ／Ｏインターフェース上で実行される。

【００２４】図１は、ＧＰＰ／ＤＳＰデュアル・プロセ
ッサ構成用のｉＤＳＰＯｒｂアーキテクチャを示し、こ
こで、ＧＰＰは「クライアント」として作動し、ＤＳＰ
は「サーバ」として作動する。

【００２５】ここではｉＤＳＰ-ＱｏＳＭと呼ばれるｉ
ＤＳＰシステム内のサービス品質（ＱｏＳ）マネージャ
は、クライアント・アプリケーションにネゴシエート・
レベルのサービスを提供する（サーバ内部の）機構であ
る。それは、クライアントに伝達される所定の低下政策
（degradation policy）を備えた保証されたサービス品
質を提供する。ｉＤＰＳ-ＱｏＳＭは次の特徴を有す
る。（１）それは、ネットワーク上に常駐するノードの
限られたコンテクストの内部で定義される（ノード
内）。それは、ノード間（ネットワーク）通信を制御す
るために適当なＱｏＳマネージャの存在を仮定する。
（２）それは、負荷共有能力を備えたマルチ・プロセッ
サ環境のために定義される。

【００２６】好適な実施形態のｉＤＳＰ-ＱｏＳＭによ
って実行される機能は次のものを含む。（１）システム
内のサーバ上における定常状態処理負荷の監視。（２）
過負荷サーバからそれのピア（peer）への負荷分散。
（３）サーバにあらゆる追加負荷を登録するためのクラ
イアント・アプリケーションとのサービス要件のネゴシ
エーション。（４）サーバによってサービスされる個々
のオブジェクトの具体的な特性に基づいたサーバ上の将
来負荷の予測。（５）アルゴリズム・ランタイム予測は
処理時間の代わりにプロセッサ時間のサイクルに基づく
であろう。このようなアルゴリズム・ランタイム予測は
プロセッサ動作周波数には結び付けられていない。

【００２７】テキサス・インスツルメンツ社のTMS320C6
2XX ＤＳＰでは、内部（オン・チップ）データ・メモリ
の量は限られている。TMS320C6211（およびそれの派生
製品）を除いて、TMS320C62XX ＤＳＰは、外部メモリ
（オフ・チップ）アクセスを効率的にするデータ・キャ
ッシュを有していない。内部メモリは、TMS320C62XX Ｄ
ＳＰのデータ・メモリ階層内の最上位レベルにある。し
たがって、TSM320C62XXＤＳＰ上で走る全てのアルゴリ
ズムはそれらのデータ・ワークスペースのために内部メ
モリを使いたい。何故なら、それはデータ・メモリにア
クセスするための最上位の効率であるからである。

【００２８】通常、ＤＳＰ用のアルゴリズムは、それら
がＤＳＰプロセッサ全体を所有すると、したがって、Ｄ
ＳＰの全ての内部メモリを所有すると仮定して、開発さ
れる。これは、数個の異なるアルゴリズムを集積するこ
とを、それらが同じであろうが（同質）異なろうが（異
質）、非常に困難にする。内部メモリのようなシステム
・リソースにアクセスし使用する共通の方法に関するア
ルゴリズム開発者には、一組の規則が必要とされてい
る。

【００２９】好適な実施形態は、ＤＳＰ内部メモリにデ
ータ・ページング・アーキテクチャを用いることによっ
てデータ・キャッシュのないＤＳＰ上で多数のアルゴリ
ズムを走らせる際のプロセッサ利用度を高める方法を提
供する。データ・ページング・アーキテクチャに準拠す
るＤＳＰアルゴリズムの開発または変換はテキサス・イ
ンスツルメンツＸＤＡＩＳ規格を用いて達成することが
できる。この規格は、アルゴリズム開発者に、当該アル
ゴリズムに対して全てのデータ・メモリをサポートする
少なくとも１つ以上のメモリ領域を定義するように要求
する。これらのユーザ定義領域の中の１つまたは全てが
TMS320C62X ＤＳＰの内部メモリで走るようにアルゴリ
ズム開発者によって選択される。アプリケーションのＤ
ＳＰシステム・ソフトウエア部分内部では、内部メモリ
はシステム・サポートとデータ・ワークスペース（ペー
ジ）とに分割される。ＤＳＰアプリケーション内部の全
てのアルゴリズムは、ワークスペースを共有するととも
に、実行時にワークスペース全体を所有する。２つのア
ルゴリズム間のコンテクスト・スイッチ上では、ＤＳＰ
システム・ソフトウエアは、ワークスペースと各アルゴ
リズムの外部シャドー・メモリとの間の転送をそれぞれ
処理するであろう。好適な実施形態は次のように構成さ
れている。

【００３０】（１）２つ以上のＤＳＰアルゴリズム間の
データ・キャッシュのないＤＳＰ内の内部データ・メモ
リの共有はプロセッサ利用度を高める。 （２）同じ共有内部メモリからの多数のアルゴリズムを
走らせることは、スタック要件およびアルゴリズム内部
変数をサポートするためにデータ・メモリにアクセスす
るとき、各アルゴリズムがTMS320C62X ＤＳＰ環境にお
いて最大効率を発揮することを可能にさせる。 （３）このアーキテクチャは、内部メモリとプロセッサ
の内部メモリにアクセスできるＤＭＡユーティリティと
を備えたいずれかの単一プロセッサ上で機能する。 （４）データ入力フレーム境界においてのみコンテクス
ト・スイッチを実行することはデータ・ページング・ア
ーキテクチャの最大効率を与える。読み取られるだけで
あるアルゴリズム・データの非対称ページ転送をサポー
トする。

【００３１】アプリケーションにおけるデータ・フロー
はアルゴリズムからアルゴリズムへとすることができ、
また、好適な実施形態は、アルゴリズム実行毎にデータ
をＧＰＰとやりとりするのではなく、１つ以上のＤＳＰ
内にデータが残留するようにしている。

【００３２】２．デュアル・プロセッサ構成におけるＤ
ＳＰ ＯＲＢ 図１は、汎用プロセッサ（ＧＰＰ）およびディジタル信
号プロセッサ（ＤＳＰ）を含むデュアル・プロセッサ構
成用の好適な実施形態のＯＲＢ（「ｉＤＳＰＯｒｂ」）
アーキテクチャを示し、ここで、ＧＰＰは「クライアン
ト」として作動し、ＤＳＰは「サーバ」として作動す
る。ｉＤＳＰＯｒｂはサービス品質（ＱｏＳ）マネージ
ャを含むことに留意願いたい。図１は、２つのＤＳＰア
ルゴリズム・オブジェクト“Ａ”，“Ｂ”を呼び出すク
ライアント・アプリケーションを示す。ｉＤＳＰＯｒｂ
は、最初に、ＧＰＰ上でプロクシ（クライアント・スタ
ブ）オブジェクト“ａ”，“ｂ”のオブジェクト・バイ
ンディングを与える。例えば、“Ａ”および“Ｂ”は、
以下のように、デコーダ（ＤＥＣ）用のＤＳＰＩＤＬイ
ンターフェースの拡張とすることができる。

【００３３】

【表１】

【００３４】（ｉＤＳＰサーバと呼ばれる）ＤＳＰ側ア
プリケーションは、ＤＳＰＩＤＬコンパイラによって与
えられるアルゴリズム・インターフェースを用いて構築
される。

【表２】

【００３５】ＧＰＰ側アプリケーションは、ＤＳＰＩＤ
Ｌコンパイラによっても与えられるプロクシ・インター
フェースを用いて構築される。

【表３】

【００３６】または、ＧＰＰ側アプリケーションはｉＤ
ＳＰＯｒｂ動的呼出しインターフェースを用いて構築さ
れる。ランタイムでは、“ａ”はＧＰＰ側クライアント
・アプリケーションから呼び出されてバッファを処理す
ることができる。このデータはＤＳＰ側の実際のオブジ
ェクト“Ａ”に渡される。オブジェクト連鎖データ・フ
ローを用いて、“Ａ”の出力を“Ｂ”の入力に接続する
ことができる結果、中間データ・バッファはＧＰＰに転
送して戻されない。“ｂ”は、データをＧＰＰに戻す別
の処理ステップをもたらす“Ｂ”を呼び出す。ｉＤＳＰ
Ｏｒｂの動的呼出しインターフェースは対称呼出しおよ
び非対称呼出しの双方をサポートする。

【００３７】ｉＤＳＰＯｒｂはＧＰＰと単一ＤＳＰとの
間で区分される必要はない。それは多数のＤＳＰを備え
た構成においても走ることができる。この場合、ＱｏＳ
マネージャ（サーバ側）は利用可能ＤＳＰ間でＤＳＰア
ルゴリズムの負荷均衡化を実行する。他の構成は、（固
定機能ＤＳＰとして作動する）ＡＳＩＣすなわちＡＳＩ
ＣおよびＲＩＳＣからなることもでき、ここでは、アル
ゴリズム・インターフェースがクライアント・アプリケ
ーションに提供される。

【００３８】２ａ．ＤＳＰＩＤＬコンパイラ ｉＤＳＰＯｒｂは、ＤＳＰＩＤＬ、以下のキーワードを
有するＩＤＬ（インターフェース定義言語）をサポート
する。 module：インターフェース仕様の集合体 例えば、Ｈ２６３モジュールはデコーダ・インターフェ
ースおよびエンコーダ・インターフェースを内蔵するこ
とができる。 interface：インターフェース仕様 in：入力引数を示す out:出力引数を示す BUFFER:バッファ・タイプを示す STREAM:ストリーム・タイプを示す RESULT:関数のリターン・タイプを示す。 メモリ利用，リアル・タイムに対するその他。

【００３９】ＤＳＰＩＤＬファイルの一般フォームは次
の通りである。

【表４】

【００４０】また、directionはin, out,または[in, ou
t]であり、TYPEはBUFFERまたはSTREAMである。例えば、
H263 IDLは、図２に示すようなアルゴリズムおよびプロ
クシ・インターフェースを生成するかもしれない。

【００４１】２ｂ．フレームおよびストリーム処理 フレーム対ストリーム処理には、以下の相違がある。 キーワード： BUFFER:引数タイプとしてBUFFERを有する関数はフレー
ム毎に処理する。 STREAM:引数タイプとしてSTREAMを有する関数は、通常
はタスクを生成することによってフレームのストリーム
を処理する。

【００４２】関数コール

【表５】 は、オブジェクト出力を入力（それぞれフレームまたは
ストリーム）に接続する。バッファに対して、接続演算
子はＤＳＰＯＲＢにＤＳＰ上でメモリ・バッファを作成
させ、そこでは、１つのメソッド呼出しの出力は別のメ
ソッド呼出しの入力のために格納される（オブジェクト
連鎖）。例えば、

【表６】

【００４３】ストリーム処理では、

【表７】 のようなプロクシ呼出しは、通常は、ＤＳＰ側に作成さ
れたタスクをもたらして２つのストリーム ＳＩＯスト
リーム（H263 TIDEC decodeStreamのインプリメンテ
ーションはこれを行うタスクを生成する。）を取り扱
う。接続されていないストリームはクライアント・プロ
クシとサーバとの間のＩ／Ｏを与える。

【００４４】２ｃ．リアル・タイムＱｏＳマネージャ ｉＤＳＰＯｒｂは、設定された時間制約内で所与の動作
を実行するために必要とされるリソースをDSPORB Syst
em setTimeConstraint()およびDSPORB System setPr
iority()インターフェースを介して割り当てることによ
ってハード・リアル・タイムＱｏＳを与えることができ
る。ＧＰＰ／ＤＳＰチャネルＩ／Ｏドライバは多数のス
レッドが並列に動作することを可能にする。ＱｏＳマネ
ージャは、（１）クライアントによって必要とされるア
ルゴリズムをインスタンス化し、（２）クライアント・
アプリケーションからの制約を更新するとともにリソー
スを管理して制約を満たし（または、制約が満たされ得
なかったことを報告し戻し）、（３）その他のことを行
うＤＳＰ側のｉＤＳＰＯｒｂの一部である。

【００４５】２ｄ．ｉＤＳＰＯＲＢ登録サービス ｉＤＳＰＯｒｂはクラス登録サービスを備えているの
で、サーバ・オブジェクトはそれらのサービスを登録す
ることができる。例えば、サーバ・オブジェクトはｉＤ
ＳＰＯｒｂを用いて登録を行ってＭＰ３オーディオをデ
コードすることができる。クライアント・オブジェクト
は、所望のサービスの名称を供給することによってサー
バ・オブジェクトをインスタンス化する。ｉＤＳＰＯｒ
ｂ登録サービスは任意の種類のＤＳＰオブジェクト・サ
ービスに用いることができるが、それは、オーディオお
よびビデオ・サービス用の標準的な一組のモニカ（moni
ker）を備えることによって分かるメディア・ドメイン
である。

【００４６】

【表８】

【００４７】ｉＤＳＰＯｒｂ登録サービスは、ｉＤＳＰ
Ｏｒｂがランタイムにサーバ・オブジェクトを動的にイ
ンスタンス化することを可能にする。サーバ・オブジェ
クトをインスタンス化するとき、ｉＤＳＰＯｒｂはマイ
クロプロセッサとＤＳＰとの間に低レベルＩ／Ｏチャネ
ルを動的に割り当てる。これらの低レベル・チャネル
は、ｉＤＳＰＯｒｂストリーミング・インターフェース
（DSPORB Streamインターフェースを参照）を介してク
ライアント・オブジェクトによって直接にアクセスする
ことができる。ｉＤＳＰＯｒｂ登録サービスは、ｉＤＳ
ＰＯｒｂが特定のサービスを提供するＤＳＰを突き止め
ることを可能にする情報も提供し、また、それは、Ｑｏ
Ｓマネージャが負荷均衡化およびスケジューリング・プ
ロジェクションをすることを可能にする（リアルタイム
ＱｏＳマネージャを参照）。例えば、動的呼出しモデル
を用いて、コールDSPORB ALG create(“MP3 Audio De
code”, NULL)はＭＰ３オーディオ・デコーダのインス
タンスをインスタンス化するであろう。ｉＤＳＰＯｒｂ
負荷はシステムを均衡化し、また、クライアントは、Ｄ
ＳＰが実際にデコーダを実行している詳細と、どの低レ
ベル・ストリームがデータを通過させるために割り当て
られたかということとから遮蔽される。クライアントは
また、ｉＤＳＰＯｒｂに問い合せることによって、現在
登録されているサービス・クラスのリストを列挙する。
関数DSPORB Alg*DSPORB System getServices()は、
現在登録されているサービスのエニュメレータ（enumer
ator）を獲得するために用いられ得る。次に、char*DSP
ORB System next(DSPORB Alg*enum)は各登録された
サービスの名称を得るためにコールされ得る。目録(enu
meration)は、DSPORB System reset(DSPORB Handle*
enum)をコールすることによって先頭にリセットされ得
る。

【００４８】２ｅ．メディア・フレームワーク・サポー
ト ｉＤＳＰＯｒｂは、以下のような特定のメディア・フレ
ームワーク用のコンポーネントを備えることによってメ
ディア処理加速をサポートするために用いられ得る。 DirectShow（Ｗｉｎｄｏｗｓ（登録商標）メディア）：
フィルタ・オブジェクトは、ｉＤＳＰＯｒｂコデック・
クライアント・オブジェクトをラップ（wrap）するよう
に実装されることができ、DirectShowフレームワークに
プラグ・インされることができる。 RealMedia Architecture(RealSystem G2)：レンダラ・
プラグイン（rendererplugin）は、ｉＤＳＰＯｒｂコデ
ック・クライアント・オブジェクトをラップするために
実装されることができ、RealSystem G2フレームワーク
にプラグ・インされることができる。ＤＳＰＯｒｂは、
同じ方法論を用いてＪＭＦおよびQuickTimeにプラグ・
インすることもできる。

【００４９】ｉＤＳＰＯｒｂのＡＰＩはＤＳＰＯＲＢモ
ジュールにカプセル化することができる。クライアント
（ＧＰＰ）側ＤＳＰＯＲＢのデータタイプおよび関数は
以下のように指定される。 ２ｆ．データ・タイプ： DSPORB Alg：ＤＳＰアルゴリズム・オブジェクト用ク
ライアント・プロクシ。 DSPORB Fxn：動的呼出しと共に用いられる関数オブジ
ェクト。 DSPORB Arg：動的呼出しと共に用いられる関数引数オ
ブジェクト。 DSPORB BufferおよびDSPORB StreamはDSPORB Argの
「サブクラス」である。 DSPORB Params：ＤＳＰ側のIALG Paramsアルゴリズム
・パラメータ構造に一致するアルゴリズムに対してパラ
メータを与える。 DSPORB Buffer：バッファ・オブジェクト。 DSPORB Stream：ストリーム・オブジェクト。

【００５０】２ｇ．DSPORB Bufferインターフェース -DSPORB Buffer*DSPORB Buffer create(int size, i
nt direction);長さsizeのデータを参照することができ
るバッファ・オブジェクトを作成する。directionはDSP
BUFFER INPUTまたはDSPBUFFER OUTPUTの一方である。
バッファ方向が関数呼出しシグネーチャと一致しなけれ
ばならないか、ｉＤＳＰＯｒｂランタイム・エラーが発
生するであろう。または、DSPORB Buffer*DSPORB Buf
fer create(DSP ORB Alg*, int, int); オブジェク
トによって利用されるバッファ。 -unsigned char*DSPORB Buffer getData();バッファ
・オブジェクトによって参照されたデータを獲得する。
バッファが他のバッファに接続されているならば、ヌル
が戻される。 -Void DSPORB Buffer setData(usigned char*data) バッファ・データ・ポインタをセットする。このバッフ
ァが別のバッファに接続されているならば、この動作は
行われない。何故なら、このバッファのデータ用のメモ
リ空間はＤＳＰメモリ空間にあるからである。 -void DSPORB Buffer setSize(int) 実際のデータのサイズをセットする。 -int DSPORB Buffer getSize() 実際のデータのサイズを獲得する。 -void DSPORB Buffer delete(DSPORB Buffer*buffe
r) -int DSPORB Buffer connect(DSPORB Buffer*outpu
t, DSPORB Buffer*input) 入力バッファをＤＳＰ上の出力バッファに接続する。こ
れらのバッファ・オブジェクトが接続されているなら
ば、データは、ＤＳＰ上に残り、ＧＰＰに転送し戻され
ない（バッファは、中間結果を保持するためにＤＳＰ上
のｉＤＳＰＯｒｂによって作成される。）。

【００５１】２ｈ．DSPORB Streamインターフェース ストリーム・インターフェースは次のメソッドを有す
る。 -DSPORB Stream*DSPORB Stream create(int n, int
direction);ｎ個のバッファを保持することができるス
トリームを作成する。directionはDSPSTREAM INPUTま
たはDSPSTREAM OUTPUTの一方である。 -int DSPORB Stream issue(DSPORB Buffer*buf);入
力ストリーム上で送られる入力バッファbuf、または、
出力ストリーム上で満たされるキュー上に置かれた空バ
ッファを有する。接続されているストリームに対して
は、この動作は何の効果もない。何故なら、ストリーム
はアルゴリズム間に直接に接続されるであろうからであ
る。 -DSPORB Buffer*DSPORB Stream reclaim();出力スト
リームから出力バッファ、または、入力ストリーム上で
再送出され得る入力バッファを獲得する。接続されてい
るバッファに対しては、この動作は何の効果もない。 -DSPORB Stream select(DSPORB Stream array[], in
t n streams, int*mask, long millis);ストリームが
Ｉ／Ｏのために準備できるまでブロックする。 -DSPORB Stream idel(DSPORB Stream*str);ストリー
ムをアイドルする。 -DSPORB Stream close(DSPORB Stream*str);ストリ
ームを閉じる。 -DSPORB Stream conect(DSPORB Stream* out, DSPOR
B Stream*in);出力ストリームを入力ストリームに接続
する。２つの半ストリームは、ＤＳＰプロセッサ空間で
動作し、ＧＰＰにアクセス可能でない。

【００５２】２ｉ．ＤＳＰＯＲＢ動的呼出しインターフ
ェース 動的呼出しインターフェースは次のメソッドを有する。 -int DSPORB System int();ＤＳＰＯｒｂを初期化す
るために最初にコールされなければならない。 -DSPORB Alg*DSPORB Alg create(cost char*name, D
SPORB Params*params);シンボル‘name'によって参照
されたアルゴリズムのインスタンスを作成する。 -void DSPORB Alg delete(DSPORB Handle alg);アル
ゴリズム・インスタンスを削除する。 -DSPORB Fxn*DSPORB Alg getFxn(DSPORB Alg* alg,
const char* fxn name);シンボル‘fxn name'に関連
する関数オブジェクトを戻す。 -int DSPORB Fxn setTimeConstraing(DSPORB Fxn*fx
n);fxnの実行に対して時間境界をセットする。ＤＳＰＯ
ｒｂは、この制約を満たすために十分なリソースを割り
当てるか０を戻す。 -int DSPORB Fxn setPriority(DSPORB Fxn*fxn);１
から１５の優先度レベルをセットする。 -int DSPORB Fxn invoke(DSPORB Fxn*fxn, DSPORB
Arg*args[]);入力および出力上で関数を呼び出す。この
呼出しは、未接続出力で全てのデータが使用可能になる
までブロックする。‘DSPORB Buffer connect’と接
続されている入力および出力に対しては、‘NULL’が渡
され得る。 -int DSPORB Fxn invokeAsync(DSPORB Fxn*fxn, DSP
ORB Arg*args[]);入力および出力上で関数を呼び出
す。この呼出しは直ちに戻る。アプリケーションは、
‘DSPORB getData’を用いて出力引数オブジェクトか
らデータを引き出す。 -unsigned char*DSPORB Arg getData(DSPORB Arg*ou
tput, long timeout);出力引数オブジェクトからデータ
を獲得する。ナノ秒で‘timeout'が発生するまでブロッ
クするか、‘timeout＝−１’であれば無期限にブロッ
クする。 -void DSPORB Arg setCallback(DSPORB Arg* outpu
t, unsigned char*(*getData)(DSPORB Arg*));出力引
数上でコールバック関数をセットする。データが利用可
能であるときは、getDataがコールされる。 -void DSPORB System close()は、ＤＳＰＯｒｂを閉
じる。

【００５３】２ｊ．ｉＤＳＰＯｒｂの例 最初の例は、動的呼出しインターフェースを用いてC6xx
x上でTI H.263デコーダに接続するためにｉＤＳＰＯｒ
ｂがどのように用いられるかを示す。第２の例は、プロ
クシ・スタブを用いて書かれた同じプログラムを示す。

【表９】

【００５４】３．サービスの品質（ＱｏＳ） ｉＤＳＰＯｒｂサービス品質管理マネージャ(ｉＤＳＰ
−ＱｏＳＭ)を定義する好適な実施形態の構成は、ディ
ジタル信号プロセッサ（ＤＳＰ）のプールをピア・サー
バとして有するホスト・プロセッサからなる。特定のサ
ービス品質を維持するために必要な全ての関数を実行す
るアンブレラＱｏＳマネージャは、このＤＳＰサーバの
プールを管理する。ホスト・プロセッサは汎用プロセッ
サ（ＧＰＰ）である場合が多く、それは共有メモリまた
はバス型インターフェースのようなハードウエア・イン
ターフェースを介してＤＳＰに接続されている。ＱｏＳ
マネージャは、ｉＤＳＰＯｒｂの一部としてもよく、よ
り一般的には、ＤＳＰ上の別個のマネージャとしてもよ
い。システムはハードウエア割込みおよびソフトウエア
割込みの双方によって駆動される。好適な実施は主要な
ユーザ（クライアント）アプリケーションをＧＰＰ上で
走らせることであり、特定のサービスは負荷共有ベース
でＤＳＰ上を走る。ｉＤＳＰメディア・フレームワーク
のようなフレームワークはＱｏＳマネージャと同時に全
てのプロセッサ上で走ることができる。ｉＤＳＰ−Ｑｏ
Ｓマネージャは、３つの主要な機能、すなわち、（１）
オブジェクトの分類、（２）オブジェクトのスケジュー
リングおよび（３）オブジェクトの実行時間の予測を行
う。

【００５５】これら３つの機能について、メディア特定
例を用いてＧＰＰ／マルチＤＳＰ環境において、以下に
説明する。

【００５６】３ａ．オブジェクトの分類 メディア特定環境では、オブジェクトはメディア・コデ
ック／フィルタ（アルゴリズム）に変換する。メディア
・オブジェクトは、それらのストリーム・タイプ，アプ
リケーション・タイプまたはアルゴリズム・タイプに基
づいて分類され得る。アルゴリズムのタイプに応じて、
ＱｏＳマネージャは、コデック・サイクル，フィルタ・
サイクルなどとして知られているメトリックを規定す
る。

【００５７】３ｂ．オブジェクトのスケジューリング
（ハード・デッドライン） ｉＤＳＰ-ＱｏＳＭは、２フェーズ・スケジューラに基
づいてアルゴリズム・オブジェクトをスケジューリング
する。第１のフェーズは、新たなメディア・ストリーム
がＤＳＰ上でスケジュール可能か否かを判定するととも
にコデック・サイクルに対してハード・リアル・タイム
・デッドラインをセットする上位スケジューラである。
第２のフェーズは、個々のメディア・フレームをスケジ
ューリングするとともに、第１のフェースからのハード
・リアル・タイム・デッドラインを利用する。第１のフ
ェーズは、オブジェクト・ネゴシエーション時間で、通
常はホスト（ＧＰＰ）上で走る。第２のフェーズは、Ｄ
ＳＰ（サーバ）上で走るとともに、フレーム単位ベース
で走る。

【００５８】スケジューリングの第１のフェーズは、オ
ブジェクトが既に同時に走っているオブジェクトと共に
サポートされ得るか否かをＱｏＳマネージャが平均して
判定するときである。また、第１のフェーズ・スケジュ
ーリングの一部として必要とされるのは、メモリに関す
るオブジェクトに対しての十分なサポートの検討であ
る。内部使用，入力および出力用のオブジェクト・メモ
リ・バッファは、それのインスタンス化の時点で静的に
固定されて動的にメモリを割り当てることの不確実性を
排除しなければならない。ｉＤＳＰメディア・プラット
フォームはＸＤＡＩＳ準拠アルゴリズムを走らせるのみ
である。開発者は、彼らのアルゴリズムに対して異なる
条件下で処理時間を規定するように要求される。データ
のサーバへのトランスポートおよびサーバからのトラン
スポートに必要なおおよその時間は、それが各オブジェ
クトに対してデッドラインをセットするときにＱｏＳマ
ネージャによって考慮に入れられる（factor in）初期
化の時点で決定される。

【００５９】各ＤＳＰオブジェクトは、ＱｏＳマネージ
ャに以下の情報を供給する必要がある。 ｎ：コデック・サイクルおよびフレーム数（デフォル
ト：フレーム／秒）。 Ｔ_acc：ターゲット・サーバ（ＤＳＰ）サイクル数でコ
デック・サイクルを計算するための平均時間。 Ｔ_acd：ターゲット・サーバ（ＤＳＰ）サイクル数での
コデック・サイクルの表示時間。

【００６０】ビデオ・コデックについては、ｎは、通
常、連続Ｉ-フレーム間のフレーム数（例えば、１５フ
レーム）である。そして、Ｔ_accは、通常、Ｉ-フレーム
に必要な最大時間量とＰおよびＢフレームに必要な平均
時間との和である。ＱｏＳマネージャは全てのメディア
・オブジェクトに対してＴ_ccdを絶えず注意している。
（ＤＳＰサイクルに関する）この時間は現フレーム・レ
ートに基づく。例えば、３０ｆｐｒビデオ・ストリーム
およびｎ＝１５については、Ｔ_ccd＝１２５Ｍサイクル
となる。

【００６１】ＱｏＳマネージャは、新たなストリームが
スケジュール可能であるか否かを以下のように判定する
ことができる。現在スケジュールされている全てのスト
リームに対するコデック・サイクル（Ｔ_acc）の和をＳ
とする。新たなストリームに対する（Ｓ＋Ｔ_acc）が新
たなストリームに対するＴ_ccd未満であるならば、スト
リームはスケジュール可能であり、さもなければ、可能
ではない。例えば、ｎ＝１５，Ｔ_axc＝３９．５Ｍサイ
クル（１５８ｍｓ）およびＴ_ccd＝１２５Ｍサイクル
（５００ｍｓ）であるオブジェクト-Ａがあり、かつ、
ＤＳＰ上でスケジュールされたタスクがない（したがっ
て、Ｓ＝０）と仮定する。ＱｏＳマネージャは、オブジ
ェクト-Ａを必要とする新たなストリームのためにリソ
ースをスケジュールすることが通知される。Ｓ＋３９．
５＝３９．５Ｍサイクル＜１２５Ｍサイクル（５００ｍ
ｓ）であるので、そのストリームをスケジュールするこ
とができる。オブジェクト-Ａを必要とする第２のスト
リームが到達したとき、それもスケジュールされる。何
故なら、Ｓ＋３９．５＝７０Ｍサイクル（３１６ｍｓ）
＜１２５Ｍサイクル（５００ｍｓ）であるからである。
第３のストリームもスケジュールされ得る。しかしなが
ら、第４のストリームは、１５８Ｍサイクル（６３２ｍ
ｓ）を必要とし、５００ｍｓハード・デッドラインを満
たすことができないので、スケジュールされることがで
きない。この時点で、ＱｏＳマネージャは、ストリーム
のフレーム・レートを低下するようにネゴシエートし、
それに失敗すると、ストリーム全体を拒絶する。

【００６２】修正は、異なるコデック・サイクル時間で
異種のメディア・オブジェクトをスケジューラが処理す
ることを可能にする。もっと長いＴ_ccdを有するオブジ
ェクトは最も小さいＴ_ccdに割り当てられる。例えば、
ｎ＝３０，Ｔ_axc＝４０Ｍサイクル（１６０ｍｓ）およ
びＴ_ccd＝１６９Ｍサイクル（６７５ｍｓ）のオブジェ
クト-Ｂがあり、かつ、ＤＳＰ上でスケジュールされた
２つの（先に定義された）オブジェクト-Ａがある（し
たがって、Ｓ＝７９Ｍサイクル／３１６ｍｓ）と仮定す
る。Ｓ＋４０＊（１２５／１５８）＝１１０．４５Ｍサ
イクル（Ｓ＋１６０＊５００／６７５＝４３５ｍｓ）で
あるので、新たなオブジェクト-Ｂストリ−ムをスケジ
ュールすることができる。（７９＋４０＜１２５）Ｍサ
イクル／（３１６＋１６０＜５００）ｍｓであるので、
これは恐らく正しい。したがって、５００ｍｓというも
っと短いコデック・サイクル・デッドライン以内で全て
のストリームを実際に保証することができる。オブジェ
クト-Ｂを必要とする第２のストリームをスケジュール
しなければならないときに、何が発生するのか。１１
０．４５＋４０＊１２５／１５８＝１３９＞１２５Ｍサ
イクル／４３５＋１６０＊（５００／６７５）＝５５４
ｍｓ＞５００ｍｓ。したがって、スケジューラは、この
ストリームを拒絶し、上述したようにネゴシエートし始
める。

【００６３】ｉＤＳＰ-ＱｏＳＭは、アプリケーション
またはそれのプロクシとネゴシエートしてコデック・サ
イクルに基づいてメディア・オブジェクトのために十分
な処理帯域幅を予約する。このネゴシエーションは、オ
ブジェクトが必要とするメモリ，要求ＱｏＳレベルおよ
び他の同時に走っているＤＳＰアプリケーションを有す
るＤＳＰの利用可能なＭＩＰＳを考慮に入れる。オブジ
ェクト選択が変化すると、ＱｏＳマネージャはＤＳＰプ
ロセッサ帯域幅の再ネゴシエーションを行う。ＱｏＳマ
ネージャのネゴシエーション・プロセスへの入力パラメ
ータは、アプリケーションにオブジェクトのために以下
のことを定義するように要求する。 （１）ＤＳＰメモリ要件（入力／出力バッファの数およ
びサイズ）。 （２）所望のＱｏＳレベル（通常は、フレーム／秒で表
わされる）。 （３）オブジェクトを開始する際の最悪ランタイム。 （４）コデック・サイクルと呼ばれるメディア・フレー
ムのシーケンス用のハード・リアル・タイム・デッドラ
インを有する（フレーム数および平均実行時間）。

【００６４】ｉＤＳＰ-ＱｏＳマネージャにおけるオブ
ジェクトの第２のフェーズ・スケジューリングは、２つ
の面（すなわち、どれのデッドラインが最初に来るか
と、どれが高い優先度を有するか）を基準とする。次の
例を検討する。オブジェクト-Ａが１０ｍｓでデッドラ
インを有し、かつ、オブジェクト-Ｄが３ｍｓでデッド
ラインを有するならば、ｉＤＳＰ ＱｏＳマネージャ
は、オブジェクト-Ａの方が優先度が高くても、オブジ
ェクト-Ｄを最初に走らせるようにスケジュールする。
オブジェクトのおおよそのランタイムを知っているの
で、オブジェクトが開始されるときに、なおもそれのデ
ッドラインを満たすように、「最終」時点（No later t
ime）を決定することができる。図３では、オブジェク
ト-Ａの「最終」開始時点よりも前にオブジェクト-Ｄが
終了すると予測される。この状況では、優先度が高い方
のオブジェクト-Ａおよびオブジェクト-Ｄの間にはデッ
ドライン・コンフリクトはない。したがって、オブジェ
クト-Ａは、優先度がより低いオブジェクト-Ｄの後に走
る。

【００６５】別のスケジューリングの例では、優先度が
最初のデッドラインよりも優先するのは、優先度が高い
方のオブジェクト-Ａの「最終」時点が予測されたオブ
ジェクト-Ｄの予測終了時刻よりも前である場合であ
る。この場合、オブジェクト-Ａは優先度が高いので最
初に走り、また、オブジェクト-Ｄがオブジェクト・イ
ンスタンス化時点において指定されたそれのフレーム欠
落パラメータを満たす場合にのみ、オブジェクト−Ｄは
後から走ることを許される。図４を参照。

【００６６】ｉＤＳＰ ＱｏＳがデッドラインを可能な
かぎり効率的に管理するためには、ＧＰＰは、できるだ
け早くＤＳＰサブシステムにデータ入力フレームを与
え、オブジェクトのために到達時刻とデッドラインとの
間で最大の時間量が許されるようにしなければならな
い。データ・フレームの到達とそれのデッドラインとの
間の時間が長い程、ｉＤＳＰ-ＱｏＳＭは、各オブジェ
クトの他の同時オブジェクトとのスケジューリングにお
いて一層の柔軟性を可能にする。

【００６７】３ｃ．オブジェクトのランタイム予測（ソ
フト・デッドライン） ｉＤＳＰ-ＱｏＳＭの中心的機能は、全てのスケジュー
ルされたオブジェクトの次の入力フレームに対する要求
処理時間を予測することである。この予測は、厄介であ
り、オブジェクトに一意である。ＱｏＳマネージャは、
以前のランタイムの統計を用いて次の入力フレームに対
する予測ランタイムを算出することによって、オブジェ
クトに対するランタイムを予測する。オブジェクトに対
する予期されたランタイムは、（各オブジェクトに対し
て一意に決定された）最大可能正変化との以前のランタ
イムの（オブジェクトに一意である）関数である。例え
ば、ビデオ・オブジェクトの場合には、Ｉ，ＰおよびＢ
フレームの周期性は決定論的である。したがって、今後
の処理時間は現フレームのタイプとビデオ・フレームの
周期内のそれのロケーションとに基づいて予測され得
る。全ての同時アルゴリズムに対して行われたそのよう
な予測は、予測された処理時間および近づきつつあるハ
ード・デッドラインに基づいて動的に優先度を割り当て
し直すのに直接に役に立つ。

【００６８】これらの予測は、ソフト・デッドラインと
処理時間におけるジッタとを管理するためのキー・イネ
ーブラ（key enabler）である。ｉＤＳＰ-ＱｏＳＭは、
予測に基づいて、処理のためにオブジェクトを瞬時に再
スケジュールする。この瞬間的な再スケジュールは、個
々のオブジェクトのコデック・サイクル・デッドライン
時間（平均的に定義されたハード・デッドライン）内で
行われる。この方法は、個々のフレームがハード・デッ
ドラインおよびソフト・デッドラインの双方に従って重
み付けされるという意味で、独特である。上述した例で
は、オブジェクト-Ａとの５００ｍｓ重複に対して作業
負荷の平均を取ったときに、オブジェクト-Ｂの全フレ
ームは同じ時間量を必要とすると仮定した。オブジェク
ト-Ｂのフレームは実際の重複の間よりも多くの時間を
必要とする場合もあり、また、オブジェクト-Ｂは平均
時間量が与えられない場合もあるので、これは真ではな
いかもしれない。したがって、それらのコデック・サイ
クル・デッドラインに最も近いフレームは、より高い優
先度を受ける。予測ランタイムがユーザ定義時間要件に
違反するならば、ＱｏＳマネージャは数個の可能なアク
ションの１つを取るであろう。

【００６９】単一ＤＳＰ構成では： （レベル１）単純バイナリ・カットオフ：これは自動フ
レーム欠落をもたらす。問題のオブジェクトは、フレー
ム欠落が破局的な結果を招くか否か示すことができなけ
ればならない。 （レベル２）割り当てられた時間の終了時におけるオブ
ジェクトのプリエンプション（pre-emption）による低
優先度オブジェクトの割当てランタイムの全体的な削
減。 （レベル３）オブジェクトは、出力データの品質低下
（scaling back）のようなＱｏＳコマンドを受け入れる
能力を有することを要求される。

【００７０】多数ＤＳＰ構成では： （１）各ＱｏＳタイム・スライスの終了時では、負荷デ
ータを有するメッセージが各ＤＳＰからＧＰＰに送られ
る。 （２）ＧＰＰは、推定されたデッドライン・ミスの場合
にのみオブジェクトの再分配に訴える。このタスクの再
割当ては、サービスしているＤＳＰから「負荷データ」
を受信した後にＧＰＰ（ＯＲＢレイヤー）によって実行
される。しかしながら、タスク切換え時間を減少するた
めには、全てのＤＳＰが外部メモリ空間の共通クラスタ
から動作することが非常に望ましい。

【００７１】ｉＤＳＰシステムで実行する全オブジェク
トは、実行時間で決定論的でなければならない。ＤＳＰ
オブジェクトは、３つのタイプ（データの圧縮（エンコ
ード），データの伸長（デコード）およびデータ変換
（オブジェクト用のデータの前または後処理））に分解
することができる。オブジェクトは、処理するデータが
ブロック単位で提示され、これらのブロックは入力デー
タ・フレームと呼ばれる。オブジェクトは、入力データ
・フレームを処理するとともに、出力データ・フレーム
を発生する。いずれの計算データの場合でも、入力デー
タ・フレームおよび出力データ・フレームの双方はサイ
ズおよび処理量に関して制限されている。任意の所与の
入力フレームのサイズに基づいて、ＤＳＰまたはその件
のための他の任意のコンピュータが当該入力フレーム上
で実行しなければならない最大処理量を正確に決定する
ことができる。

【００７２】各オブジェクトは、それがｉＤＳＰシステ
ムに統合される前に、単一フレームに対する当該オブジ
ェクト用の最悪ラン・タイムを宣言するように要求され
る。この最悪ラン・タイムは、オブジェクトが開始され
得るように最初の入力データ・フレームのラン・タイム
を計算するのに用いられる。ＱｏＳマネージャは、オブ
ジェクトを走らせる前に入力データ・フレームを特徴付
けることができない。エンコード・オブジェクトおよび
デコーダ・オブジェクトは稀に最悪の状況で走ることが
あるので、最初の入力フレームはコストがかかる（何故
なら、最悪の場合であると予測されなければならないか
らである）。この最悪スケジュールは、最初のフレーム
の実際のランタイムよりも大きい場合が多い。これは、
実際のランタイムが最悪スケジュールよりも大きい場合
にのみ、問題となる。

【００７３】先に述べたように、アルゴリズム・オブジ
ェクトの処理時間は入力フレーム間で変動する。開始時
には、ｉＤＳＰ-ＱｏＳＭは最初のデータ入力フレーム
に対して最悪の値で開始する。最初のフレームの後に、
ＱｏＳマネージャは、アルゴリズムの特性および最初の
フレームについての測定処理時間に基づいて次の入力フ
レームに対する処理時間を予測する。各後続フレームに
ついては、それはアルゴリズム・オブジェクトのセマン
ティックス（semantics）および履歴に基づいておおよ
その処理時間を予測する。例えば、エンコーダ・オブジ
ェクトは、オブジェクト・セマンティックス（例えば、
Ｉ，ＰおよびＢフレーム・タイプ）を直前の同様の入力
フレームの平均エンコード時間と共に用いて今後のエン
コード時間要件を予測する。エンコーダ・オブジェクト
は、それらが実行のためにスケジュールされる毎に、同
じサイズの入力フレーム上で動作する。処理時間の変動
は、フレームにおけるアクティビティ・レベルおよびフ
レーム間の動き度合などというような要因によって生ず
る。しかしながら、これらの変動は制限される。したが
って、２つのフレーム間の処理時間は、予測処理時間に
加算されて次のフレームに対する最悪処理時間を決定す
ることができる有限最大差を有する。図５および図６を
参照。

【００７４】デコード・オブジェクトは、通常、可変サ
イズの入力フレームを提示される。入力データ・フレー
ムの処理時間はそれのサイズに直接に比例する。次のフ
レーム処理時間に増大があるか否かを判定するために、
ＱｏＳマネージャは現データ入力フレーム・サイズと次
のデータ入力フレーム・サイズとの差の大きさをチェッ
クする。エンコーダの場合のように、同様の引数がデコ
ーダにも保持される。すなわち、２つの意味的に同様の
フレーム間の処理における差が制限される。デコーダに
対する最大すなわち最悪の処理時間は、オブジェクトに
対して定義された最大可能バッファである。図７を参
照。

【００７５】変換オブジェクトは、同じサイズの入力バ
ッファ上で常に動作するという点で、エンコーダ・オブ
ジェクトと同様に走る。各フレームは、同じ処理時間量
が常にかかり、また、入力フレームを通過する単一パス
である。したがって、入力フレーム当たりの処理時間は
常に一定のままである。

【００７６】各オブジェクトは、受け渡されたフレーム
がオブジェクトによって完成されなければならない相対
時間をユーザ・アプリケーションから受け取る。一例
は、このフレームが次の７ｍＳ以内に処理されなければ
ならないとアプリケーションが指定することである。ホ
ストＧＰＰとＤＳＰとの間には共通ソフトウエア・クロ
ックがないので、デッドラインは相対的にしか指定され
ることができない。ホストとＤＳＰとの間のデータ・フ
レームのトランスポート時間は決定論的であると仮定す
る。ｉＤＳＰシステムは内部クロックを維持し、内部ク
ロック対して、データ・フレームは到達時にタイムスタ
ンプを受け取ったのちに予期処理時間を算出する。予期
処理時間を計算した後に、ＱｏＳマネージャはデータ・
フレーム実行をスケジュールする。

【００７７】オブジェクトがスケジュールされる前に、
ＱｏＳマネージャは、他の同時オブジェクトと比較し
て、オブジェクトの実行の適切な順序を決定する。他に
入力フレームを処理するオブジェクトがないならば、オ
ブジェクト・フレームは実行のために直ちにスケジュー
ルされる。他に走っているオブジェクトがあるならば、
ＱｏＳマネージャは、各要求オブジェクトの優先度，予
期デッドラインおよびハードまたはソフト・リアルタイ
ム要件を考慮することによって実行順序を決定する。図
８を参照。

【００７８】ランタイム特性が異なる多数のオブジェク
トが同じＤＳＰ上に結合されるとき、ＱｏＳマネージャ
は、オブジェクトの特定のランタイム算出に基づいて各
オブジェクトについてランタイム予測を計算する。次い
で、それはスケジューリング・オブジェクト（ＴＢＤ）
に基づいて異なるタスクをスケジュールする。以下の３
つのスケジューリング状況が可能である。

【００７９】（１）全てのオブジェクトは、与えられた
入力データ・フレーム上で完了まで走るとともに、アプ
リケーション指定デッドライン内に完了する。この状況
は図９に提示されている。図の全てのオブジェクトは各
オブジェクト・デッドラインの前に完了していることに
注目すること。全てのオブジェクトがそれらの各デッド
ラインよりも前に完了するならば、ＱｏＳマネージャの
要求された作業は最小である。

【００８０】（２）処理負荷は１つ以上のオブジェクト
（例えば、オブジェクト-Ｂ）上で増大するが、これは
後続オブジェクトに対する予測デッドラインを看過する
ことにはならない。負荷がオブジェクト-Ｂにおけるよ
うに１つ以上のオブジェクト上で増大することができ
る。オブジェクトによっては、同じオブジェクトの後続
データ・フレームがそれらのデッドライン制約内で処理
されるならば、デッドラインの看過は容認できるかもし
れない。一例は、“Ｉ”フレームが計算に最も時間がか
かるＨ２６４エンコーダにおける場合であろう。“Ｉ”
フレームに続くフレームは、常に“Ｐ”フレームであ
り、遥かに少ない処理要件を典型的には有する。これ
は、“Ｉ”フレームの処理が次のＰフレームの処理から
サイクルを盗むことを可能にする。したがって、１つの
フレーム上でデッドラインを看過しても、次のフレーム
上に十分な処理余裕があれば、破局的にはならないかも
しれない。オブジェクト-Ｂに対するデッドラインを超
過したので、全体的なシステム効果が判断されなければ
ならない。オブジェクト-Ｂによるデッドラインの看過
が次のオブジェクトに対する予測デッドラインを看過す
ることにはならないならば、全体的なシステム被害は最
小である。図１０および図１１を参照。

【００８１】（３）処理負荷は１つ以上のオブジェクト
（例えば、オブジェクト-Ｂ）上で増大するが、これが
次のオブジェクトに対する予測デッドラインを看過させ
ることになる。図１２を参照。この場合には、オブジェ
クト-Ｂによるデッドラインの看過は次のオブジェクト
に対する予測デッドラインを看過させる。この場合で
も、全体的なシステム被害は最小であるかもしれず最小
でないかもしれない。同時に走っているオブジェクトの
各々は、後続のフレームからサイクルを盗むことができ
る、したがって、デッドライン看過のドミノ効果を回避
することができるかもしれない。

【００８２】ｉＤＳＰ-ＱｏＳＭはソフトウエア・デッ
ドライン管理のために一組の規則を提案する。この一組
の規則は、１つの重要なデッドライン看過に端を発する
デッドライン看過の雪だるま現象を制限するように設計
される。（１）あらゆるアルゴリズム・オブジェクト
は、許された秒単位の最大フレーム欠落数をＱｏＳマネ
ージャに与える。（２）各オブジェクトは、各処理サイ
クルの後に移動平均として「看過デッドライン」の数の
ランニング・カウントを更新する。（３）オブジェクト
がそれの看過デッドライン限界を越えたとき、オブジェ
クトの優先度を最高値に変更する。元の優先度は、一度
でも数が限界未満に低下すると、復元される。（４）限
界後にそれらのデッドラインを看過した全ての後続フレ
ームは欠落される。これは、次の直接レベルへのＱｏＳ
の一時的低下をもたらす。次に、（極く稀でなければな
らない）このＱｏＳの瞬時的落下がクライアントに報告
される。（５）ＤＳＰがそれのデッドラインの超過の後
でも問題のオブジェクトを開始させない場合にのみ、フ
レームは規則として欠落される。

【００８３】３ｄ．周期的メディア・レンダリングに対
するスロットル制御 所与のアルゴリズム・オブジェクトに対して、ｉＤＳＰ
-ＱｏＳＭは、任意の時点ではレディ・キューに１つの
みだけの要求があると仮定している。一般に、メディア
・ストリームには、ＱｏＳマネージャに対するサービス
品質制約として特定された周期的デッドライン（例え
ば、ビデオ・ストリームについては３０フレーム／秒）
を有する。メディア・ストリームにおけるオーディオお
よびビデオ・レンダリング・コンポーネントは、到達時
刻の分散を取り扱うためにフレームをバッファすること
ができ、フレームがスケジュールより多少早く到達する
ことを可能にする。しかし、これらのバッファは有限で
あり、したがって、メディア・システムの上流コンポー
ネントは、フレームが処理される相対的速度を注意深く
調節しなければならない。

【００８４】２つの機構が、アルゴリズム・オブジェク
トの処理速度を調節するために、ｉＤＳＰ-ＱｏＳＭに
よって用意されている。 （１）ＤＳＰアルゴリズム・オブジェクトのクライアン
トは、それがアルゴリズム・オブジェクトの処理関数
（サーバ）を呼び出す速度を制御する。これは、それら
が満たされなければならない時間期間内に要求が行われ
るならば、ＱｏＳマネージャのスケジューリング・アル
ゴリズムの準最適作用（sub-optimal behavior）をもた
らす。例えば、バッファＡ１が時間期間Ｔ１内に処理さ
れなければならず、かつ、バッファＡ２が時間期間Ｔ２
内に処理されなければならない上述したアルゴリズム・
オブジェクトＡについて検討する。図。ここでは、Ｔ１
およびＴ２は２つの連続する期間であり、［ｘ］はバッ
ファｘの到達を示し、{ｘ}はバッファｘの処理の完了を
示す。図１３ａを参照。

【００８５】（２）ＱｏＳマネージャはメディア・スト
リームの調節（throttling）を制御する。この機構は、
クライアントができるだけ早く入力バッファを用いてア
ルゴリズム・オブジェクトの処理関数を呼び出すことを
可能とする。次に、ＱｏＳマネージャは「開始−デッド
ライン」を入力バッファに添付する。スケジューラは
「開始デッドライン」の後までこのバッファをスケジュ
ールしない。クライアントは、それの現バッファの処理
が完了されるまで停止する。図１３ｂを参照。

【００８６】このように、両方の場合において、ＱｏＳ
マネージャ・レディ・キューにはいずれの時点において
もアルゴリズム・オブジェクト当たりの要求はせいぜい
１つである。

【００８７】４．メモリ・ページング ＤＳＰまたは当該事項用の任意のプロセッサ上で多数の
アルゴリズムを最良に走らせるためには、システム・リ
ソースがアルゴリズム間で公平に共有されるように一組
の規則が制定されなければならない。これらの規則は、
ＤＭＡ，内部メモリおよびアルゴリズム用スケジューリ
ング方法のようなプロセッサの周辺へのアクセスを指定
する。一旦一組の規則が受け入れられると、システム・
インターフェースがアルゴリズム用に開発されて、それ
らがシステム・リソースにアクセスできるようにプラグ
・インすることができる。共通のシステム・インターフ
ェースは、アルゴリズム開発者に、アルゴリズムをより
早く開発するのに明確な境界を与える。何故なら、彼ら
はシステム対応問題ではなくアルゴリズムの開発のみに
集中できるからである。そのようなインターフェースの
一例はテキサス・インスツルメンツ社のiDSP Media Pla
tform DSPフレームワークである。アルゴリズムとTMS32
0C62XX ＤＳＰとの間の全アクセスはこのフレームワー
クを介して行われる。

【００８８】テキサス・インスツルメンツ社のＸＤＡＩ
Ｓ規格要件は、１つよりも多いアルゴリズムをｉＤＳＰ
メディア・プラットフォームにプラグ・インすることを
可能にし、システム構築者が１つ以上のアルゴリズムか
ら素早く生産品質システムを組み上げることを可能にす
る。ＸＤＡＩＳ規格は、アルゴリズムがＡｌｇインター
フェースと呼ばれる共通のインターフェース要件を満た
すことを要求する。ＸＤＡＩＳ規格によって課される規
則はいくつかあるが、アルゴリズムがメモリを直接に定
義したりハードウエア周辺に直接にアクセスすることが
できないことが最も重要である。システム・サービス
は、全アルゴリズム用の単一の共通インターフェースを
介して与えられる。したがって、システム構築者は、全
アルゴリズムに対してＡｌｇインターフェースをサポー
トするＤＳＰフレームワークを設けるだけでよい。Ａｌ
ｇインターフェースは、システム・サービスにアクセス
するとともにそれらのアルゴリズムを呼び出す手段もア
ルゴリズム開発者に提供する。

【００８９】アルゴリズムはそれの内部メモリ要件を正
確に定義しなければならない。これは、ページング・ア
ーキテクチャが内部メモリ内の同じ空間にアクセスする
マルチ・アルゴリズムをサポートするのに必要である。
ＸＤＡＩＳ準拠アルゴリズムは、それらの内部および外
部メモリ要件を指定するように要求される。

【００９０】内部（オンチップ）メモリは２つのエリア
に分割されなければならない。第１のエリアはシステム
・オーバーヘッド・エリアであり、これは特定のＤＳＰ
システム・コンフィギュレーション用のＯＳデータ構造
に対してサポートする。第２のエリアは、アルゴリズム
が使用するためであるが、それらが実行するようにスケ
ジュールされているときだけである。双方のメモリ・エ
リアはサイズを固定されなければならない。この第２の
メモリ・エリアはアルゴリズム・オンチップ・ワークス
ペースと呼ばれ、言い換えると、このワークスペースは
データ・オーバーレイまたはデータ・メモリ・ページと
して記述されることもできる。図１４を参照。

【００９１】どれだけのメモリがアルゴリズム・オンチ
ップ・ワークスペースのために使用可能であるかを判定
するために、システム開発者は、使用可能な内部データ
・メモリ空間の総量を把握するとともに、ページング・
アーキテクチャ用のＯＳサポートおよびデータサポート
のようなシステム・ソフトウエアをサポートするのに必
要な量を差し引く。タスク，セマファー（semaphore）
などのようなＯＳコンフィギュレーションは、システム
ＤＳＰ設計者が一度に同時に走らせたいアルゴリズムの
総数をサポートする最大サイズにその設計者によって設
定されなければならない。これは、ＯＳサポート・オー
バーヘッドを最小に抑えるとともに、アルゴリズム・ワ
ークスペースを増加する。

【００９２】アルゴリズムがこの環境で走るためには、
それの内部メモリ要件はワークスペースのサイズ未満で
なければならない。そうでないと、システム構築者はア
ルゴリズムを統合することができず、アルゴリズム当た
り１ページしかないという制限が生ずる。このアーキテ
クチャはアルゴリズムについて多数のページをサポート
しない。

【００９３】アルゴリズム・ワークスペースは３つのコ
ンポーネント（スタック（必須）と永続メモリと非永続
メモリ）に分割される。場合によっては、永続メモリの
読取りのみの部分を扱う後述する第４のコンポーネント
がある。図１５を参照。

【００９４】アルゴリズムは、それが実行している間
は、オンチップ・ワークスペースを使用するのみであ
る。アルゴリズムが実行するようにスケジュールされて
いるときは、ＤＳＰシステム・ソフトウエアは、アルゴ
リズムのワークスペースをそれの外部記憶ロケーション
（シャドー・ストレージ）からオンチップ内部ワークス
ペースに移す。アルゴリズムが制御を行うときは、ＤＳ
Ｐシステム・ソフトウエアはどのアルゴリズムを次に走
らせるかを決定し、それが同じアルゴリズムであるなら
ば、ワークスペースの移動は不要である。次のアルゴリ
ズムが異なるアルゴリズムであるならば、現ワークスペ
ースはそれの外部メモリのシャドー・ロケーションに格
納され、また、次のアルゴリズムのワークスペースが移
される。図１６を参照。

【００９５】あるアルゴリズムのワークスペース全体
は、コンテクスト・スイッチ時には移されない。スタッ
クおよび永続データ・メモリの使用された部分のみが移
される。アルゴリズムがそれのコール・スタックでそれ
の最高レベルにあるときは、アルゴリズムのスタックは
それの最高レベルである（使用頻度が最も低い）。言い
換えると、アルゴリズムはそれのエントリ点にある。ア
ルゴリズムに対する理想的なコンテクスト・スイッチ
は、それのスタックがそれの最高レベルにあるときに行
われる。何故なら、それは、オフチップのシャドー・ス
トレージに転送するデータが少ないことを意味するから
である。図１７を参照。

【００９６】好適な実施形態のデータ・ページ・アーキ
テクチャは、コンテクスト・スイッチが最も効率的であ
ることを要求する。コンテクスト・スイッチ処理オーバ
ーヘッドは、ＤＳＰがアルゴリズムを実行することがで
きる時間の効果を減じる。アルゴリズムをコンテクスト
・スイッチする最良の時点はそれのコール境界上である
ので、アルゴリズムのプリエンプティングは絶対的に最
小化されなければならない。アルゴリズムのプリエンプ
ティングは、それのスタックがそれの最小値よりも大き
いとき、システム全体の能力低下を招く。これは要件で
なければならないが、非常に制限されたベースでプリエ
ンプトすることは容認できるかもしれない。図１８およ
び図１９を参照。

【００９７】アルゴリズム・ワークスペースの特殊ケー
スは、アルゴリズムが読取りのみの永続メモリを必要と
する場合である。この種のメモリはアルゴリズムによっ
て用られる参照テーブルのために用いられる。このメモ
リは決して変更されないので、読取りができさえすれば
よく、書込みを行う必要はない。この非対称的ページ転
送は、アルゴリズムのコンテクスト・スイッチでオーバ
ーヘッドを低減する。

【００９８】このデータ・ページング・アーキテクチャ
によって、単一のアルゴリズムは１回よりも多くインス
タンス化され得る。アルゴリズムは内部メモリ要件に対
するそれの必要性を定義しているので、ＤＳＰシステム
構築者は同じアルゴリズムの１つより多いインスタンス
が可能である。ＤＳＰシステム・ソフトウエアは、多数
のインスタンスとアルゴリズムの各インスタンスをスケ
ジュールすべきときとに絶えず注意している。インスタ
ンス数の制限は、どれだけの外部メモリがアルゴリズム
・インスタンスのシャドー・バージョンを維持するため
にＤＳＰシステムにあるかである。

【００９９】ＤＳＰシステム・ソフトウエアは、アルゴ
リズムをスケジュールする際にアルゴリズム・データに
正確に一致されるように各インスタンスを管理しなけれ
ばならない。殆どのＤＳＰアルゴリズムはタスクとして
インスタンス化されるので、ＤＳＰシステム・ソフトウ
エアは、アルゴリズム・インスタンスを管理する手段と
してタスク環境ポインタを用いることができる。

【０１００】５．連鎖を持つデータ・フロー データ・フローの好適な実施形態は、処理エレメントを
統合化し、それらに共有メモリ空間を与え、ＧＰＰによ
る介入なしに処理エレメント間で直接にデータをルーテ
ィングすることに頼る。そのようなシステムが図２１に
示されている。

【０１０１】処理エレメントＰＥ_aがかなりの量のデー
タを処理し終えたとき、得られたデータを共有メモリ内
の既定の出力バッファに書き込む。次に、ＰＥ_aは連鎖
内の次の処理エレメントＰＥ_bに適切な制御パスを介し
て通知する。通知は、どの共有メモリ・バッファをＰＥ
_bが入力として使うかを示す。その後、ＰＥ_bは、次の処
理のために入力バッファからデータを読み出す。このよ
うに、データは、全てのデータが消費されるまで、要求
された全ての処理エレメント間で受け渡される。

【０１０２】上述した一組のバッファは、２つの処理エ
レメント間でデータを伝達するのに用いられるととも
に、これらのエレメント間にＩ／Ｏチャネルを備える。
多数のＩ／Ｏチャネルが任意の２つの処理エレメント間
に存在し、多数のデータ・ストリームがシステムによっ
て同時に（すなわち、並列に）処理されることを可能に
する。図２２は、多数のデータ・ストリームｓ１，ｓ２
の並列処理の一例を示す。

【０１０３】Ｉ／Ｏチャネルによって接続された一連の
処理エレメントはチャネル・チェーンを構成する。数個
のチャネル・チェーンが特定のシステム内部に規定され
得る。チェーン内処理エレメントの場合には、各入力チ
ャネルは関連する出力チャネルを有する。端末処理エレ
メントは入力チャネルまたは出力チャネルのみを有す
る。

【０１０４】処理エレメントの入力チャネルは、データ
が読み出されるべきバッファ（複数のバッファ）を規定
する。処理エレメントの出力チャネルは、データが書き
込まれるべきバッファ（複数のバッファ）と次に通知す
る処理エレメントとを規定する。データ処理エレメント
と中央制御プロセッサ（ＣＣＰ）との間の制御メッセー
ジの形式は、次の通りである。

【０１０５】（１）ステータス・メッセージ：データ・
ストリーム処理開始，停止，中断，休止，再開など。 （２）サービス品質メッセージ：タイム・スタンプ，シ
ステム負荷，リソース・フリー／ビジーなど。 （３）データ・ストリーム制御メッセージ：開始，停
止，休止，再開，巻き戻しなど。 （４）システム負荷メッセージ：タスク実行，アクティ
ブ・チャネルの数，処理エレメント毎のチャネルなど。

【０１０６】好適な一実施形態では、処理エレメントに
よるＩ／Ｏチャネルの作成および連携は、システム初期
化時点で読み取られ得るコンフィギュレーション・ファ
イルを介して静的に定義される。処理されるべき各ビッ
トストリーム・タイプについて、コンフィギュレーショ
ン・ファイルは、適切な処理エレメントを接続するチャ
ネル・チェーン（すなわち、データ・パス）を規定す
る。チャネル・チェーンにおける全ての処理エレメント
の一括処理はデータの完全消費をもたらす。

【０１０７】多数のデータ・パスが所与のビットストリ
ームに存在する場合には、代わりのチャネル・チェーン
またはバックアップ・チャネル・チェーンが定義され得
るであろう。一次チャネル・チェーンの任意の処理エレ
メントも使用できない場合には、ビットストリームはこ
れらにルーティングされ得る。ランタイムにおけるビッ
トストリーム・タイプの決定と動的ＱｏＳ分析とは、デ
ータがルーティングされるチャネル・チェーンを選択す
る。ランタイムでは、システム内の全ての正当なチャネ
ル・チェーンは固定され変更できない。

【０１０８】別の好適な実施形態では、新たなビットス
トリームが通信プロセッサに到達するときに、異なるビ
ットストリーム用のチャネル・チェーンは動的に構築さ
れ得る。ランタイムで得られるビットストリーム情報
は、必要な処理エレメントを決定するとともにそれらの
間でＩ／Ｏチェーンを動的に割り当てるＣＣＰに制御メ
ッセージ（複数の制御メッセージ）を介して送られる。
この手法は、リソースをサービスから外したり、ランタ
イムでオンラインに戻したりして、自動的にシステムを
適合化することを可能にする。

【０１０９】共有メモリ異種システムでは、データは、
ＣＣＰの介入を受けずに外部共有メモリを介して処理エ
レメント間に流れる。データは決してバス上に現れない
ので、データ・トランザクションの速度は、バス・トラ
ンスポート時間ではなく共有メモリ・アクセス時間によ
って決定される。ＣＣＰ介入も最小化されるので、ＣＣ
Ｐ応答および処理遅延は全体的なデータ・フロー時間か
ら除かれる。これは、処理エレメント間のデータ転送時
間を最小化することによってシステムのスループットを
向上させる。

【０１１０】５ａ．一例 ここに論じられたデータ・フロー技術の典型的な応用は
メディア処理システムに対するものであろう。そのよう
なシステムは、デコード，エンコード，変換（translat
ing），変換(converting)，スケーリングなどのような
処理のために広帯域メディアのストリームを開始し制御
する。ローカル・ディスクからまたは遠方の機械／サー
バから発するメディア・ストリームをケーブル・モデ
ム，ＤＳＬまたはワイヤレスのような通信媒体を介して
処理することができる。図２３は、そのようなシステム
の一例を示す。

【０１１１】図２３のメディア処理システムは５つの処
理エレメントを含む。 （１）ＤＳＬまたはケーブル・モデムＩ／Ｏフロント・
エンドＤＳＰ （２）メディア処理ＤＳＰ （３）ビデオ／グラフィクス・オーバーレイ・プロセッ
サ （４）Ｈ．２６３デコーダ・タスク （５）カラー空間変換タスク

【０１１２】フロント・エンドＩ／Ｏ ＤＳＰから入る
Ｈ．２６３ストリームは、付番された円弧１〜３によっ
て規定されるチャネル・チェーンを辿る。各チャネル
は、２つの処理エレメントを接続するとともに、エレメ
ント間でデータを受け渡すのに用いられる一組のＩ／Ｏ
バッファからなる。チャネル・フローは、影を付けた円
弧で示されている。

【０１１３】Ｈ．２６３ストリームは、グローバル共有
メモリ内に規定されたチャネル１Ｉ／ＯバッファにＩ／
Ｏフロント・エンドＤＳＰから流入する。Ｉ／Ｏフロン
ト・エンドＤＳＰは、チャネル１と関連する宛先処理エ
レメント（すなわち、メディア処理ＤＳＰ上のＨ．２６
３デコーダ・タスク）に、それの入力バッファが満杯で
あり読み出される準備ができていることを知らせる。
Ｈ．２６３デコーダ・タスクは、チャネル１Ｉ／Ｏバッ
ファから読み出し、データをデコードし、得られたＹＵ
Ｖデータをローカル共有メモリ内のチャネル２Ｉ／Ｏバ
ッファに書き込む。

【０１１４】チャネルはプロセッサ間またはプロセッサ
内であり得ることに留意願いたい。データは、グローバ
ル共有メモリ（プロセッサ間）を介してか所与のプロセ
ッサに「ローカルな」共有メモリ（プロセッサ内）を介
してプロセッサ間を通過することができる。図４では、
チャネル１およびチャネル３はプロセッサ間であり、チ
ャネル２はプロセッサ内である。

【０１１５】６．変更 好適な実施形態は、その特徴を保持しつつ種々の方法で
変更され得る。

【０１１６】関連出願 本願は、全て２０００年４月２６日に出願された米国仮
出願番号第６０／１９９，７５３号，第６０／１９９，
７５５号，第６０／１９９，９１７号および第６０／１
９９，７５４号の優先権を主張する。

【図面の簡単な説明】

【図１】好適な実施形態のＤＳＰＯＲＢアーキテクチャ
を示す図である。

【図２】ＩＤＬコンパイルを示す図である。

【図３】ＱｏＳのタイミング図である。

【図４】ＱｏＳのタイミング図である。

【図５】ＱｏＳのタイミング図である。

【図６】ＱｏＳのタイミング図である。

【図７】ＱｏＳのタイミング図である。

【図８】ＱｏＳのタイミング図である。

【図９】ＱｏＳのタイミング図である。

【図１０】ＱｏＳのタイミング図である。

【図１１】ＱｏＳのタイミング図である。

【図１２】ＱｏＳのタイミング図である。

【図１３ａ】ＱｏＳのタイミング図である。

【図１３ｂ】ＱｏＳのタイミング図である。

【図１４】好適な実施形態のメモリ分析を示す図であ
る。

【図１５】好適な実施形態のメモリ分析を示す図であ
る。

【図１６】好適な実施形態のメモリ分析を示す図であ
る。

【図１７】好適な実施形態のメモリ分析を示す図であ
る。

【図１８】好適な実施形態のメモリ分析を示す図であ
る。

【図１９】好適な実施形態のメモリ分析を示す図であ
る。

【図２０】異種システムにおける公知のデータ・フロー
を示す図である。

【図２１】好適な実施形態のデータ・フローを示す図で
ある。

【図２２】好適な実施形態のデータ・フローを示す図で
ある。

【図２３】好適な実施形態のデータ・フローを示す図で
ある。

【図２４】ＣＯＲＢＡを示す図である。

【図２５】ＣＯＲＢＡを示す図である。

【図２６ａ】ＣＯＲＢＡを示す図である。

【図２６ｂ】ＣＯＲＢＡを示す図である。

【図２６ｃ】ＣＯＲＢＡを示す図である。

【図２７】ＣＯＲＢＡを示す図である。

フロントページの続き (72)発明者 アジャイ ナラヤン アメリカ合衆国 テキサス、リチャードソ ン、ウオータービュー パークウェイ 2700、アパートメント ナンバー 4538 (72)発明者 ラジコ ミロバノビック アメリカ合衆国 テキサス、プラノ、パス フィンダー トレイル 5824 (72)発明者 ジェームズ エム、オーバーターフ アメリカ合衆国 テキサス、ダラス、ダラ ス パークウェイ 14500、アパートメン ト 166 (72)発明者 シャイラー ティ、パットン アメリカ合衆国 テキサス、キャロルト ン、ランズ エンド ドライブ 2524 (72)発明者 フィリップ アール、スリフト アメリカ合衆国 テキサス、ダラス、チャ ーチル ウェイ 7900、ナンバー 2304 Ｆターム(参考） 5B045 GG01 GG06 5B098 AA10 GA04 GC01 GC16 GD02 GD14

Claims (7)

【特許請求の範囲】
1. 【請求項１】 クライアント−サーバ・スケジューリン
   グ方法であって、（ａ）クライアント上でスケジューリ
   ングを行って前記クライアントに結合されたサーバ用の
   タスクに対してリアルタイム・デッドラインを設定する
   第１のフェーズと、（ｂ）前記サーバ上で前記タスクの
   サブタスクのスケジューリングを行う第２のフェーズで
   あって、ステップ（ａ）の前記リアルタイム・デッドラ
   インを用いてスケジューリングを行う第２のフェーズ
   と、 を含む、クライアント−サーバ・スケジューリング方
   法。
2. 【請求項２】 （ａ）前記タスクが、メディア・ストリ
   ーム・デコードを含み、（ｂ）前記サブタスクが、前記
   メディア・ストリームのフレームに対するフレーム・デ
   コードを含む、 請求項１記載のスケジューリング方法。
3. 【請求項３】 クライアント−サーバ・システム用のオ
   ブジェクト要求ブローカ方法であって、（ａ）第１のク
   ライアント要求リターンおよび第２のクライアント要求
   コールを崩壊させるステップと、（ｂ）第１のサーバ・
   オブジェクトの出力を第２のサーバ・オブジェクトの入
   力に連鎖するステップであって、前記第１のサーバ・オ
   ブジェクトおよび前記第２のサーバ・オブジェクトが第
   １および第２のクライアント要求にそれぞれ対応する、
   ステップと、 を含む、クライアント−サーバ・システム用のオブジェ
   クト要求ブローカ方法。
4. 【請求項４】 （ａ）前記連鎖が、前記サーバにおける
   中間結果（前記第１のオブジェクトの出力および前記第
   ２のオブジェクトに対する入力）用のバッファの作成に
   よるものである、請求項３記載の方法。
5. 【請求項５】 クライアント−サーバ・システムにおけ
   るサーバ・プロセッサ・メモリ管理の方法であって、
   （ａ）プロセッサ・メモリの第１の部分をプロセッサ・
   オーバーヘッドに割り当てるステップと、（ｂ）前記プ
   ロセッサ・メモリの第２の部分をタスク・ワークスペー
   スに割り当てるステップであって、前記第２の部分があ
   る時点でたった１つのタスクによって占有され得る、ス
   テップと、 を含む、方法。
6. 【請求項６】 （ａ）前記メモリの第２の部分が、スタ
   ック・コンポーネント，永続メモリ・コンポーネントお
   よび非永続メモリ・コンポーネントを含む、請求項５記
   載の方法。
7. 【請求項７】 制御プロセッサと複数の処理エレメント
   の各々とに接続されたバスを有する異種システムにおけ
   るデータ・フローの方法であって、（ａ）前記バスとは
   別個の共通メモリの使用により前記処理エレメント間で
   データを転送するステップ、 を含む、方法。