JP3501313B2 - ディジタル信号プロセッサに関するタスク管理システム及び方法 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、改良されたデータ処理
システムに関し、具体的には、複数のディジタル信号プ
ロセッサ上で実行中のタスクの実行を管理するための方
法およびシステムに関する。

【０００２】

【従来の技術】ディジタル信号プロセッサ（DSP）は、P
C産業で、たとえばデータ圧縮、伸長（解凍（展
開））、電話、音声生成、および、ミキシングや音量制
御など他のオーディオ処理などのマルチメディア・リア
ルタイム要件に合致するための計算力を提供するのに使
用されてきた。ハードウェア構成は、通常は、DSP、命
令とデータのためのメモリ、および、DAC（ディジタル
・アナログ変換器）、ADC（アナログ・ディジタル変換
器）、MIDI（Musical Instrument Digital Interface）
および電話回線や電話機などの代表的な項目のためのポ
ートなどのハードウェア装置からなる。

【０００３】

【発明が解決しようとする課題】DSPタスク・スケジュ
ーリングと資源管理を処理するために作成されたプログ
ラムの１つが、米国カリフォルニア州Santa BarbaraのS
pectron Microsystems社製のSPOXである。OS/2と同様
に、SPOXは、下層のDSPハードウェアに対する高水準ソ
フトウェア・インターフェースを提供する。しかし、こ
れは、さまざまな単一DSPシステムのための共通インタ
ーフェースの作成を目的としている。そのインターフェ
ースは、同種の複数DSPではなく単一DSP（またはマスタ
／スレーブ関係のマスタDSP）を目標としているので、
負荷平衡化と資源管理への十分な対処が欠けている。

【０００４】VCOS（Visible Cache Operating Systemの
略）は、AT&T社が自社のDSP 3210ファミリーの部品のた
めに作成したマルチタスク方式の多重処理環境である。
VCOSは、ISPOSを用いて最も簡単に識別され、ホスト・
オペレーティング・システムのスレーブとなることを目
的としている。これは、ホストに緊密に組み込まれるの
ではないので、IBM社のDSPマネージャが提供するのと同
等の範囲の操作性は有しない。これは、IBM社のDSPマネ
ージャの特徴の一部を有するが、具体的には単一DSPサ
ブシステムを目標としている。全体として、Texas Inst
ruments(TI)社、Motorola社およびAT&T社からの既知のD
SPサポートは、ハードウェア装置に関する要件の大域管
理を提供しない。

【０００５】

【課題を解決するための手段】本発明は、マルチメディ
ア・オーディオ・ビデオ・サポートに関するIBM社のデ
ィジタル信号プロセッサ・プロジェクトに関する。現
在、ディジタル信号プロセッサ（DSP）を管理するソフ
トウェアは、１つのDSP上のハードウェア・デバイスを
サポートする。本発明は、ハードウェア資源をDSPマネ
ージャに集中化することによって、複数のDSP上の複数
のハードウェア・デバイスをサポートする。DSP自体を
含む各ハードウェア・デバイスは、ハードウェア・デバ
イス識別子にマッピングされる。各DSP上のすべてのデ
バイスは、導入可能BIOSデバイス・ドライバによってDS
Pマネージャに報告される。DSPマネージャは、複数のDS
P上のすべてのデバイスを収集し、数を数える。DSPタス
クをロードする際に、マネージャは、アプリケーション
によって指定されたデバイス識別子によって宛先を突き
止める。プログラム・アプリケーションに影響を及ぼさ
ずに複数のDSPをサポートするために、DSPマネージャを
設けて、ハードウェア資源を集中化し、どのDSP上のど
の特定のハードウェア・デバイスでも簡単にアクセスで
きるようにする。

【０００６】具体的に言うと、DSPマネージャは、処理
能力、データ処理システム内に置かれたさまざまなDSP
内の命令メモリ、データ・メモリなどの要因を考慮に入
れて、複数のDSPへタスクを効率的にロードするための
処理を提供する。DSPマネージャは、DSP上での他の機能
の実行に割り込まずに、選択された機能をロードしたり
除去する能力を提供する。

【０００７】

【実施例】ここで図面、具体的には図１を参照すると、
コンピュータ１５に電気的に接続された複数のマルチメ
ディア末端装置１３を含むマルチメディア・データ処理
システム１１が示されている。当業者は、仕様を参照す
れば、コンピュータ１５に、米国ニューヨーク州Armonk
のInternational Business Machines Corporation社製
造のPS/2 IBM Computerなど、従来技術で周知のパーソ
ナル・コンピュータ・システムが含まれることを了解す
るであろう。複数のマルチメディア末端装置１３には、
リアルタイム・データまたは非同期ストリーム化データ
を製作または消費するすべての種類のマルチメディア末
端装置が含まれ、CD-ROMプレイヤ１７、マイクロフォン
１９、キーボード２１、電話２３、ビデオ・モニタ２５
などの末端装置が制限なしに含まれる。マルチメディア
末端装置１３のそれぞれは、ストリーム化データを製作
または消費するために、マルチメディア・アプリケーシ
ョン・ソフトウェアによって呼び出される可能性があ
る。

【０００８】たとえば、CD-ROMプレイヤ１７の動作を、
コンピュータ１５に常駐しこれによって制御されるマル
チメディア・アプリケーション・ソフトウェアによって
制御することができる。CD-ROMプレイヤ１７の出力とし
て生成されたリアルタイム・ディジタル・データ・スト
リームを、コンピュータ１５によって、そこに常駐する
マルチメディア・アプリケーションの命令に従って受け
取り、処理することができる。たとえば、このリアルタ
イム・ディジタル・データ・ストリームを、従来のコン
ピュータ・フロッピー・ディスクへ格納するために圧縮
したり、通常の電話回線を介してモデム経由で遠隔地に
あるコンピュータ・システムに伝送し、このコンピュー
タ・システムでディジタル・ストリーム化データを解凍
（展開）し、アナログ・オーディオ機器で再生すること
ができる。その代わりに、CD-ROMプレイヤ１７からのリ
アルタイム・データ・ストリーム出力を、コンピュータ
１５によって受け取り、ディジタル・フィルタリング、
アナログ・フィルタリング、増幅、音声バランスをかけ
た後に、アナログ信号形式でアナログ・ステレオ・アン
プ２９に送り、オーディオ・スピーカ３１および３３に
出力することができる。

【０００９】マイクロフォン１９は、環境音に対応する
アナログ入力信号を受け取るのに使用できる。このリア
ルタイム・アナログ・データ・ストリームを、コンピュ
ータ１５に向け、ディジタル形式に変換し、マルチメデ
ィア・アプリケーション・ソフトウェアによる操作の対
象とすることができる。このディジタル・データは、記
憶、圧縮、暗号化、フィルタリング、変換、アナログ・
ステレオ・アンプ２９へのアナログ形式での出力、電話
２３へのアナログ形式での出力、電話回線への伝送のた
めのモデムの出力としてディジタル化アナログ形式での
提示、ビデオ・モニタ２５での表示用の視覚画像への変
換、または、さまざまな他の異なる従来のマルチメディ
ア・ディジタル信号処理動作の対象とすることができ
る。

【００１０】同様の形で、キーボード２１、電話２３お
よびビデオ・モニタ２５のアナログまたはディジタルの
入出力を、コンピュータ１５内の通常のマルチメディア
動作の対象とすることができる。

【００１１】本明細書に記載の発明的貢献から、既存の
マルチメディア・データ処理システムに対する多数の大
きな長所が明白である。本発明的貢献の１実施例は、
（１）無数のユーザ作成マルチメディア・アプリケーシ
ョンを許容する、オープン・アーキテクチャを提供し、
（２）末端装置のリアルタイム動作に干渉せずに、マル
チメディア末端装置の調整された動作または同時動作も
しくはその両方を可能にし、（３）モジュラー・マルチ
メディア・ソフトウェア・タスク間でのストリーム化デ
ータのリアルタイムまたは非同期の通信を可能にし、
（４）コンピュータとマルチメディア末端装置の間での
ストリーム化データのリアルタイムまたは非同期の通信
を可能にし、（５）マルチメディア・ハードウェア末端
装置の通常の機能を仮想化し、ソフトウェアで実行でき
るようにし、（６）マルチメディア・アプリケーション
・ソフトウェアの作成と動作を簡単にする、設計のモジ
ュール性を提供し、（７）他の実行中のマルチメディア
・タスクに割り込まずにマルチメディア・タスクの動的
再構成を可能にし、したがって、マルチメディア末端装
置の一時的なオーバーラップ動作を可能にするマルチメ
ディア・データ処理システムを提供する。

【００１２】図２は、本発明でマルチメディア末端装置
１３の動作を制御するマルチメディア・アプリケーショ
ンの実行に利用される主なハードウェア構成要素を示す
ブロック図である。マルチメディア・データ処理動作で
の通例どおり、中央処理装置（CPU）３３を、コンピュ
ータ１５内に設ける。通常、マルチメディア・アプリケ
ーション・ソフトウェアは、RAMコンピュータ・メモリ
３５内に常駐する。CPU３３は、マルチメディア・アプ
リケーションを構成する命令を実行する。また、マルチ
メディア・データ処理動作での通例どおり、ディジタル
信号プロセッサ３７が、補助プロセッサとして設けら
れ、これは、リアルタイム・データまたは非同期ストリ
ーム化データに対する動作の実行専用である。当業者に
は周知のとおり、ディジタル信号プロセッサとは、リア
ルタイム・データに基づく演算またはリアルタイム・デ
ータを含む演算の実行専用であり、したがって、マルチ
メディア末端装置のリアルタイム動作性を許容するよう
に超高速ですばやく応答するように設計されたマイクロ
プロセッサ・デバイスである。通常、ディジタル信号プ
ロセッサ３７の動作を高速化するために、通常の直接メ
モリ・アクセス（DMA）３９を設けて、データの高速な
取出と記憶を可能にする。本発明では、命令メモリ（I
M）４１とデータ・メモリ（DM）４３を別々に設けて、
ディジタル信号プロセッサ３７の動作をさらに高速化す
る。バス４５を設けて、ディジタル信号プロセッサ３７
とハードウェア・インターフェース４７の間でデータを
通信する。ハードウェア・インターフェース４７には、
ディジタル・アナログ変換器とアナログ・ディジタル変
換器が含まれる。さまざまなマルチメディア末端装置１
３の入出力は、ハードウェア・インターフェース４７の
ディジタル・アナログ（D/A）変換器とアナログ・ディ
ジタル（A/D）変換器を介して接続される。図２では、
例として、電話入出力４９、マイクロフォン入力５３、
ステレオ出力の左チャンネル５５および右チャンネル５
７が示され、これらは、ハードウェア・インターフェー
ス４７のA/D変換器またはD/A変換器を介して接続され
る。MIDI入出力もハードウェア・インターフェース４７
からディジタル信号プロセッサ３７に接続されるが、こ
れはA/D変換器やD/A変換器には接続されない。

【００１３】図３は、マルチメディア・ディジタル信号
処理動作の主なソフトウェア構成要素を示すブロック図
である。この図の上部は、CPU３３（図２）内で処理さ
れるソフトウェアを表し、この図の下部は、ディジタル
信号プロセッサ３７（図２）内で処理されるソフトウェ
ア７３を表す。図からわかるように、マルチメディア・
アプリケーション５９は、マルチメディア・アプリケー
ション・プログラミング・インターフェース（API）６
１を介して、電話応答機（TAM）ドライバ６３、サウン
ド・ドライバ６５、モデム・ドライバ６７および他のデ
ィジタル信号処理ドライバ６９などのデバイス・ドライ
バを経てDSPマネージャ７１と通信する。DSPマネージャ
７１は、複数のモジュラー・マルチメディア・ソフトウ
ェア・タスクのうちのどれでも要求でき、実行のためデ
ィジタル信号プロセッサ３７（図２）にロードすること
ができる。TAMタスク７５、サウンド・タスク７７およ
びモデム・タスク７９を含む、複数の代表的なモジュラ
ー・タスクを図３に示す。他のさまざまなディジタル信
号処理タスクは、「他のDSPタスク」と記されたブロッ
ク８１によって表される。これらのマルチメディア・ソ
フトウェア・タスクは、マルチメディア末端装置または
他のモジュラー・マルチメディア・ソフトウェア・タス
クによって消費または製作されるリアルタイム・データ
または非同期ストリーム化データに対して実行される、
実質的に削減できない動作を表す。マルチメディア・ソ
フトウェア・タスクは、ディジタル信号プロセッサによ
って実行可能な命令の組と、他のモジュラー・マルチメ
ディア・ソフトウェア・タスクまたはマルチメディア末
端装置によって作成されたか他のモジュラー・マルチメ
ディア・ソフトウェア・タスクまたはマルチメディア末
端装置によって消費されるリアルタイム・データ点また
は非同期データ点を表すデータ点の組とを表す。マルチ
メディア・アプリケーション５９は、複数のマルチメデ
ィア・モジュラー・ソフトウェア・タスクによって表さ
れる動作の実行を頻繁に要求する。この場合、タスク
は、１モジュール内に配置されるが、そのさまを図１０
に示す。

【００１４】複数のDSPを使用するデータ処理システム
のブロック図である図４を参照すると、複数の異なる通
信チャネルを使用して、DSPを相互接続し、DSP間の通信
を実現することができる。本発明の好ましい実施例によ
れば、DSP１、DSP２およびDSP３は、バス６８に接続さ
れる。バス６８は、バス・インターフェース・チップ
（BIC）７０に接続され、BIC７０は、PCホストの主バス
（すなわちマイクロチャネル）に接続される。「マイク
ロチャネル」は、International Business Machines Co
rporation社の登録商標である。BIC７０は、PCホストと
DSPハードウェアの間の通信を制御する。BIC７０とDSP
を接続するバス構成とに関する情報は、米国特許出願通
し番号第０８／１５５３１１号明細書等にある。

【００１５】図示の実施例には、DSP間の接続と通信を
もたらす「ローカル・バス」が図示されているが、「ロ
ーカル・バス」以外の多数の異なる種類の通信チャネル
を使用して、DSP間の通信を実現するためにDSPを相互接
続することができる。たとえば、共用メモリ・システム
を、大域共用メモリ構成または二重ポート式共用メモリ
構成で実施することができる。さらに、DSP間の通信
は、さまざまなDSP内の直列ポートを相互接続する直列
ポート配置を介して実現できる。たとえば、４個のDSP
を使用し、各DSPが少なくとも３つの直列ポートを含む
場合、４個のDSPのすべてを、直列ポートを介して互い
に相互接続することができる。

【００１６】DSPマネージャの大きな特徴が、装置独立
な形で複数DSPサポートを提供する能力である。この目
標は、DSP BIOSインターフェースの使用を介して達成さ
れる。図５のDSP BIOSインターフェース７０４を参照さ
れたい。このインターフェースは、ハードウェア固有の
情報をDSPマネージャ７１から隔離する。これによっ
て、他のアプリケーションに影響を与えずに、カードを
挿入するという簡単な処理によってハードウェアを含め
ることができるようになる。

【００１７】下記は、それぞれのDSP DBIOSxドライバを
介してDSPマネージャ７１によって管理される機能のリ
ストである。 ・BIOS_Read DSPのデータ・メモリまたは命令メモリから指定された
バッファにnワードを読み取る。 ・BIOS_Write DSPのデータ・メモリまたは命令メモリに指定されたバ
ッファからnワードを書き込む ・BIOS_Query_Info MIPs、メモリ・サイズ、ハードウェア・デバイスなどの
DSP情報を問い合わせる。 ・BIOS_Reset 指定されたDSPをリセットする。 ・BIOS_Halt 指定されたDSPをホールト（halt）する。 ・BIOS_SetIPC IPCルーチン・アドレスをセットする。 DSP BIOSデバイス・ドライバを導入するステップは、次
のとおりである。 １．デバイス・ドライバは、当初は名前"DBIOS00$"を含
む。 ２．初期設定中に、デバイス・ドライバは、デバイス・
ドライバ"DBIOS01$"にATTACHDDを発行する（図５のDBIO
Sxドライバ７００を参照されたい）。これが成功した場
合、そのデバイス・ドライバは、"DBIOS01$"を"DBIOS02
$"に変更し（図５のDBIOSxドライバ７０２を参照された
い）、同一の動作を実行する。このステップを、エラー
が発生するまで繰り返す。 ３．デバイス・ドライバは、"DBIOS00$"をエラーになっ
た番号、たとえば"DBIOS10$"に変更する。 ４．デバイス・ドライバは、直前のデバイス・ドライバ
のIDC入口点をセーブし、終了する。

【００１８】DSPマネージャが走行する時、その初期設
定コードは、エラーになるまで複数のDOSOPENを呼び出
すことによって、最後のDSP BIOSドライバを突き止め
る。その後、DSPマネージャは、最後のBIOSドライバにI
OCTLコマンドを発行し、最後のBIOSドライバは、同じコ
マンドを直前のデバイス・ドライバに発行し、このデバ
イス・ドライバが、同じ動作を行う。この処理の結果、
DSPマネージャは、導入されたすべてのBIOSドライバの
入口点のすべてを得る。

【００１９】DSPハードウェア表現 この実施例のために選択された抽象の水準は、デバイス
IDと称する数値を使用して、各ハードウェア・デバイス
を識別することである。デバイスIDは、下記の３２ビッ
ト・ワードである。ヒ゛ット (上位ワート゛) ヒ゛ット 3 1 1 6 TTDD DDDD DDDD DDDD T＝００、 入力デバイス ０１、 出力デバイス １０、 入出力デバイス D＝デバイス・タイプ ビット （下位ワード） ビット 1 0 5 0 NNNN NNNN NNNN NNNN N＝デバイス順序数 ０ − 省略時 １ − デバイス１ ２ − デバイス２ … など 現在定義されているハードウェア・デバイスIDは、下記
の通りである。 上位ワード（１６進） デバイス名 0001 ステレオ・ライン入力 8001 ステレオ・ライン出力 E006 電話回線 0006 電話機 0008 MIDI入力 8008 MIDI出力 E009 DSP E00A UART

【００２０】DSP BIOSドライバ導入の最後に、DSPマネ
ージャは、BIOS_Query_Infoコマンドを発行して、各DSP
の下記の資源情報を得る。 STRUCTURE /* DSP情報 */ USHORT DSP_MIPSs; /* DSP MIPs数 */ USHORT DSP_DataStore; /* KW単位のデータ記憶サイズ */ USHORT DSP_InstStore; /* KW単位の命令記憶サイズ */ USHORT DSP_Smart_Cable_ID; /* 0FFH:使用不能 */ USHORT DSP_Slot_Number; /* アダプタのスロット番号 */ USHORT DSP_Adapter_ID; /* アダプタID */ USHORT DSP_COM; /* 使用するCOMポート、ビット0 = 1 = COM1 */ /*ビット1 = 1 = COM2、など */ USHORT DSP_NumHWs /* ユニークなハードウェアの数 */ ULONG DSP_HWID[SDP_NumHWs]; /* カウントの代わりに使用される順序数 */ /* たとえば、0002 8001 = 2ステレオ出力ライン */ . . END USHORTは、符号なし短整数（１６ビット）を意味し、UL
ONGは、符号なし長整数（３２ビット）を意味する。

【００２１】その後、DSPマネージャは、スロット番号
に基づいてハードウェア・デバイスに番号をつける。た
とえば、スロット１のステレオ出力ラインには、STEREO
-OUT-1という番号をつけ、スロット２のステレオ出力ラ
インには、STEREO-OUT-2という番号を付け、この方式を
繰り返す。

【００２２】アプリケーションがDSPタスクをロードす
るためにDSPマネージャAPIを発行する時には、宛先を示
すためにハードウェア・デバイスIDも指定する。

【００２３】図５は、DSPマネージャ７１が、デバイス
識別子を使用してハードウェアから独立に複数のDSPデ
バイスを管理する方法を示す図である。

【００２４】DSPマネージャ７１は、DSP BIOSインター
フェース７０４を使用して、例の複数のDSPのDBIOSxド
ライバ７００および７０２を接続し、維持する能力を有
する。DSPマネージャ７１は、図５のDSP HW1ユニットお
よびDSP HW2ユニット（ハードウェア・ユニット７０
６）からなるハードウェア資源とソフトウェア資源を、
この実施例のデバイス識別子とDSP BIOSインターフェー
ス７０４を介して維持し、割り振り、割振り解除する。

【００２５】個々のDBIOSxドライバ７００および７０２
のそれぞれは、ハードウェア・ユニット７０６へのそれ
自体のインターフェース７０８および７１０を有する。
DSPBIOSインターフェース７０４は、DSPマネージャ７１
およびマルチメディア・アプリケーション５９を、Mwav
eハードウェアなどの異なるタイプのハードウェア・ユ
ニット７０６から「隔離」する共通インターフェースを
提供する。

【００２６】図６は、DSPマネージャ７１とDBIOSxドラ
イバ７００および７０２の間のDSP BIOSインターフェー
ス７０４の使用と、ハードウェア・ユニット７０６への
DSPタスクのロードを説明する論理流れ図である。

【００２７】BIOS_QUERY_INFO７１２コマンドを発行し
て、DSPに関する情報を見つける。DSP_INFO構造体に記
述されたこの情報は、下記の決定に使用される。 ・DSP_MIPS DSPの処理能力 ・DSP_DataStore 使用可能なデータ記憶容量 ・DSP_InstStore 使用可能な命令記憶容量 ・DSP_Slot_Number アダプタのスロット番号 ・DSP_Adapter_ID アダプタのタイプ ・DSP_COM 使用するCOMポート ・DSP-NumHWs ユニークなハードウェアの
数 ・DSP_HWID[DSP_NumHWs] 本発明で指定されるハード
ウェア・デバイスID

【００２８】BIOS_QUERY_INFO７１２から返された情報
を使用して、ブロック７１４で、DSPタスクをロードす
るのに十分な資源と適切なタイプの資源があるかどうか
の判定を行うことができる。ここで説明する処理は、DS
Pマネージャ７１とDBIOSxドライバ７００および７０２
の間の相互作用であることに留意されたい。また、DSP
マネージャ７１は、マルチメディア・アプリケーション
５９を、そのシステムに存在するハードウェア・ユニッ
ト７０６が何であり、DSPカードの枚数がいくつである
かという実際の低水準の選択から「隔離」することに留
意されたい。

【００２９】次のステップは、DSPタスクをロードする
位置に関して、次に使用可能な命令記憶アドレスとデー
タ記憶アドレスを見つけるためのBIOS_READコマンド７
１６の発行である。ステップ７１８で検査を行って、DS
Pコードをロードする位置が存在することを検証する。

【００３０】BIOS_WRITEコマンド７２０を複数回発行し
て、DSP用のデータ・メモリ４３および命令メモリ４１
にDSPタスクをロードすることができる。成功をステッ
プ７２２で検証する。これらの成功およびエラーのすべ
てが、ハードウェアおよびソフトウェアの資源能力の現
在の状態を維持するという本発明の技法のDSPマネージ
ャ７１の実施態様により、最終的にマルチメディア・ア
プリケーション５９に返されることに留意されたい。

【００３１】BIOS_SETIPC７２４を発行して、DBIOSxド
ライバ７００または７０２とDSPマネージャ７１の間の
割込みコールバック（IPC）アドレスをセットアップす
る。図５のDSP HW1およびDSP HW2のために使用できるDS
Pハードウェア・カードあたりの割込み「チャネル」の
数は有限なので、ステップ７２６でチャネルが使用可能
であるかどうかを検証する。

【００３２】最後に（任意指定）BIOS_READ７２８を行
って、ステップ７３０で、DSPマイクロコードの正しさ
を確認する。

【００３３】ステップ７３２とステップ７３４でのBIOS
_WRITEは、DSPタスクの走行を開始するために発行され
る。この時点で、タスクとマルチメディア・アプリケー
ション５９の間のすべての通信は、DBIOSxドライバ７０
０または７０２によって処理される割込みを介し、DSP
マネージャ７１に渡されるデバイス識別を介して行われ
る。

【００３４】図７は、DBIOSxドライバ７００または７０
２とDSPマネージャ７１の間の割込み処理の論理の流れ
を示す図である。

【００３５】この状況では、タスクが割り込まれてお
り、DBIOSxドライバが、BIOS_SETUPコマンドによって確
立された割込みハンドラにその割込み呼出しを渡してい
る。図７の流れの処理は、DSPマネージャ７１による割
込みの維持を示すものである。

【００３６】BIOS_READコマンド７３６をハードウェア
・ユニット７０６に発行して、ハードウェア割込みベク
トルを読み取る。ステップ７３８で検証を行って、割込
みをかけたタスクとハードウェアの組合せの所有権を判
定する。ステップ７３８での検証が確立されたならば、
BIOS_WRITEステップ７４０が発生し、コマンドを発行し
て、この特定のタスクとハードウェアの組合せに関する
割込みベクトルをクリアする（ステップ７４２）。

【００３７】ステップ７４４でタスクからBIOS_READを
発行して、割込みが発行された理由を判定する。ステッ
プ７４６で、この割込みがハードウェア障害のために発
行されたと示される場合、ステップ７４８のBIOS_HALT
とステップ７５０のBIOS_RESETを発行して、ディジタル
信号プロセッサ上のハードウェアを停止させ、リセット
しなければならない。

【００３８】ステップ７５２で、この割込みが正常なタ
スク維持のために発行された（すなわち、次のデータや
正常完了など）場合、ステップ７５４でBIOS_READを発
行して、タスクと資源の状態に関する情報を得る。ステ
ップ７５６で、１回以上のBIOS_Writeを発行して、正し
い動作のためにこのタスクにサービスする。

【００３９】図８は、本明細書に記載の、DSP BIOSドラ
イバ初期設定の流れ図と、デバイス識別を使用して複数
のDBIOSxドライバをシステムにロードする方法を示す図
である。

【００４０】DSPマネージャ７１は、初期設定の際にDBI
OS00$識別子から開始する。ドライバをロードしようと
する時に、DSPマネージャ７１は、ステップ７５８で識
別子をDBIOS01$（DBIOSxドライバ７００）にセットし、
ステップ７６０でこのドライバにATTACHDDを発行する。
このATTACHDDコマンドによって、ドライバの入口点がセ
ットされ、ドライバへの通信「経路」が確立される。AT
TACHに成功した場合、DBIOSxドライバが存在し、ステッ
プ７６２でXXを増分して、次のドライバに関してステッ
プ７６０のATTACHDDを再試行する。

【００４１】このループは、ステップ７６４でATTACHDD
が失敗するまで繰り返される。失敗の場合、ステップ７
６６で、前のXXをそのシステム内の新しいドライバのた
めにセーブする。この時点で、DSPマネージャ７１は、D
BIOSxドライバのそれぞれとの初期通信を有することに
留意されたい。

【００４２】図９を参照すると、たとえばDBIOSxドライ
バ７００および７０２などのドライバのすべてがステッ
プ７６０によって互いに成功裡に接続(ATTACH)されたな
らば、DSPマネージャ７１は、これらのドライバのアド
レスを登録する。これは、DSPマネージャ７１が、ブロ
ック７６８で最初のドライバから開始し、ステップ７７
０でドライバに対する連続的なオープンを発行すること
によって行われる。

【００４３】ステップ７７０でのオープンのそれぞれに
よって、たとえばDBIOSxドライバ７０２などのDBIOSxx
ドライバが、それ自体を初期設定する。ステップ７７０
でのドライバの連続的なオープンは、ステップ７７２で
ドライバの存在を確立する方法でもあることに留意され
たい。ステップ７７４で、xxレベルを増分する。

【００４４】すべてのドライバが初期設定されたなら
ば、ステップ７７６で最後にオープンされたドライバに
Query_IDCコマンドを発行して、DBIOSxドライバ７００
および７０２の間の照会のカスケード効果を引き起こ
し、ステップ７６０からのIDC入口点のすべての登録と
いう最終結果をもたらす。

【００４５】本明細書で述べるように、DSPマネージャ
７１とDBIOSxドライバ７００および７０２の間で発行さ
れる、ステップ７７０からのドライバに対するオープン
とステップ７６０でのATTACHDDのすべてが、構成要素間
でのBIOS通信リンクまたはDSP BIOSインターフェース７
０４を形成する。さらに、デバイス識別技法とハードウ
ェア資源識別技法を使用することによって、通信のすべ
てがマルチメディア・アプリケーション５９から透過的
になる。

【００４６】図１０は、N個のモジュラー・マルチメデ
ィア・ソフトウェア・タスク８５および１０３のグルー
プ化を表すモジュール８３からなるマルチメディア動作
を示すブロック図である。図からわかるように、タスク
１は、複数のコード・セグメント８７、８９、９１およ
び９３と、複数のデータ・セグメント９５、９７、９９
および１０１からなる。タスク１０３は、同様に、複数
のコード・セグメント１０５、１０７、１０９および１
１１と、複数のデータ・セグメント１１３、１１５、１
１７および１１９からなる。図２をもう一度参照する
と、タスク８５および１０３のコード・セグメントは、
命令メモリ４１に常駐し、タスク８５および１０３のデ
ータ・セグメントは、データ・メモリ４３に常駐する。
図２に視覚的に示されているように、マルチメディア末
端装置１３によって作成または消費されるリアルタイム
・データまたは非同期データは、バス１２１を介してデ
ータ・メモリ４３に直接読み書きすることができる。

【００４７】物理的な接続を、図１１に詳細に示す。図
１１は、図１に示されたマルチメディア末端装置１３と
図２に示された専用のデータ・メモリ４３の間でのリア
ルタイム・データまたは非同期ストリーム化データの直
接読み書きを示すブロック図である。図からわかるよう
に、電話入出力４９、マイクロフォン入力５３、MIDI端
子入出力５１およびステレオ出力の左チャンネル５５お
よび右チャンネル５７は、直列にまたは図２のハードウ
ェア・インターフェース４７内のさまざまなアナログ・
ディジタル（A/D）変換器およびディジタル・アナログ
（D/A）変換器とバス１２１とを介してデータ・メモリ
４３へ通信する。複数のデータ通信モジュール１３７を
データ・メモリ４３内に設けて、ディジタル信号プロセ
ッサ３７とマルチメディア末端装置１３の間でリアルタ
イム・データまたは非同期ストリーム化データを受け渡
しする。データ通信モジュールのそれぞれに、下で詳細
に説明する環状メモリ・バッファが含まれ、この環状メ
モリ・バッファに、電話入力環状バッファ１２３、電話
出力環状バッファ１２５、マイクロフォン入力環状バッ
ファ１２７、左チャンネル・ステレオ出力環状バッファ
１２９、右チャンネル・ステレオ出力環状バッファ１３
１、MIDI入力環状バッファ１３３およびMIDI出力環状バ
ッファ１３５が含まれることが好ましい。図１１からわ
かるように、電話入力４９、マイクロフォン入力５３お
よびMIDI端子入力５１からのストリーム化データは、通
常の直接メモリ・アクセス（DMA）動作の使用を介して
データ・メモリ４３に向けられる。

【００４８】図３をもう一度参照すると、複数のモジュ
ラー・マルチメディア・ソフトウェア・タスクが、ディ
ジタル信号処理BIOSに常駐するが、これには、直接メモ
リ・アクセス・インターフェース・タスク１３９、汎用
非同期送受信器（UART）インターフェース・タスク１４
１、アナログ変換インターフェース・タスク１４３およ
びCDディジタル・アナログ変換（CD-D/A）インターフェ
ース・タスク１４５が含まれる。TAMタスク７５、サウ
ンド・タスク７７、モデム・タスク７９および他のDSP
タスク８１などのマルチメディア・モジュラー・ソフト
ウェア・タスクは、データ・メモリ４３と複数のマルチ
メディア末端装置１３の間でのリアルタイム・データま
たは非同期ストリーム・データの読み書きのために提供
されるものなどのデータ通信モジュールの使用を介し
て、お互いの間およびディジタル信号処理BIOSと、リア
ルタイム・データまたは非同期ストリーム化データを通
信する。

【００４９】マルチメディア動作用のモジュール化され
たオープン・アーキテクチャは、図１２ないし図２５を
参照して下で説明する、新規のデータ通信モジュールを
タスク間制御ブロックと組み合わせて使用することを介
して得られる。図１２、図１３および図１４は、モジュ
ール化されたオープン・アーキテクチャを得るためのデ
ータ通信モジュールとタスク間制御ブロックの使用を表
すブロック図である。図１２は、どちらも単一のディジ
タル信号プロセッサに常駐するタスク１５１からタスク
１５３への連続的なリアルタイム単一方向データ転送の
実現に使用することができるデータ通信モジュール１５
５を示す図である。タスク間制御ブロック（ＩＴＣＢ）
１５７は、タスク１５１内で定義され、タスク間制御ブ
ロック（ＩＴＣＢ）１５９は、タスク１５３内で定義さ
れる。タスク間制御ブロック１５７および１５９は、タ
スク１５１および１５３の間で状況と制御情報を渡すた
めに設けられる。

【００５０】図１３は、タスク１５１とタスク１５３の
間への暗号化タスク１６１の挿入を示す図である。図か
らわかるように、データ通信モジュール１５５は、タス
ク１５１から暗号化タスク１６１にデータを渡す。デー
タ通信モジュール１６３を暗号化タスク１６１とタスク
１５３の間に設けて、暗号化タスク１６１からタスク１
５３への連続的なリアルタイム単一方向データ伝送を可
能にする。図からわかるように、タスク間制御ブロック
１５７および１５９は、やはりタスク１５１とタスク１
５３の間での状況と制御情報の受け渡しに使用される。
タスク１５１、タスク１５３および暗号化タスク１６１
は、すべてが単一のディジタル信号プロセッサに常駐す
る。

【００５１】図１４は、第１のディジタル信号プロセッ
サに常駐するタスク１５１およびタスク１６１と、第２
のディジタル信号プロセッサに常駐するタスク１５３を
有し、これらのタスクがマルチメディア・タスクを実行
するために協力している構成を示す図である。図からわ
かるように、データ通信モジュール１５５は、タスク１
５１とタスク１６１の間のデータの受け渡しをもたら
す。データ通信モジュール１６３は、タスク１６１から
タスク１５３へのデータ渡しをもたらす。追加のタスク
間制御ブロック１６５が、タスク１５１とタスク１６１
の間での状況と制御情報の受け渡しをもたらし、タスク
間制御ブロック１５７および１５９が、タスク１５１と
タスク１５３の間の状況と制御変数の受け渡しを行う。

【００５２】図１２、図１３および図１４に示された形
で、モジュラー・マルチメディア・ソフトウェア・タス
クとマルチメディア末端装置を、無数のユーザ選択の組
合せで互いに接続することができる。ユーザは、個々の
必要に応じて独自のタスクをコード化した後に、データ
通信モジュールとタスク間通信ブロックを使用すること
によって、これらのタスクを先在するモジュラー・マル
チメディア・ソフトウェア・タスクに接続することがで
きる。ユーザは、モジュラー・マルチメディア・ソフト
ウェア・タスクの特定のコーディングに配慮する必要は
なく、データ通信モジュールとタスク間制御ブロックを
介するデータ受け渡しのデータ通信プロトコルだけを考
慮すればよい。

【００５３】したがって、本発明は、ユーザが、事前に
パッケージ化されたモジュラー・マルチメディア・ソフ
トウェア・タスクの動作に対する過度の危険なしに、ユ
ーザ自身のマルチメディア・アプリケーション・ソフト
ウェアをコーディングできるようにする、比較的危険性
の低いオープン・アーキテクチャを提供する。データ通
信モジュールとタスク間通信ブロックを使用することに
よって、非常に強化された接続性がもたらされ、実質的
にオープンなアーキテクチャが提示され、したがって、
非常に多数のソフトウェア・ベンダが、他のソフトウェ
ア・ベンダならびにエンド・ユーザ自身によって生成さ
れた他の事前にパッケージ化されたマルチメディア・ア
プリケーション・ソフトウェアに干渉せずにディジタル
信号プロセッサによって実行される広範囲のモジュラー
・マルチメディア・ソフトウェア・タスクを含む事前に
パッケージ化されたマルチメディア・アプリケーション
・ソフトウェアを作成し、販売することが可能になる。
この実質的にオープンなアーキテクチャを支持するため
には、データ通信モジュールとタスク間通信ブロックに
関して複数の厳密な規則が必要である。

【００５４】図１５、図１６および図１７は、モジュラ
ー・マルチメディア・ソフトウェア・タスクとマルチメ
ディア末端装置の間でのデータ転送のためにデータ通信
モジュールを秩序だった形で使用できるようにする好ま
しい動作規則を示す図である。この好ましい実施例で
は、データ通信モジュールが、２つ以上のモジュラー・
マルチメディア・ソフトウェア・タスクの間または１つ
のモジュラー・マルチメディア・ソフトウェア・タスク
と１つまたは複数のマルチメディア末端装置の間でデー
タ・ストリームを受け渡しするのに使用される環状バッ
ファである。図１５からわかるように、環状メモリ・ア
レイ１６７は、複数のバイトまたはワードからなり、こ
れらは、メモリ・セグメント１６９などの環状メモリ・
アレイ１６７内のセグメントによって図示されている。
図１５、図１６および図１７では、斜線のはいったメモ
リ・セグメントに新しいデータが含まれ、斜線のないメ
モリ・セグメントには新しいデータが含まれない。

【００５５】リアルタイム・データまたは非同期データ
の秩序だった通信を確保するために、あるタスクを、特
定のデータ通信モジュールの「オーナー」として指定す
る。あるデータ通信モジュールは、１つのオーナーだけ
を有することができる。オーナーは、そのデータ通信モ
ジュールの環状メモリ・アレイ１６７への書込を許可さ
れる唯一のタスクである。オーナー・タスクは、データ
が最後に書き込まれたメモリ・セグメントを識別する
「オーナー・ポインタ」または書込ポインタ１７１を制
御する。１つまたは複数のマルチメディア・ソフトウェ
ア・タスクは、データ通信モジュールの「ユーザ」とし
て識別される。「ユーザ」タスクまたは末端装置は、デ
ータが最後に読み取られた環状メモリ・アレイ１６７内
のメモリ・セグメントを識別するユーザ・ポインタまた
は「読取ポインタ」１７３を制御する。オーナー・タス
クが環状メモリ・アレイ１６７にデータを書き込む前
に、書込ポインタ１７１を増分して、環状メモリ・アレ
イ１６７内の次の連続したメモリ・セグメントを識別す
る。ユーザ・タスクが環状メモリ・アレイ１６７からデ
ータを読み取る前に、読取ポインタ１７３を同様に増分
して、次に読み取る環状メモリ・アレイ１６７内のメモ
リ・セグメントを識別する。データは、環状メモリ・ア
レイ１６７に対して１方向にのみ読み書きされる。これ
を、図１５の矢印１７５によって示す。

【００５６】図１６は、「空」のデータ通信モジュール
を示す図である。オーナー・タスクによって環状メモリ
・アレイ１６７に書き込まれたデータのすべてが、ユー
ザ・タスクによって読み取られたか「消費」されてい
る。この状況では、書込ポインタ１７１と読取ポインタ
１７３が、同一のメモリ・セグメントを識別している。
図１７は、「満杯」のデータ通信モジュールを示す図で
ある。この状況では、オーナー・タスクが、環状メモリ
・アレイ１６７内の使用可能なメモリ・セグメントのす
べてにデータを書き込んでいる。この状況は、書込ポイ
ンタ１７１が読取ポインタ１７３より１メモリ・セグメ
ント後ろにある時に識別できる。読取ポインタ１７３ま
たは書込ポインタ１７１を増分すると、そのポインタ
は、矢印１７５の方向にバッファ内を前進する。

【００５７】リアルタイム・データまたは非同期ストリ
ーム化データの通信を簡単にする上で、４つの標準化通
信プロトコルが、本発明の好ましい実施例によるデータ
通信モジュールと共に使用される。図１８、図１９、図
２０および図２１は、本発明の好ましい実施例でデータ
通信モジュールと共に使用される４つの標準化通信プロ
トコルを表す図である。図１８は、同期式プロトコルを
表す。図１９は、オーナー・データ駆動プロトコルを表
す。図２０は、ユーザ・データ駆動プロトコルを表す。
図２１は、安全データ駆動プロトコルを表す

【００５８】図１８に示された同期式プロトコルを参照
すると、オーナー・タスク１７７は、一定の速度で環状
メモリ・アレイ１６７にデータを書き込み、ユーザ・タ
スク１７９は、同じ一定速度でデータを読み取る。した
がって、オーナー・タスク１７７とユーザ・タスク１７
９の両方が、ユーザ・タスクに提供される書込ポインタ
１７１の位置（アドレス"PUTP"）に関するフィードバッ
クもオーナー・タスクに提供される読取ポインタ１７３
の位置（アドレス"GETP"）に関するフィードバックもな
い、「開ループ」で走行する。オーナー・タスク１７７
は、ユーザ・タスク１７９が正しい速度でデータを消費
していると仮定し、ユーザ・タスク１７９は、オーナー
・タスク１７７が正しい速度でデータを作成していると
仮定する。オーナー・タスク１７７とユーザ・タスク１
７９のどちらもが、バッファの「空」状態や「満杯」状
態を検査せず、オーナー・タスク１７７とユーザ・タス
ク１７９のどちらもが、もう一方のタスクのポインタの
位置またはアドレスを知らない。したがって、オーナー
・タスク１７７とユーザ・タスク１７９は、書込ポイン
タ１７１と読取ポインタ１７３の均一な間隔（時間上
の）によって明示される正確な同期の維持を保証するた
めに、同一のハードウェア割込み供給源から同一のサン
プル速度で走行することが重要である。同期式プロトコ
ル・モードの動作で動作しているデータ通信モジュール
にデータを書き込めるオーナー・タスクは１つだけであ
るが、任意の個数のユーザ・タスクをデータ通信モジュ
ールに接続することができる。

【００５９】図１９は、オーナー・タスク１７７が、そ
れ自体の速度で環状メモリ・アレイ１６７にデータを書
き込むオーナー・データ駆動プロトコルを示す図であ
る。ユーザ・タスク１７９は、オーナー・タスク１７７
に遅れずについてゆき、オーナー・タスク１７７が生成
し環状メモリ・アレイ１６７に書き込むデータのすべて
を消費することが期待される。オーナー・タスク１７７
は、「開ループ」で走行し、読取ポインタ１７３の位置
（すなわちアドレス）に関するフィードバックを全く有
さず、環状メモリ・アレイ１６７が「満杯」や「空」で
あるかどうかの判定を全く行わない。オーナー・タスク
１７７は、一定速度または、所定の最大速度までの可変
速で、環状メモリ・アレイ１６７にデータを書き込むこ
とができる。この最大速度は、下で詳細に説明するよう
に、最大ワード毎フレーム（MWPF）単位で、データ通信
モジュールを定義する「マクロ」で指定される。環状メ
モリ・アレイ１６７のサイズも、そのマクロによって"S
IZE"として指定される。サイズ（SIZE）、最大ワード毎
フレーム（MWPF）ならびに書込ポインタ１７１のアドレ
ス(APUT)は、すべてがユーザ・タスク１７９によって維
持され、ユーザ・タスク１７９がオーナー・タスク１７
７によって製作されたデータのすべてを消費することを
保証するのに使用される。ユーザ・タスク１７９は、環
状メモリ・アレイ１６７が絶対に満杯にならない、すな
わち、オーバーフローしないことを保証する責任を負
う。ユーザ・タスク１７９が遅れをとると、オーナー・
タスク１７７が新データで旧データを上書きすることに
なる。通常、ユーザ・タスク１７９は、使用可能なデー
タのすべてを読み取るか、１ブロック分のデータが使用
可能になると同時にそのブロックのデータを読み取るこ
とによって、環状メモリ・アレイ１６７を空にする。上
で述べたように、ユーザ・タスク１７９は、オーナー・
タスク１７７の書込ポインタ１７１のアドレスを知って
おり、したがって、ポインタの位置を比較することがで
きる。書込ポインタ１７１のアドレスPUTPが読取ポイン
タ１７３のアドレスGETPと等しい場合、環状メモリ・ア
レイ１６７は「空」である。そうでない場合には、環状
メモリ・アレイ１６７に、ユーザ・タスク１７９によっ
て消費されなければならないデータが含まれる。

【００６０】オーナー・データ駆動プロトコルは、オー
ナー・タスク１７７が所与の速度でデータを製作しなけ
ればならないが、ユーザ・タスク１７９がその消費速度
をオーナー・タスク１７７の速度に合わせることができ
る時に有用である。オーナー・データ駆動プロトコルを
必要とする応用例が、電話回線からデータを受け取り、
処理のため別のタスクにデータを渡すモデムである。電
話回線からの着信データをサンプリングするタスクは、
これを正確に固定された速度で行わなければならない。
データを処理するタスクの時間要件は、これほど厳しく
はないであろう。

【００６１】図２０は、ユーザ・タスク１７９がそれ自
体の速度でデータを読み取るユーザ・データ駆動プロト
コルを示す図である。オーナー・タスク１７７は、ユー
ザ・タスク１７９の速度に一致することが期待され、必
ず環状メモリ・アレイ１６７内に十分なデータを保持し
なければならない。ユーザ・タスク１７９は、一定速ま
たは可変速でデータを読み取ることができるが、この速
度は、指定された最大速度以下でなければならない。オ
ーナー・タスク１７７は、ユーザ・タスク１７９の最大
データ消費速度（MWPF）に基づいて、書込ポインタ１７
１と読取ポインタ１７３の間の間隔を維持する責任を負
う。ユーザ・タスク１７９は、「開ループ」で走行し、
書込ポインタ１７１のアドレスPUTPを知らない。対照的
に、オーナー・タスク１７７は、ユーザ・タスク１７９
の読取ポインタ１７３のアドレスAGETを知っている。

【００６２】図２１は、安全データ駆動プロトコル・モ
ードの動作を示す図である。このプロトコルでは、オー
ナー・タスク１７７とユーザ・タスク１７９の両方が、
積極的にポインタ・オーバーランを防止する。オーナー
・タスク１７７は、書込ポインタ１７１と読取ポインタ
１７３の位置を考慮して環状メモリ・アレイ１６７が
「満杯」と判定される場合には、絶対に環状メモリ・ア
レイ１６７にデータを書き込まない。ユーザ・タスク１
７９は、書込ポインタ１７１と読取ポインタ１７３の相
対位置によって環状メモリ・アレイ１６７が「空」と判
定される場合には、絶対に環状メモリ・アレイ１６７か
らデータを読み取らない。オーナー・タスク１７７が、
１ブロックあたり１６サンプルなどのブロック単位でユ
ーザ・タスク１７９にデータを渡す場合、オーナー・タ
スク１７７は、書込動作を開始する前に、１ブロック分
の空きが環状メモリ・アレイ１６７内に生じるまで待機
しなければならない。ユーザ・タスク１７９は、読取動
作を開始するために、１ブロック分のデータが使用可能
になるまで待機しなければならない。この安全データ駆
動プロトコルの動作では、オーナー・タスク１７７に、
読取ポインタ１７３のアドレスが常に通知される。反対
に、ユーザ・タスク１７９には、書込ポインタ１７１の
アドレスが常に通知される。

【００６３】データ通信モジュールへのすべての接続
は、図４４に示されるデータ通信モジュール・マクロに
関して確立し、定義することができる。データ通信モジ
ュールへの接続のそれぞれは、下記のラベルおよびパラ
メータの参照によって定義される。 （１）ラベル（label） （２）オーナーまたはユーザの指定（OWNER、USER） （３）サイズまたは最小サイズ（size、MINSIZE） （４）データ通信プロトコル（PROTOCOL） （５）データ読取またはデータ書込のいずれかの最大ワ
ード毎秒（MAXWPF） （６）最小ポインタ間隔（MPTRSEP） （７）データ・サンプル速度（SAMPRATE） （８）データ・アドレッシング・モード（ADDRMODE） （９）データ・フォーマット・モード（MODE） （１０）読取動作と書込動作の間の最大遅延（MAXDELT、
MAXDELF） （１１）そのデータ通信モジュールを通過するデータ要
素のサイズ（STRIDE）

【００６４】これらのパラメータのそれぞれを、下でマ
クロを参照して詳細に説明する。マクロは、アセンブラ
・プログラミング言語の形で図４４に示されている。

【００６５】LABEL FOR THE DATA COMMUNICATION MODUL
E（データ通信モジュールのラベル）：ラベルは、デー
タ通信モジュールを指定するために必要である。これ
は、モジュラー・マルチメディア・ソフトウェア・タス
ク間またはモジュラー・マルチメディア・ソフトウェア
・タスクとマルチメディア末端装置の間でデータを受け
渡しするために作成された他のデータ通信モジュールか
ら特定のデータ通信モジュールを識別し、区別するのに
使用される。

【００６６】OWNER OR USER DESIGNATION（オーナーま
たはユーザの指定）：データ通信モジュールへの接続
を、オーナー・タイプまたはユーザ・タイプのいずれか
として識別することが必要である。両方を指定すること
はできない。

【００６７】SIZE（サイズ）：環状メモリ・アレイのサ
イズを、１６ビット・ワード単位で指定する。好ましい
実施例では、データ通信モジュールが３２、６４、１２
８、２５６、５１２、１０２４または２０４８ワードの
サイズを有することができる。同期式プロトコル・モー
ドの動作でのデータ通信モジュールの動作のためには、
バッファのサイズが、製作または消費される最大ワード
毎フレームの少なくとも２倍であることが重要である。
代替案では、ユーザが、ユーザ・タイプのデータ通信モ
ジュールのみに関して最小バッファ・サイズを選択でき
る。ユーザ・タイプのデータ通信モジュールは、最小サ
イズ（MINSIZE）以上のサイズを有するオーナー・タイ
プのデータ通信モジュールに接続することができる。

【００６８】PROTOCOL（プロトコル）：上で述べたよう
に、同期式プロトコル、オーナー・データ駆動プロトコ
ル、ユーザ・データ駆動プロトコルおよび安全データ駆
動プロトコルを含む４つのプロトコルを、ユーザが選択
することができる。図２２に、最下位５ビットがデータ
通信プロトコルの選択を表す１６ビット・ワードを示
す。ビット０の２進数１は、プロトコルが選択されてい
ないことを示す。ビット１の２進数１は、同期式プロト
コル・モードの動作がユーザによって選択されたことを
示す。ビット２の２進数１は、オーナー・データ駆動プ
ロトコルが選択されたことを示す。ビット３の２進数１
は、ユーザがユーザ・データ駆動プロトコルを選択した
ことを示す。最後に、ビット４の２進数１は、安全デー
タ駆動プロトコルが選択されたことを示す。ユーザは、
プロトコルに互換性があるならば、複数のプロトコルを
選択することができる。図４５に、プロトコルの互換性
を示す。図からわかるように、同期式プロトコル・モー
ドの動作で動作するオーナー・タイプのタスクは、デー
タ通信モジュールを介して、同期式（SYNC）プロトコル
モードの動作またはオーナー・データ駆動（OWNERDD）
プロトコル・モードの動作のいずれかのユーザ・タイプ
のタスクと接続することができる。図４５には、さら
に、オーナー・データ駆動プロトコル・モードの動作で
動作するオーナー・タイプのタスクが、データ通信モジ
ュールを介して、オーナー・データ駆動プロトコル・モ
ードの動作のユーザ・タイプのタスクだけに結合できる
ことが示されている。図４５には、さらに、ユーザ・デ
ータ駆動（USERDD）プロトコル・モードの動作で動作す
るオーナー・タイプのタスクが、データ通信モジュール
を介して、識別される４つのプロトコル・モードの動作
のどれで動作するユーザ・タイプのタスクにでもデータ
を渡せることが示されている。最後に、図４５には、安
全データ駆動（SAFEDD）プロトコル・モードの動作で動
作するオーナー・タイプのタスクが、オーナー・データ
駆動プロトコル・モードの動作または安全データ駆動プ
ロトコル・モードの動作のいずれかで動作するユーザ・
タイプのタスクにデータを渡せることが示されている。

【００６９】MAXIMUM WORDS PER FRAME（最大ワード毎
フレーム）：最大ワード毎フレームは、タスク実行のた
びに製作または消費されるワードの最大数である。たと
えば、オーナー・タスクが毎フレーム１６ワードの一定
速度でデータを書き込む場合、最大ワード毎フレーム
（MAXWPF）は１６である。

【００７０】MINIMUM SEPARATION（MPTRSEP、最小間
隔）：最小間隔は、オーナー・ポインタとユーザ・ポイ
ンタの間で許容することのできる最少の間隔である。同
期式プロトコル・モードの動作で動作しているデータ通
信モジュールの場合、経験則として、最小間隔を最大ワ
ード毎フレームにセットするのがよい。オーナー・タス
クとユーザ・タスクが異なる値の最小間隔を定義する場
合、大きい方の値を使用して、これら２つの動作を同期
化させなければならない。

【００７１】SAMPLE RATE（SAMPRATE、サンプル速
度）：サンプル速度は、データ通信モジュールを通って
流れるデータの固有のサンプル速度を指定するパラメー
タである。ユーザとオーナーの両方が０以外のサンプル
速度を指定する場合、サンプル速度は、オーナー・タス
クとユーザ・タスクの両方について同一でなければなら
ない。そうでない場合には、それらのタスクを接続する
ことができない。

【００７２】DATA ADDRESSING MODE（ADDRMODE、データ
・アドレッシング・モード）：データ・アドレッシング
・モードは、データ通信モジュールのポインタを操作す
るのに使用されるモードを識別するパラメータである。
選択肢は、"byte（バイト）"、"table（テーブル）"ま
たは"word（ワード）"である。オーナー・タスクとユー
ザ・タスクを接続するためには、これらが同一のタイプ
のデータ・アドレッシング・モードを識別しなければな
らない。

【００７３】DATA FORMAT MODE（MODE、データ・フォー
マット・モード）：データ・フォーマット・モードは、
データ通信モジュールに書き込まれ、読み取られるデー
タのフォーマットを記述するパラメータである。オーナ
ー・タスクとユーザ・タスクは、同一のモードを指定し
なければならない。そうでない場合、接続が許可されな
い。データは、長さN（Nは整数）のパケットとみなされ
る。たとえば、Nを２にセットするという技法は、ステ
レオ・サウンドの右チャンネルと左チャンネルの伝送
や、複素数の実数部と虚数部を伝送を可能にする技法の
１つである。Nを他の整数値にセットすると、ある信号
の異なる部分を表すN個の構成要素内のより大きなデー
タの集合を受け渡しできるようになる。データ・フォー
マット・モードを"universal（汎用）"にセットする
と、データ・フォーマットに関する具体的なモード選択
に無関係に、データ通信モジュールを別のデータ通信モ
ジュールに接続できるようになる。

【００７４】MAXIMUM DELAY（MAXDELT,MAXDELF、最大遅
延）：最大遅延は、オーナー・タスクがデータ通信モジ
ュールにデータを書き込む時刻とユーザ・タスクがデー
タ通信モジュールからデータを読み取る時刻の間で許容
される時間を表すパラメータである。最大遅延は、"MAX
DELF"または"MAXDELT"のいずれかとして指定できるが、
両方を指定することはできない。MAXDELTは、ナノ秒、
マイクロ秒、ミリ秒または秒単位の絶対時間で測定され
た時間である。MAXDELFの測定単位は、データ通信モジ
ュール・マクロに関連するタスクの１フレームまたは１
周期である。たとえば、あるオーナー・タスクが８KHz
の割込み供給源からの割込みの８回に１回走行する場
合、そのタスクのフレームまたは周期は、１ミリ秒と判
定される。このタスクは、それが通信モジュールにデー
タを書き込んだ時刻とそのデータが消費される時刻の間
に３ミリ秒以内の遅延しか許容できない。このデータ通
信モジュール・マクロでは、MAXDELT=3msまたはMAXDELF
=3のいずれかによって遅延許容範囲を指定しなければな
らない。

【００７５】STRIDE（ストライド）：ストライドは、デ
ータ通信モジュールを通過するデータ要素の、ワード単
位のサイズである。ストライドは、タスクに有用な１単
位の情報を含む１６ビット・サンプルの個数を定義する
パラメータである。N次元データを処理している場合、
ストライドは、Nにセットしなければならない。たとえ
ば、ステレオ・オーディオは、左右のサンプル対の形で
処理しなければならないので、ストライドを２にセット
しなければならない。

【００７６】図２３は、図４４に示された、データ通信
モジュールを定義するマクロで行われた指定の結果とし
ての、オーナー・タスクとユーザ・タスクでの制御ブロ
ックの作成を示す図である。製作側であるオーナー・タ
スク１７７を環状メモリ・アレイ１６７に接続し、消費
側であるユーザ・タスク１７９を環状メモリ・アレイ１
６７に接続するために、２つのマクロ（図４４に示され
たものなど）を定義しなければならない。オーナー・タ
イプのマクロによって、オーナー・タスクのデータ・セ
グメントに制御ブロック１８１が作成される。ユーザ・
タイプのマクロによって、ユーザ・タスクのデータ・セ
グメントに制御ブロック１８３が作成される。制御ブロ
ックの長さは、選択されたデータ通信プロトコルに応じ
て、１ワードから４ワードまでの間で変化する。生成さ
れる可能性のある異なるタイプの制御ブロックを、図１
８ないし図２１に示す。

【００７７】図１８に戻って、オーナー・タスク１７７
内に確立された制御ブロックには、書込ポインタ１７１
だけが含まれる。ユーザ・タスク１７９には、読取ポイ
ンタ１７３（GETP）だけが含まれる。図１９では、オー
ナー・タスク１７７に、書込ポインタ１７１（PUTP）だ
けが含まれる。ユーザ・タスク１７９では、制御ブロッ
クに、読取ポインタ１７３（GETP）、環状メモリ・アレ
イのサイズ（SIZE）、最大ワード毎フレーム（MWPF）お
よび書込ポインタ１７１のアドレス（APUT）が含まれ
る。図２０では、オーナー・タスク１７７が、書込ポイ
ンタ１７１（PUTP）、環状メモリ・アレイのサイズ（SI
ZE）、最大ワード毎秒（MWPF）および読取ポインタ１７
３のアドレス（AGET）を含む制御ブロックを有する。ユ
ーザ・タスク１７９には、読取ポインタ１７３だけが含
まれる。図２１では、オーナー・タスク１７７の制御ブ
ロックに、書込ポインタ１７１のアドレス（PUTP）と読
取ポインタ１７３のアドレス（AGET）の両方が含まれ
る。ユーザ・タスク１７９にも同様に、読取ポインタ１
７３(GETP)と書込ポインタ１７１のアドレス（APUT）が
含まれる。

【００７８】データ通信モジュール用の堅固なデータ通
信構造と標準化データ通信プロトコルを有することの実
質的な利益の１つが、データ通信モジュールに対する読
取動作と書込動作を、単純な標準化されたソフトウェア
・ルーチンとして構築できることである。図２８は、同
期式プロトコル・モードの動作でデータ通信モジュール
にデータを書き込むタスクの流れ図である。図２９は、
同期式プロトコル・モードの動作でデータ通信モジュー
ルからデータを読み取るタスクの流れ図である。

【００７９】まず図２８を参照すると、書込動作は、ブ
ロック２０１から始まる。ブロック２０３で、ディジタ
ル信号プロセッサに、オーナー（書込）ポインタをゲッ
トするように命令する。ディジタル信号プロセッサは、
インデクシングを可能にするためにブロック２０５で停
止する。この実施例の特定のDSPは、アドレス・レジス
タの更新に１クロック・サイクルを必要とする。ブロッ
ク２０７で、ディジタル信号プロセッサが、選択された
データ通信モジュールを構成する環状バッファにデータ
を書き込む。その後、ブロック２０９で、ディジタル信
号プロセッサが、オーナー（書込）ポインタを増分し
て、環状バッファ内の次のメモリ・セグメントへの書込
を可能にする。書込動作が完了するまで、ブロック２０
７とブロック２０９を繰り返す。ブロック２１１で、デ
ィジタル信号プロセッサは、将来の書込動作で使用する
ためにポインタの値をセーブする。ブロック２１３で、
このルーチンは、DSPメモリ内に常駐するDSPオペレーテ
ィング・システムに戻る。ブロック２１５で、書込処理
が停止する。

【００８０】データをデータ通信モジュールから読み取
る時の処理は、そのタスクがDSPオペレーティング・シ
ステムによって処理のためにスケジューリングされた時
に、ブロック２１７から始まる。ブロック２１９で、デ
ィジタル信号プロセッサに、ユーザ（読取）ポインタを
ゲットするように命令する。ブロック２２１で、ディジ
タル信号プロセッサがインデクシング動作を待つ。ブロ
ック２２３で、ディジタル信号プロセッサが、環状バッ
ファからデータを読み取る。次に、ブロック２２５で、
ディジタル信号プロセッサが、ユーザ（読取）ポインタ
を増分する。読取動作が完了するまで、ブロック２２３
とブロック２２５を繰り返す。ブロック２２７で、ディ
ジタル信号プロセッサが、将来の読取動作に使用するた
めにユーザ（読取）ポインタの値をセーブする。その
後、ブロック２２９で、このルーチンはDSPメモリに常
駐するDSPオペレーティング・システムに戻る。

【００８１】図３０は、ユーザ・データ駆動プロトコル
・モードの動作でデータ通信モジュールにデータを書き
込むタスクの流れ図である。この処理は、DSPオペレー
ティング・システムによってタスクが実行のためにスケ
ジューリングされた時に、ブロック２３５から始まる。
ブロック２３７で、ディジタル信号プロセッサに、オー
ナー（書込）ポインタの値を判定するよう命令する。次
に、ブロック２３９で、ディジタル信号プロセッサに、
ユーザ（読取）ポインタの値を判定するよう命令する。
その後、ブロック２４１で、ディジタル信号プロセッサ
に、オーナー（書込）ポインタとユーザ（読取）ポイン
タの間の距離を判定するよう命令する。ブロック２４３
で、ディジタル信号プロセッサに、判定されたオーナー
（書込）ポインタとユーザ（読取）ポインタの間の距離
に応じた速度で、データ通信モジュールにデータを書き
込むように命令する。ブロック２４５で、ディジタル信
号プロセッサに、オーナー（書込）ポインタとユーザ
（読取）ポインタの両方のポインタの値をセーブするよ
う命令する。ブロック２４７によって、このルーチン
は、DSPメモリに常駐するDSPオペレーティング・システ
ムに戻る。最後に、ブロック２４９で、処理が停止す
る。

【００８２】図３１は、オーナー・データ駆動プロトコ
ル・モードの動作または安全データ駆動プロトコル・モ
ードの動作のいずれかでデータ通信モジュールからデー
タを読み取るタスクを示す流れ図である。この処理は、
DSPオペレーティング・システムが実行のためこのルー
チンをスケジューリングした時に、ブロック２５１から
始まる。ブロック２５３で、ディジタル信号プロセッサ
に、オーナー（書込）ポインタの値を判定するよう命令
する。次に、ブロック２５５で、ディジタル信号プロセ
ッサに、ユーザ（読取）ポインタの値を判定するよう命
令する。ブロック２５７で、ディジタル信号プロセッサ
に、オーナー（書込）ポインタとユーザ（読取）ポイン
タの間の距離を判定するよう命令する。次に、ブロック
２５９で、ディジタル信号プロセッサに、ポインタ位置
から環状メモリ・アレイが「空」であることが示される
まで、データ通信モジュールから使用可能データを読み
取るよう命令する。次に、ブロック２６１で、ディジタ
ル信号プロセッサに、将来の読取動作で使用するために
ポインタの値をセーブするよう命令する。ブロック２６
３で、ディジタル信号プロセッサが、DSPメモリに常駐
するDSPオペレーティング・システムに制御を返す。最
後に、ステップ２６５で、この処理が終了する。

【００８３】上で述べたように、単一のユーザ・タスク
が、複数のデータ通信モジュールを介してストリーム化
されたデータを受け取ることが可能である。図２４は、
複数のモジュラー・マルチメディア・ソフトウェア・タ
スク２６７、２６９、２７１および２７３から、複数の
データ通信モジュール２７５、２７７、２７９および２
８１を介して単一のユーザ・タスク２９３への、仮想デ
ータ通信モジュール２９１の使用を介するデータ・スト
リームの通信を示すブロック図である。本発明の好まし
い実施例では、複数の「ミュート」タスク２８３、２８
５、２８７および２８９が、データ通信モジュール２７
５、２７７、２７９および２８１と仮想データ通信モジ
ュール２９１の間に接続される。ミュート・タスク２８
３、２８５、２８７および２８９は、データ通信モジュ
ール２７５、２７７、２７９および２８１の出力に減衰
係数または「ミュート」係数を適用して、出力を減衰さ
せ、仮想データ通信モジュール２９１によって実行され
る合計演算中のオーバーフローを防ぐ。

【００８４】この種の動作の例を、図２６に示す。図２
６は、シンセサイザ・タスク２９５、モデム・オーディ
オ・タスク２９７およびアラーム・クロック・サウンド
・タスク２９９を含む複数のモジュラー・マルチメディ
ア・ソフトウェア・タスクから単一のCDディジタル・オ
ーディオ（CD-D/A）変換器タスク３０７への、オーディ
オ出力信号の多重化を示すブロック図である。リアルタ
イム・データまたは非同期ストリーム化データが、シン
セサイザ・タスク２９５からデータ通信モジュール３０
１を介して仮想データ通信モジュール３１７に向けられ
る。同様に、リアルタイム・データまたは非同期ストリ
ーム・データが、モデム・オーディオ・タスク２９７か
らデータ通信モジュール３０３を介して仮想データ通信
モジュール３１７に向けられる。同様に、アラーム・ク
ロック・サウンド・タスク２９９は、リアルタイム・デ
ータまたは非同期ストリーム化データを、データ通信モ
ジュール３０５を介して仮想データ通信モジュール３１
７に向ける。仮想データ通信モジュール３１７は、シン
セサイザ・タスク２９５、モデム・オーディオ・タスク
２９７およびアラーム・クロック・サウンド・タスク２
９９からのさまざまなリアルタイム・データまたは非同
期ストリーム化データ出力を合計して、CD-D/Aタスク３
０７への入力を提供する。CD-D/Aタスク３０７は、仮想
データ通信モジュール３１７からのディジタル出力を、
ディジタル化アナログ出力に変換する。この出力は、デ
ータ通信モジュール３０９および３１１を介して渡され
た後に、スピーカ３１３および３１５に向けられ、オー
ディオ・サウンド出力をもたらす。

【００８５】図２６に示された例では、シンセサイザ・
タスク２９５からの出力が、合成された人間の音声を表
す可能性がある。モデム・オーディオ・タスク２９７か
らの出力は、モデム・タスクが実行中であることをユー
ザに示すために、市販の大半のモデムで実現されている
聴取可能な確認トーンを表す可能性がある。アラーム・
クロック・サウンド・タスク２９９は、所定の時刻に予
定された事象についてユーザに警告するためのアラーム
・クロック・サウンドを表す可能性がある。仮想データ
通信モジュール３１７を使用すると、これらのタスクか
らのリアルタイム・データまたは非同期ストリーム化デ
ータを用いてスピーカ３１３および３１５を同時に駆動
できるようになる。これは、マルチメディア末端装置を
駆動するさまざまなマルチメディアタスクのオーバーラ
ップする同時動作が、特定のタスクや末端装置のいずれ
の動作にも干渉せずに可能になるので、有利な特徴であ
る。この形で、図２６は、定義済みの標準化デー通信プ
ロトコルおよびデータ通信規則と共に使用される本発明
のデータ通信モジュールの実世界での利点の１つを示す
ものである。

【００８６】図２５は、図２４および図２６の仮想デー
タ通信モジュールの動作を示す詳細なブロック図であ
る。図２５からわかるように、オーナー・タスク３１９
は、書込ポインタ３３１を使用してデータ通信モジュー
ル３２５にデータを書き込み、オーナー・タスク３２１
は、書込ポインタ３３３を使用してデータ通信モジュー
ル３２７にデータを書き込み、オーナー・タスク３２３
は、書込ポインタ３３５を使用してデータ通信モジュー
ル３２９にデータを書き込む。読取ポインタ３３７、３
３９および３４１によって、ユーザ・タスク３４３、デ
ータ・マクロ３４５、３４７および３４９の命令とパラ
メータに従い、データ通信モジュール３２５、３２７お
よび３２９からデータを読み取る。図からわかるよう
に、データ・マクロ３４５、３４７および３４９は、図
２５の右側に描かれた仮想データ通信モジュール制御ブ
ロックを介して、リンク・リストによって互いに結合さ
れる。図からわかるように、リンク３５１によってユー
ザ・タスク３４３がデータ・マクロ３４５に接続され
る。リンク３５３によって、データ・マクロ３４５がデ
ータ・マクロ３４７に接続される。リンク３５５によっ
て、データ・マクロ３４７がデータ・マクロ３４９に接
続される。

【００８７】ユーザ・タスク３４３には、データ・マク
ロ３４５へのアドレス（VDCMマクロ）が含まれる。デー
タ・マクロ３４５によって、ミュート係数、読取ポイン
タ（GETP）、データ通信モジュール３２５のサイズ（SI
ZE）、データ通信モジュール３２５への最大データ・フ
ロー速度（最大ワード毎フレーム、MWPF）および書込ポ
インタ３３１のアドレス（APUT）が定義される。データ
・マクロ３４５には、さらに、オーナー・タスク３１９
からのデータを処理する際にユーザ・タスク３４３によ
って使用することのできる（しなくてもよい）ユーザ定
義変数が含まれる。データ・マクロ３４５には、次の仮
想データ通信モジュールへのアドレスが含まれる。図か
らわかるように、データ・マクロ３４７には、読取ポイ
ンタ３３９（GETP）、データ通信モジュール３２７のサ
イズ（SIZE）、データ通信モジュール３２７への最大デ
ータ・フロー速度（最大ワード毎フレーム、MWPF）およ
び書込ポインタ３３３のアドレス（APUT）が含まれる。
データ・マクロ３４７には、さらに、オーナー・タスク
３２１からのデータを処理する際にユーザ・タスク３４
３によって使用することのできるユーザ定義変数が含ま
れる。データ・マクロ３４７には、次の仮想データ通信
モジュールへのアドレスも含まれる。図からわかるよう
に、データ・マクロ３４９には、読取ポインタ３４１の
値（GETP）が含まれる。データ・マクロ３４９は、最後
のデータ多重化タスクを表すので、その最初の位置を"0
000"にセットして、制御を他のデータ・マクロに渡して
はならないことを示す。

【００８８】図４６は、仮想データ通信マクロの基本概
念を表の形で識別する図である。最初の構成要素は、
「次の仮想DCM」として識別される、「次の仮想データ
通信モジュール」へのアドレスである。第２の構成要素
は、接続中に出力を静かにするのに使用されるミュート
係数（Mute)である。第３の構成要素は、ユーザのポイ
ンタ、環状メモリ・バッファのサイズ、最大ワード毎フ
レームおよびオーナーのポインタのアドレスを識別する
制御ブロックである。最後に、他の変数のためにユーザ
定義データを設ける。

【００８９】上で述べたように、データ通信モジュール
は、これまで完全には説明してこなかったタスク間制御
ブロック（ITCB）と共同して働く。図２７は、タスク間
制御ブロックの動作を示すブロック図である。各タスク
は、ディジタル信号オぺレーティング・システムによっ
て実行のために呼び出されるが、他のタスクからは不可
視のそれ自体の局所データ・セクションを有する。タス
ク間制御ブロックは、あるタスクが別のタスクと１ブロ
ックのデータを共用できるようにする機構である。タス
ク間制御ブロック（ITCB）を介して通信するタスクを、
「主タスク」および「副タスク」と呼ぶ。図２７に、主
タスク３５７、副タスク３５９およびその相互接続を示
す。図からわかるように、ホストCPUに常駐するホスト
・アプリケーション３６１は、アプリケーション・プロ
グラム・インターフェース（API）コマンド"connect IT
CB（ITCB接続）"と"disconnect ITCB（ITCB切断）"を使
用して、ポインタ３６７の接続と切断を行う。このポイ
ンタは、副タスク３５９のデータ・セグメントから、主
タスク３５７のデータ・セグメント部分にある制御ブロ
ック３６９を指す。したがって、選択されたモジュラー
・マルチメディア・ソフトウェア・タスク間で状況と制
御変数を受け渡しする制御ブロック３６９は、主タスク
のデータ・セクションに置かれる。主タスク３５７に
は、データの構造を定義するマクロが含まれる。副タス
ク３５９には、制御ブロック３６９の先頭を差すポイン
タ３６７を宣言するマクロが含まれる。

【００９０】前に述べたように、ホスト・アプリケーシ
ョン３６１は、定義済みのディジタル信号プロセッサ・
コマンドを用いて副タスク３５９を主タスク３５７に接
続する。タスクが接続される時に、図３のDSPマネージ
ャ７１が、副タスク３５９のデータ・セクション内の制
御ブロック３６９を指すポインタを記憶する。ホスト・
アプリケーション３６１は、いつでも主タスク３５７か
ら副タスク３５９を切断したり接続することができる。
タスクが接続された時、副タスク３５９は、主タスク３
５７の制御ブロック３６９のデータを読み書きすること
ができる。副タスク３５９は通常、制御ブロック３６９
のベースを指すポインタ３６７をインデックス・レジス
タにロードし、制御ブロック３６９内のデータをベース
からのオフセットとしてアドレッシングする。

【００９１】タスク間制御ブロックの作成と使用に必要
な全体的なシーケンスをまとめると、次のようになる。 （１）タスク間制御ブロックを、（１）ITCB PRIMARY
（主ITCB）、（２）ITCBLBLおよび（３）EITCBを含む３
つのマクロを使用して、主タスクのデータ・セクション
内でコード化する。これら３つのマクロは、下で説明す
る。 （２）副ITCBを、副タスクのデータ・セクション内にマ
クロを介してコード化する。このマクロは、主タスクの
ITCBデータ・ブロックの先頭を指すポインタのために１
ワードのメモリを割り振る。 （３）実行時に、ホスト・システムのアプリケーション
が、DSPマネージャへの呼出しをセットすることによっ
て、副タスクを主タスクに接続する。その後、DSPマネ
ージャが、副タスクのポインタに、タスク間制御ブロッ
クのベース・アドレスをロードする。もちろん、ホスト
・アプリケーションは、いつでも副タスクを接続したり
切断することができる。 （４）タスクが接続された後には、副タスクがタスク間
制御データ・ブロックを読み書きできる。通常、副タス
クは、このデータ・ブロックのベースを指すポインタを
インデックス・レジスタにロードし、ベースからのオフ
セットとしてこのレジスタ内でデータをアドレッシング
する。副ポインタは、接続が存在しない時には０にセッ
トされる。

【００９２】主タスクのデータ・セクション内のITCB P
RIMARYマクロは、ITCBデータ・ブロックの先頭を識別
し、EITCBマクロは、制御データ・ブロックの末尾を識
別する。ITCBLBLマクロは、所与のITCB制御データ・ブ
ロック内の単一の変数または変数のグループの属性を定
義する。このマクロによって、下記の情報が定義され
る。 （１）読取動作と書込動作に関して、変数のために確立
されたITCBプロトコル （２）あるタスクから別のタスクに変数を渡す際に許容
される最大遅延 （３）１つまたは複数の変数のラベル

【００９３】タスク間制御ブロックの機能ならびに、デ
ータ通信モジュールの全体動作および長所は、図３２、
図３３および図３４に示された例を参照することによっ
て最もよく理解できる。図３２は、複数のモジュラー・
マルチメディア・ソフトウェア・タスクの動作を示すブ
ロック図であり、これらのタスクの一部は、通常のハー
ドウェア・マルチメディア末端装置の動作を仮想化す
る。図３３は、オーディオ出力増幅タスクの動作を示す
ブロック図である。図３４は、データ・ストリーム間の
位相差を制御し操作するためのデータ通信モジュールと
モジュラー・マルチメディア・ソフトウェア・タスクの
使用を示すブロック図である。

【００９４】まず図３２を参照すると、全二重モードで
動作するモデムの機能を実行するよう構成された、本発
明のマルチメディア・データ処理システムの動作が示さ
れている。CPU３３が、ディジタル信号プロセッサ３７
にデータを送り、これからデータを受け取る。具体的に
言うと、データは、汎用非同期送受信器（UART）レジス
タ３７１を介して渡される。ストリーム化データは、デ
ィジタル信号プロセッサ３７からデータ通信モジュール
３７３を介して送られる。このデータ通信モジュール
は、モデム制御タスク３７７へのデータの連続的なリア
ルタイム単一方向通信を可能にする。データ通信モジュ
ール３７５は、連続的なリアルタイム単一方向データ
を、モデム制御タスク３７７からディジタル信号プロセ
ッサ３７に向けるように働く。データ通信モジュール３
７９は、ストリーム化データをモデム制御タスク３７７
からデータ変換タスク３８３に向けるように働く。デー
タ通信モジュール３８１は、データをデータ変換タスク
３８３からモデム制御タスク３７７に向けるように働
く。データ通信モジュール３８５は、データをデータ変
換タスク３８３から電話タスク３８９に向けるように働
く。データ通信モジュール３８７は、データを電話タス
ク３８９からデータ変換タスク３８３に向けるように働
く。電話タスク３８９は、データ通信モジュール３９１
を介して電話入出力回線と通信する。図からわかるよう
に、データ通信モジュールは、全二重モードで動作する
モデムのデータ・フロー経路に対応する２つのデータ・
フロー経路をもたらす。

【００９５】モデム制御タスク３７７は、電話入出力か
らデータ通信モジュール３９１で受け取られる可能性が
あるRING（呼出）信号を含むさまざまな変数に反応する
ソフトウェア状態機械を表す。タスク間通信ブロック３
９５は、モデム制御タスク３７７をデータ通信モジュー
ル３９１に連結し、電話入出力回線上でRINGを受け取っ
たことをモデム制御タスク３７７に警告するために、デ
ータ通信モジュール３９１からモデム制御タスク３７７
へ変数RINGを渡せるようにする。

【００９６】データ変換タスク３８３は、モデム制御タ
スク３７７からディジタル・データ・ストリームを受け
取り、そのディジタル・データ・ストリームに対応する
ディジタル化アナログ信号を表す出力ストリームを作る
ように動作する。タスク間制御ブロック３９３は、デー
タ変換タスク３８３とモデム制御タスク３７７の間に結
合され、これらのタスクの間で変数RATE（速度）を通信
するように働く。RATEは、データ変換タスク３８３から
ディジタル化アナログ形式でデータを出力しなければな
らない速度を識別する変数である。

【００９７】図３２の例によれば、状況標識RINGと制御
変数RATEをこれらのタスクとデータ通信モジュールの間
で渡して、モジュラー・マルチメディア・ソフトウェア
・タスクの調整された動作を保証する。図３２からわか
るように、通常の電話の機能を、モジュラー・マルチメ
ディア・ソフトウェア・タスクである電話タスク３８９
によって、ソフトウェア的にシミュレートすることがで
きる。同様に、モデム制御タスク３７７によって、通常
のモデムの通常のハードウェアおよびソフトウェアの機
能をシミュレートする。したがって、本発明は、さまざ
まな従来のハードウェア末端装置を「仮想化」するのに
有用であり、したがって、ユーザに、既存の従来技術シ
ステムから拡張された柔軟性を提供することが明白であ
る。ユーザは、通常は従来のマルチメディア末端装置に
よって実行されるはずのタスクを、CPUおよびディジタ
ル信号プロセッサによって実行されるようにコード化す
ることができる。ハードウェア装置の従来の機能を実行
するソフトウェア・ルーチンによってハードウェア装置
を「仮想化」することによって、かなりの節約が可能に
なる。この技法を使用してさまざまなマルチメディア末
端装置を仮想化することによって、エンド・ユーザに、
マルチメディア環境に対する拡張された制御が与えられ
る。

【００９８】図３３は、タスクが制御変数を読み書きで
きるかどうかを判定するのに使用されるITCBプロトコル
の使用例を示す図である。図からわかるように、データ
通信モジュール３９７は、ストリーム化データを増幅お
よび電力計算タスク３９９に通信する。データ通信モジ
ュール４０１は、増幅および電力計算タスク３９９の出
力を受け取り、これをステレオ出力に向ける。タスク間
制御ブロック（ITCB）４０３は、別の（非開示の）タス
クから増幅および電力計算タスク３９９へ変数を通信す
る。

【００９９】ITCB４０３には、２つの変数すなわち、"G
AIN L"および"GAIN R"として識別される左利得４０５と
右利得４０７が含まれる。図では、ITCBLBLマクロが、
破線によってITCB４０３に接続されている。このマクロ
は、このタスク間制御ブロックの名前を"AMPGAIN"とし
て識別する。このマクロは、第１の変数を"GAIN L"とし
て識別し、この変数の読書性を"RW"として識別する。IT
CBLBLマクロは、第２の変数を"GAIN R"として識別し、
この変数の読書プロトコルを"RW"として識別する。さら
に、ITCBLBLマクロは、第３の変数を"POWER（電力）"と
して識別する。この変数は、"WR"という読書アクセス・
プロトコルを有する。

【０１００】GAIN LおよびGAIN Rの"RW"というアクセス
・プロトコルによって、主タスク（増幅および電力計算
タスク３９９）が、ITCB４０３から変数GAIN LおよびGA
IN Rを読み取れることが識別される。このアクセス・プ
ロトコルによって、副タスク（非開示のタスク）が、変
数GAIN LおよびGAIN Rの位置に変数を書き込み可能であ
ることも識別される。この形で、ユーザは、マルチメデ
ィア・ソフトウェア・アプリケーション制御タスクを有
することができ、このタスクは、利得を修正するため
に"GAIN L"と"GAIN R"に変数を書き込むことができる。
これらの変数は、増幅および電力計算タスク３９９によ
って使用され、データ通信モジュール３９７によって提
供されるデータ・ストリームの増幅をもたらす。たとえ
ば、GAIN LとGAIN Rを２にセットする場合、増幅および
電力計算タスク３９９の受け取るデータの値が、２倍に
増幅される。副タスク（すなわち、非開示のタスク）
は、変数GAIN LおよびGAIN Rに変数を書き込むことがで
き、したがって、これらをより高い値またはより低い値
に修正して、増幅および電力計算タスク３９９の利得を
修正することができる。

【０１０１】その名前が暗示するとおり、増幅および電
力計算タスク３９９は、データ通信モジュール４０１に
供給される信号の電力出力を計算する。この電力変数４
１１は、周期的に変数"POWER"に書き込むことによっ
て、副タスクに通信することができる。電力値が変化す
る際に、その変更が変数"POWER"の修正によって反映さ
れる。この例によって示されるように、ITCBLBLマクロ
によって、読み書きアクセス・プロトコルが決定され、
このプロトコルによって、主タスクと副タスクのどちら
が変数に書き込めるかと、主タスクと副タスクのどちら
が変数から読み取れるかが決定される。

【０１０２】図３４に示されるように、本発明のデータ
通信モジュールとタスク間制御ブロックを使用して、デ
ータのストリームの位相特性を変更することができる。
図からわかるように、データ通信モジュール４１３は、
ストリーム化データを位相遅延タスク４１５に向け、位
相遅延タスク４１５は、所定の量と可変量の位相遅れを
導入する。位相遅延タスク４１５は、ストリーム化デー
タ出力を作り、このストリーム化データ出力は、データ
通信モジュール４１７に向けられ、データ通信モジュー
ル４１７は、直接または間接的に、ステレオ出力にスト
リーム化データ出力を供給する。タスク間制御ブロック
（ITCB）４１９によって、位相遅延タスク４１５をもう
１つの（非開示の）タスクに結合する。"PHASE（位
相）"変数４２１が、ITCB４１９によって、具体的にはI
TCBLBLマクロ４２３によって定義され、このITCBLBLマ
クロ４２３によって、ITCB４１９に"PHASEDELAY（位相
遅延）"という名前を付け、"RW"としてアクセス・プロ
トコルを定義する。このプロトコルによれば、主タスク
は、"PHASE"変数４２１の値を読み取ることができ、副
タスクは、"PHASE"変数４２１に値を書き込むことがで
きる。位相遅延タスク４１５が「主」タスクの場合、"P
HASE"変数４２１の値を読み取ることはできるが、それ
に書き込むことはできない。この形で、ユーザが、モジ
ュラー・マルチメディア・ソフトウェア・タスクまたは
マルチメディア末端装置からの特定のデータストリーム
出力のどれに対しても、選択された量の位相遅れを導入
したり除去することができるマルチメディア・アプリケ
ーションを構築できる。この動作は、位相遅延タスクの
知的使用を介してマルチメディア・アプリケーションの
厄介な位相遅れを除去するという利点を有する。したが
って、同期化の問題も、完全に回避することができる。

【０１０３】図３からわかるように、DSPマネージャ７
１は、ホストCPUに常駐し、ディジタル信号プロセッサ
３７（図２）へのモジュラー・マルチメディア・ソフト
ウェア・タスクの実行のためのロードを制御するように
動作する。図３５からわかるように、DSPマネージャ７
１は、互いに協力してモジュラー・マルチメディア・ソ
フトウェア・タスクのロードと実行を制御する複数の機
能ブロックからなる。互いに協力するブロックには、デ
ィジタル信号プロセッサ（DSP）パーサ４５１、ディジ
タル信号プロセッサ（DSP）リンク・エディタ４５３、
ディジタル信号プロセッサ（DSP）資源マネージャ４５
５、タスク・ローダ４５７、タスク・マネージャ４５
９、ディジタル信号プロセッサ・マネージャ・アプリケ
ーション・プログラム・インターフェース（DSPMGR AP
I）コントローラ４６１、割込みおよびプロセッサ・コ
ール・バック（IPC）ハンドラ４６３およびディジタル
信号プロセッサBIOS（DSP BIOS）インターフェース４６
５が含まれる。これらの機能ブロックのそれぞれを、図
３６ないし図４３に詳細に示す。

【０１０４】図３５を参照すると、DSPMGR APIコントロ
ーラ４６１は、マルチメディア・アプリケーション５９
からアプリケーション・プログラム・インターフェース
（API）コマンドを受け取り、そのアプリケーション・
プログラム・インターフェース（API）コマンドを適切
な機能ブロックに経路指定する。アプリケーション・プ
ログラム・インターフェース・コマンドには、大別して
５つのカテゴリーがある。カテゴリー１には、DSPMGR A
PIコントローラ４６１とタスク・ローダ４５７の間に向
けられるコマンドが含まれる。APIコマンドのカテゴリ
ー２には、DSPMGR APIコントローラ４６１からタスク・
マネージャ４５９に渡されるコマンドが含まれる。API
コマンドのカテゴリー３には、DSPMGR APIコントローラ
４６１からDSP BIOSインターフェース４６５に渡される
コマンドが含まれる。APIコマンドのカテゴリー４に
は、DSPMGR APIコントローラ４６１とIPCハンドラ４６
３の間で渡されるコマンドが含まれる。APIコマンドの
カテゴリー５には、状況その他の情報をDSPマネージャ
７１に提供する、ハウスキーピングやデバッグ動作に特
に有用であるが、本発明を完全に理解するためには特に
重要ではないコマンドが含まれる。

【０１０５】図４７は、ホストCPUに常駐するDSPマネー
ジャ７１がディジタル信号プロセッサ３７の動作を調整
し制御できるようにするAPIコマンドの５つの大まかな
カテゴリーを識別する表である。図４７を参照すると、
カテゴリー１のコマンドには、dsp allocate seg（DSP
セグメント割振り）、dsp initiation（DSP開始）、dsp
load module（DSPモジュール・ロード）、dsp load ta
sk（DSPタスク・ロード）およびdsp load thread（DSP
スレッド・ロード）が含まれる。dsp allocate segは、
ディジタル信号プロセッサに特定のタスクのためにメモ
リを確保するよう命令するコマンドである。dsp initia
tionは、レジスタをクリアし、プロセッサをリセット
し、オペレーティング・システムをロードすることによ
って、ディジタル信号プロセッサを初期設定するコマン
ドである。dsp load moduleは、選択されたタスクのモ
ジュール（図１０参照）をロードするコマンドである。
dsp load taskは、ディジタル信号プロセッサに、単一
のタスクを構成するデータ・セグメントと命令セグメン
トをロードするよう命令するコマンドである。dsp load
threadは、実行のために単一のスレッド（すなわち、命
令またはデータもしくはその両方の小さなブロック）を
ロードするよう命令するコマンドである。図３５からわ
かるように、カテゴリー１のコマンドは、DSPMGR APIコ
ントローラ４６１からタスク・ローダ４５７に渡され
る。その詳細を図４３に示す。

【０１０６】図４３からわかるように、タスク・ローダ
４５７には、制御ファイル４７３が含まれ、この制御フ
ァイル４７３が、APIを受け取り、必要に応じてさまざ
まな他のファイルを呼び出す。モジュール・ロード・フ
ァイル４６７は、タスクのモジュールをディジタル信号
プロセッサにロードするタスクを実行する。タスク・ロ
ード・ファイル４６９は、実行のため特定のタスクをデ
ィジタル信号プロセッサにロードする。スレッド・ロー
ド・ファイル４７１は、実行のため特定のスレッドをデ
ィジタル信号プロセッサにロードする。

【０１０７】セグメント割振りファイル４７５は、特定
のタスクの受け取りのためにメモリの特定の部分を割り
振る。マネージャ初期設定ファイル４７７は、ディジタ
ル信号プロセッサを選択的に初期設定する。モジュール
・ロード・ファイル４６７、タスク・ロード・ファイル
４６９およびスレッド・ロード・ファイル４７１は、DS
Pパーサ４５１、DSPリンク・エディタ４５３およびDSP
資源マネージャと通信し、協力する。これらのすべて
を、下で説明する。データ・イメージ・ロード・ブロッ
ク４７９、コード・イメージ・ロード・ブロック４８１
および制御ブロック４８３は、互いに協力して、タスク
・マネージャ４５９（図４１）に、ディジタル信号プロ
セッサへのロードのためにDSP BIOSインターフェース４
６５を介して渡さなければならないデータ、命令および
制御パラメータを供給する。

【０１０８】図４７からわかるように、APIコマンドの
カテゴリー２には、１１個の異なるコマンドが含まれ
る。これらのコマンドのすべてが、DSPMGR APIコントロ
ーラ４６１からタスク・マネージャ４５９に通信され
る。dsp change CPF（DSP CPF変更）コマンドを使用す
ると、特定のタスクに割り振られるディジタル信号プロ
セッサの毎秒サイクル数（CPF）を変更できる。dsp cha
nge DMA（DSP DMA変更）コマンドを使用すると、直接メ
モリ・アクセス動作のために割り振られるメモリ資源の
量を変更できる。DSP change module state（DSPモジュ
ール状態変更）コマンドを使用すると、複数のマルチメ
ディア・ソフトウェア・タスクのモジュラー・グループ
化の状態を変更できる。使用可能な状態には、"active
（活動）"、"standby（待機）"および"inactive（非活
動）"が含まれる。"active"タスクとは、ロード時に即
座にディジタル信号プロセッサによって実行されるタス
クである。"standby"タスクとは、ディジタル信号プロ
セッサへのロードの後に、待ち行列化され、しばらく実
行を待つタスクである。"inactive"タスクとは、"stand
by"状態でも"active"状態でもないタスクである。dsp c
hange task（DSPタスク変更）コマンドを使用すると、
単一のマルチメディア・ソフトウェア・タスクの状態
を"active"、"standby"および"inactive"状態の間で変
更できる。

【０１０９】dsp connect DCM（DSP DCM接続）コマンド
を使用すると、特定のデータ通信モジュールを特定のタ
スクまたは特定のマルチメディア末端装置もしくはその
両方に接続できる。dsp connect ITCB（DSP ITCB接続）
コマンドを使用すると、主タスクと副タスクの間でタス
ク間制御ブロックを接続できる。dsp disconnect DCM
（DSP DCM切断）コマンドを使用すると、データ通信モ
ジュールを切断でき、dspdisconnect ITCB（DSP ITCB切
断）コマンドを使用すると、タスク間制御ブロックを切
断できる。dsp free module（DSPモジュール解放）、ds
p free task（DSPタスク解放）およびdsp free thread
（DSPスレッド解放）コマンドは、それぞれ、タスクの
１モジュール、単一のタスクまたは単一のスレッドの実
行を停止させ、前にこれらのために確立されたデータ通
信モジュール、タスク間制御ブロックおよび直接メモリ
・アクセス接続から切断するコマンドである。

【０１１０】図３５からわかるように、DSPMGR APIコン
トローラ４６１は、カテゴリー２のコマンドをタスク・
マネージャ４５９に通信する。これを、図４１にブロッ
ク図形式で詳細に示す。ここで図４１を参照すると、制
御ブロック４８７が、DSPMGRAPIコントローラ４６１か
らAPIコマンドを受け取り、これらを、ディジタル信号
プロセッサ内のタスクの管理に関連する特定のタスクを
実行するのに適切なモジュールおよびファイルに経路指
定する。図からわかるように、モジュール、タスクまた
はスレッドの解放を必要とするコマンドは、モジュール
解放ファイル４８９、タスク解放ファイル４９１および
スレッド解放ファイル４９３のうちの適切なファイルに
経路指定される。同様に、モジュールおよびタスクの状
態変化を必要とするAPIコマンドは、モジュール状態変
更ファイル５０５およびタスク状態変更ファイル５０７
のうちの適切なファイルに経路指定される。サイクル毎
フレームの変更を必要とするコマンドは、サイクル毎フ
レーム変更ファイル５０１に渡される。データ通信モジ
ュール、直接メモリ・アクセスまたはタスク間制御ブロ
ックの接続または切断を必要とするAPIコマンドは、DCM
制御ファイル４９７、DMA制御ファイル５０３およびITC
B制御ファイル５１１のうちの適切なファイルに経路指
定される。サイクル毎フレームの変更を要求するAPIコ
マンドは、フレーム・マネージャ制御ファイル４９５に
経路指定される。DCM制御ファイル４９７とフレーム・
マネージャ制御ファイル４９５は、ディジタル信号プロ
セッサBIOSを介して渡される前に、ディジタル信号プロ
セッサ・オペレーティング・システム制御ファイル４９
９を通るように経路指定されることに留意されたい。

【０１１１】図４７からわかるように、APIコマンドの
カテゴリー３には、３つのコマンドが含まれる。dsp Me
mtransfer（DSPメモリ転送）コマンドは、データと命令
をデータ・メモリ４３と命令メモリ４１（共に図２）に
書き込むことができるか、そこから読み取ることができ
るかを判定するコマンドである。dsp Reset（DSPリセッ
ト）コマンドは、ディジタル信号プロセッサを停止さ
せ、ロケーション・カウンタを０にリセットするコマン
ドである。dsp Run（DSP走行）コマンドは、プロセッサ
の走行を開始するコマンドである。図３５からわかるよ
うに、これらのコマンドは、DSPMGR APIコントローラ４
６１とDSP BIOSインターフェース４６５の間で通信され
る。その詳細を、ブロック図形式で図３９に示す。

【０１１２】ここで図３９を参照すると、DSP BIOSイン
ターフェース４６５には、互いに協力してAPIコマンド
が要求したタスクを実行する複数のブロックまたはファ
イルが含まれる。すべてのAPIコマンドが、制御ブロッ
ク５１３によって受け取られる。メモリ転送に関連する
APIコマンドは、メモリ転送ブロック５１５に向けられ
る。命令の読取を必要とする動作は、命令読取ファイル
５１７に経路指定される。命令の書込を必要とする動作
は、命令書込ファイル５１９に経路指定される。データ
の読取を必要とする動作は、データ読取ファイル５２１
に向けられる。データの書込を必要とする動作は、デー
タ書込ファイル５２３に向けられる。読取機能と書込機
能のすべてが、入出力読書制御ブロック５３５を介して
実行される。プロセッサのリセットを要求するAPI命令
は、プロセッサ・リセット・ファイル５２５に向けられ
る。プロセスの走行開始を要求するAPI命令は、プロセ
ッサ走行ファイル５２７に経路指定される。図３９から
わかるように、カテゴリー５タイプのコマンドのうち、
ディジタル信号プロセッサの能力に関して問い合わせる
コマンドは、ディジタル信号プロセッサの構成と能力を
判定するためにDSPBIOSインターフェース４６５を介し
て照会能力５２９に経路指定される可能性がある。図３
９では、DSP BIOSインターフェース４６５が、割込みハ
ンドラ・ファイル５３３を介して割込みを受け取ること
ができ、この割込みハンドラ・ファイル５３３は、割込
みハンドラ導入ファイル５３１によって確立される。割
込みハンドラ・ファイル５３３は、IPCハンドラ４６３
に経路指定されるコールバックを生成する。IPCハンド
ラ４６３は、図３５に示され、図３７にブロック図形式
で詳細に示されている。

【０１１３】ここで図３７を参照すると、IPCハンドラ
４６３が、協力してIPCハンドラ４６３のタスクを実行
する機能ブロックおよびファイルとして図示されてい
る。割込み元タスク識別ブロック５３７が、実際に割込
みを受け取り、割込みレジスタ５４９をアクセスして、
特定の割込みに対して識別される特定のユーザ・コール
バックを判定する。割込みレジスタ５４９に示されてい
るように、割込みレジスタには、各ビットが要求された
特定のコールバックを表す１６ビット・ワードが含まれ
る。１つまたは複数の割込みを同時に活動状態にするこ
とができるが、割込みのそれぞれについて１つのユーザ
・コールバックの生成が必要である。DSPマネージャ
は、１時に１ビットずつ１６ビット・ワード内をサイク
ルし、割込みとそれに対応するユーザ・コールバックの
それぞれに個別に対処する。コールバック検証ファイル
５３９は、割込み元タスク識別ブロック５３７とコール
バック・ディスパッチ・ファイル５４１の両方と通信す
る。コールバック・ディスパッチ・ファイル５４１は、
実際にユーザ・コールバック信号を生成する。IPC検証
ファイル５４７は、dsp connect IPC（DSP IPC接続）と
dsp disconnect IPC（DSPIPC切断）を含む２種類のAPI
コマンドを受け取る。dsp connect IPCコマンドによっ
て、IPCハンドラ４６３が接続され、dsp disconnect IP
Cコマンドによって、IPCハンドラ４６３が切断される。
IPC検証ファイル５４７は、コールバック・セット・フ
ァイル５４５およびコールバック・クリア・ファイル５
４３と通信する。コールバック・セット・ファイル５４
５は、特定の割込みのために特定のコールバックを確立
するのに使用される。コールバック・クリア・ファイル
５４３は、前の割込みとコールバックの配置を無効化
し、割込みとコールバックのプロトコルを再構成できる
ようにする。

【０１１４】図３６は、DSPMGR APIコントローラ４６１
の詳細なブロック図である。図からわかるように、API
制御ブロック５７９は、ディジタル信号プロセッサ・マ
ネージャからAPIコマンドを受け取り、これを適切なタ
スク・ブロックに経路指定する。カテゴリー５のコマン
ドは、API制御ブロック５７９によって情報照会ブロッ
ク５８１に向けられる。ここで図４７を参照すると、カ
テゴリー５のコマンドには、「ハウスキーピング」コマ
ンドとみなすことのできる複数のコマンドが含まれる。
dsp abilities（DSP能力）コマンドは、そのコマンドが
行われた時点でどの資源を使用可能であるかを判定する
コマンドである。dsp label to addressコマンドは、メ
モリ転送をセットアップできるようにするためにドライ
バによってDSPマネージャに対して行われる呼出しであ
る。dsp name to module handleコマンド、dsp name to
task handleコマンドおよびdsp name to thread handl
eコマンドは、図３のTAMドライバ６３、サウンド・ドラ
イバ６５、モデム・ドライバ６７および他のディジタル
信号処理ドライバ６９と図３のDSPマネージャ７１の間
でのモジュール・レベル、タスク・レベルまたはスレッ
ド・レベルでの通信を容易にするコマンドであり、通常
のコマンドである。dsp query（DSP照会）コマンド、ds
p info（DSP情報）コマンド、dsp query manager info
（DSPマネージャ情報照会）コマンド、dsp query modul
e info（DSPモジュール情報照会）コマンドおよびdsp m
iscellaneous info（DSP雑情報）コマンドは、ディジタ
ル信号プロセッサ、DSPマネージャおよび選択されたモ
ジュールに関係する情報の転送に使用されるコマンドで
ある。これらの照会は、トラブルシューティングとハウ
スキーピング動作に特に有用である。

【０１１５】図３５のDSPマネージャ７１を用いると、
ディジタル信号プロセッサ資源の動的でリアルタイムな
連続的管理が可能になり、その結果、モジュラー・マル
チメディア・ソフトウェア・タスクの動的または一時的
なオーバーラップするロードと解放が可能になる。従来
技術では、他のマルチメディア・ソフトウェア・タスク
が実行されている間に特定のマルチメディア・ソフトウ
ェア・タスクをロードまたは解放することが不可能であ
った。これが本発明によって実現される。

【０１１６】図４２からわかるように、DSP資源マネー
ジャ４５５には、ディジタル信号処理資源を独立に管理
する複数のソフトウェア・ファイルが含まれる。ハード
ウェア使用可能度管理ファイル５６５は、マルチメディ
ア末端装置と他の周辺装置の使用可能度を管理する。命
令記憶域管理ファイル５６７は、図２の命令メモリ４１
での命令の記憶を独立に管理する。データ記憶域管理フ
ァイル５６９は、図２のデータ・メモリ４３でのデータ
の記憶を独立に管理する。命令記憶域管理ファイル５６
７とデータ記憶域管理ファイル５６９から、常に、マル
チメディア・ソフトウェア・タスクによって要求された
命令メモリ４１とデータ・メモリ４３内のメモリの量
と、追加のモジュラー・マルチメディア・ソフトウェア
・タスクがディジタル信号プロセッサにロードされる時
にデータと命令の受け取りのために使用可能な命令メモ
リとデータ・メモリの量とがわかる。サイクル毎秒管理
ファイル５７１は、ディジタル信号プロセッサの消費さ
れたサイクル毎秒と使用可能サイクル毎秒を継続的に監
視する。このファイルから、常に、ディジタル信号プロ
セッサによって実行されているタスクが消費する毎秒サ
イクル数ならびに使用可能な毎秒サイクル数がわかる。
十分な毎秒サイクルが使用可能でない限り、モジュラー
・マルチメディア・ソフトウェア・タスクを実行のため
ディジタル信号プロセッサにロードすることはできな
い。

【０１１７】次に、直接メモリ・アクセス管理ファイル
５７５は、直接メモリ・アクセス動作専用のディジタル
信号プロセッサ資源を管理する。具体的に言うと、直接
メモリ・アクセス管理ファイル５７５によって、直接メ
モリ・アクセス動作専用にされた命令メモリ４１とデー
タ・メモリ４３のメモリの量が判定される。十分な資源
が使用可能でない限り、他の直接メモリ・アクセス・タ
スクは許可されない。IPC管理ファイル５７７は、使用
可能な割込みの割振りを継続的に監視する。使用可能で
ない割込みを必要とするモジュラー・マルチメディア・
タスクは、ディジタル信号プロセッサにロードされな
い。最後に、バス帯域幅管理ファイル５７３は、主デー
タ通信バスと命令通信バスの活動のレベルを判定し、特
定のタスクがバスの過度の使用を要求するかどうかを判
定する。

【０１１８】ディジタル信号処理管理プログラムによっ
て実現される重要な長所は、（１）このシステムを用い
ると、モジュラー・マルチメディア・ソフトウェア・タ
スクを、ディジタル信号プロセッサによって実行中の他
のモジュラー・マルチメディア・タスクに割り込まずに
開始でき、終了できることと、（２）そのモジュラー・
マルチメディア・タスクをディジタル信号プロセッサに
よる並行実行に特に適合させる必要がないことである。
この結果は、DSPマネージャ７１を使用して、ディジタ
ル信号プロセッサにロードされる可能性のあるタスクの
受入れと実行に関してディジタル信号プロセッサの能力
を動的に判定することによって達成される。この処理
は、図３５と図４８を同時に参照することによって最も
よく理解できる。この処理は、ブロック５９１から始ま
る。ブロック５９３で、マルチメディア・アプリケーシ
ョンによってDSPマネージャ７１にAPIロード・コマンド
が供給される。このコマンドは、複数のモジュラー・マ
ルチメディア・ソフトウェア・タスク、単一のモジュラ
ー・マルチメディア・ソフトウェア・タスクまたは単一
の実行スレッドからなるモジュールを、ディジタル信号
プロセッサによる実行のためにディジタル信号プロセッ
サへロードするよう要求するコマンドである。ブロック
５９５で、ディジタル信号プロセッサへのロードを要求
されたタスクまたはモジュールを、DSPパーサ４５１が
受け取り、図３８に示されるように解析する。図３８に
よれば、ファイルは、ファイル読取バッファに読み込ま
れ（ブロック５８３）、ブロック５８５で、さまざまな
通常の「チャンク」または「テーブル」に解析される。
図３８のブロック５８７で、DSPパーサ４５１が、解析
された要素のために必要なデータ構造を作成する。

【０１１９】図４８に戻って、ブロック５９７で、ディ
ジタル信号プロセッサへのロードを要求された解析済み
のタスクまたはモジュールを、タスク・ローダ４５７に
よって検査して、その「要件」を判定する。要件は、タ
スクまたはモジュールが要求する命令メモリおよびデー
タ・メモリの量、タスクまたはモジュールによって実行
時に消費される毎秒サイクル数、タスクまたはモジュー
ルが（データ通信モジュールを介して）読み書きする接
続の個数、および、タスクまたはモジュールの実行中に
必要になる割込みがあれば、その割込みの個数である。

【０１２０】ブロック５９９で、図４２に示されたDSP
資源マネージャ４５５に相談して、タスクまたはモジュ
ールのロードが可能であるかどうかを判定する。図４２
に示されるように、DSP資源マネージャ４５５には、ハ
ードウェア使用可能度、命令メモリ使用可能度、データ
・メモリ使用可能度、サイクル毎秒使用可能度、バス帯
域幅使用可能度、割込みベクトル使用可能度および直接
メモリ・アクセス資源使用可能度を独立に監視する別々
のファイルが含まれる。ハードウェア使用可能度管理フ
ァイル５６５は、マルチメディア末端装置の使用可能度
を継続的に監視し、これらのマルチメディア末端装置
が、ディジタル信号プロセッサが実行中の他のモジュラ
ー・マルチメディア・ソフトウェア・タスクによって使
用されているかどうかの表示を提供する。命令記憶域管
理ファイル５６７は、ディジタル信号プロセッサが実行
中のモジュラー・マルチメディア・ソフトウェア・タス
クによって使用されている命令メモリの量を継続的に監
視し、また、ディジタル信号プロセッサへのロードのた
めに要求される可能性のある、モジュラー・マルチメデ
ィア・ソフトウェア・タスクのために使用可能な命令メ
モリの総量を継続的に判定する。

【０１２１】次に、データ記憶域管理ファイル５６９
は、データ・メモリを継続的に監視して、ディジタル信
号プロセッサが実行中のモジュラー・マルチメディア・
ソフトウェア・タスクによって現在使用されているデー
タ・メモリの総量を判定する。また、データ記憶域管理
ファイル５６９は、実行のためディジタル信号プロセッ
サへのロードのために要求される可能性のある、ファイ
ルに使用可能なデータ・メモリの総量を継続的に監視す
る。サイクル毎秒管理ファイル５７１は、ディジタル信
号プロセッサが実行中のモジュラー・マルチメディア・
タスクによって消費されつつあるディジタル信号プロセ
ッサのサイクル毎秒を継続的に監視する。サイクル毎秒
管理ファイル５７１は、実行のためディジタル信号プロ
セッサにロードされる可能性がある他のモジュラー・マ
ルチメディア・ソフトウェア・タスクのために使用する
ことのできる総使用可能サイクル毎秒の表示を継続的に
提供する。バス帯域幅管理ファイル５７３は、ディジタ
ル信号プロセッサ内のデータ・バスの使用可能度を継続
的に監視し、ディジタル信号プロセッサのバス容量の現
在表示を提供して、追加のモジュラー・マルチメディア
・タスクを実行のためディジタル信号プロセッサにロー
ドすることができるかどうかの判定を可能にする。IPC
管理ファイル５７７は、割込みベクトルの割振りと使用
可能度を継続的に監視する。

【０１２２】図２７に示されるように、好ましいディジ
タル信号プロセッサには、専用の割込みレジスタが含ま
れ、この割込みレジスタを用いて、ディジタル信号プロ
セッサが実行中のさまざまなモジュラー・マルチメディ
ア・タスクによって１６個の異なる割込みベクトルを使
用できる。ディジタル信号プロセッサが同時に１６個の
モジュラー・マルチメディア・ソフトウェア・タスクを
実行しており、各タスクが１つの割込みベクトルを必要
とする場合、割込みベクトルの使用を必要とする追加の
モジュラー・マルチメディア・ソフトウェア・タスクを
ディジタル信号プロセッサにロードすることはできな
い。もちろん、割込みベクトルの使用を必要としないタ
スクであれば、ディジタル信号プロセッサに追加のモジ
ュラー・マルチメディア・ソフトウェア・タスクをロー
ドして実行できる。

【０１２３】図４８と図３５に戻ると、DSP資源マネー
ジャ４５５に相談して、ハードウェア使用可能度、命令
メモリ使用可能度、データメモリ使用可能度、サイクル
毎秒使用可能度、バス帯域幅使用可能度、直接メモリ・
アクセス使用可能度および割込みベクトル使用可能度に
関する現在の資源割振りと使用可能度を考慮して、タス
クまたはモジュールのロードが可能であるかどうかを判
定する。特定のモジュラー・マルチメディア・ソフトウ
ェア・タスクが、ディジタル信号プロセッサへのロード
のためにマルチメディア・アプリケーション・ソフトウ
ェアによって呼び出される場合、そのタスクは、使用可
能資源またはディジタル信号プロセッサを超えてはなら
ない。たとえば、特定のモジュラー・マルチメディア・
ソフトウェア・タスクによって操作されるマルチメディ
ア末端装置が使用可能であり、十分な命令メモリとデー
タ・メモリの空間が使用可能であるが、十分なディジタ
ル信号プロセッサ・サイクル毎秒が使用可能でない場
合、そのタスクは、ディジタル信号プロセッサにロード
されない。

【０１２４】別の例として、特定のモジュラー・マルチ
メディア・ソフトウェア・タスクが、ディジタル信号プ
ロセッサへのロードを要求されたが、そのディジタル信
号プロセッサが実行中の他のモジュラー・マルチメディ
ア・ソフトウェア・タスクによって１６個の割込みベク
トルのすべてが現在使用されている場合、このロード動
作は許可されない。ロードが許可されると判定される場
合、そのタスクまたはモジュールは、ブロック６０１で
DSPリンク・エディタ４５３に送られて、モジュール・
フィックスアップ・ブロック５５３（図４０）、タスク
・フィックスアップ・ブロック５５５およびセグメント
（またはスレッド）フィックスアップ・ブロック５５７
での「フィックスアップ」動作を行って、ブロック５５
９およびブロック５６１によるデータ・メモリおよび命
令メモリへの書込を可能にする。ブロック６０３で、タ
スクまたはモジュールをDSPの命令メモリとデータ・メ
モリにロードする。

【０１２５】この形で、単一のディジタル信号プロセッ
サに、ディジタル信号プロセッサ資源の使用可能度だけ
を考慮して、さまざまなモジュラー・マルチメディア・
ソフトウェア・タスクをロードすることができる。この
特徴の結果として、モジュラー・マルチメディア・ソフ
トウェア・タスクは、他のモジュラー・マルチメディア
・ソフトウェア・タスクの存在または実行を考慮に入れ
るように構成、修正または配置する必要がない。これに
よって、単一のディジタル信号プロセッサによって同時
にロードし実行することのできる完全に独立なマルチメ
ディア・アプリケーションをエンド・ユーザが作成でき
るオープン・アーキテクチャがもたらされる。このオー
プン・アーキテクチャと設計のモジュール性によって、
複数のディジタル信号プロセッサを「ネットワーク化」
して、複数のモジュラー・マルチメディア・タスクの実
行を共用することも可能になる。図４９に示されるよう
に、N個のディジタル信号プロセッサを、単一のDSPマネ
ージャと通信状態にすることができる。図からわかるよ
うに、ディジタル信号プロセッサ６１１、ディジタル信
号プロセッサ６１３、ディジタル信号プロセッサ６１５
およびディジタル信号プロセッサ６１７は、並列に動作
して、複数のモジュラー・マルチメディア・ソフトウェ
ア・タスクを実行することができる。

【０１２６】複数のディジタル信号プロセッサを、DSP
マネージャ７１などの単一のDSPマネージャと共に使用
する時、DSPマネージャは、ディジタル信号プロセッサ
のうちの特定の１つにタスクをロードしようと試みる。
あるディジタル信号プロセッサが、特定のモジュールま
たはタスクのロードに使用できない場合、DSPマネージ
ャ７１は、次のディジタル信号プロセッサへのロードを
試みる。このディジタル信号プロセッサが十分な資源を
有しない場合、DSPマネージャは、さらに別のディジタ
ル信号プロセッサへのロードを試みる。この処理は、DS
Pマネージャ７１によってロードを要求されたタスクま
たはモジュールを受け入れるのに十分な資源を有する使
用可能なディジタル信号プロセッサが見つかるまで繰り
返される。これによって、既存のシステムに多数のディ
ジタル信号プロセッサを追加して、マルチメディア・ア
プリケーションの処理能力を高めることができる、設計
のモジュール性ももたらされる。

【０１２７】ここで図５０を参照すると、タスクをロー
ドする処理が示されており、このシステムは、ブロック
７０１でパワー・アップされる。その後、ブロック７０
３で、DSPの個数を判定する。この処理では、まずその
システムで何個のDSPが使用可能であるかを判定し、し
たがって、どれだけの資源を使用しなければならないか
を判定できるようにする。各DSPは、バス上にそれ自体
の入出力アドレス範囲を有するので、各アドレスを照会
してDSPが存在するかどうかを調べるのは簡単である。
ブロック７０５で、DSPを初期設定する。この処理は、
周知であり、単に、コマンドおよびタスクのロードの前
置きとして全レジスタ値のリセットと全メモリのクリア
を行うだけである。次に、ブロック７０７で、メモリか
らロードする機能を識別する。アプリケーション・プロ
グラムは、そのAPI（アプリケーション・プログラム・
インターフェース）を介して、DSPに機能をロードする
ようDSPマネージャに伝える。「機能」は、複数の「タ
スク」から構成される。その後、ブロック７０９で、シ
ステム・メモリからロードするタスクを識別する。機能
は複数のタスクから構成されるので、アプリケーション
は、DSPにロードする必要がある所与の機能の最初のタ
スクを識別する。ブロック７１１で、タスク平衡化を実
行して、タスクの行き先を決定する。タスク間のリンケ
ージ要件（データ通信モジュール（DCM)の個数とサイ
ズ）およびタスクを分散できるかどうか（タイミング要
件に基づく）と、さまざまな入出力インターフェースの
使用可能度および接続位置と、残っているDSP命令メモ
リ量およびデータ・メモリ量と、各DSP上でまだ使用可
能なMIPS（百万命令毎秒）の量と、通信方法と、システ
ム上で使用可能な資源とを、本発明の好ましい実施例に
従って考慮に入れることができる。"MIPS"は、処理能力
の尺度である。

【０１２８】DSP間通信は、選択された複数DSPアーキテ
クチャに応じて複数の方法によって達成できる。DSPが
互いに通信するための方法として、直列ポート、局所化
された相互接続バスまたは共用メモリのどれが使用され
るかに基づいて、異なる資源値が見つかる。これらの異
なる方法のそれぞれが、それ自体の伝送特性と動作方式
を有するので、全体的なアルゴリズムは、どのシステム
を使用するかに基づいて変化する可能性がある。本発明
の独自の態様は、システム特性またはサブシステム特性
がさまざまな負荷に伴って変化するにつれて、タスクの
配分を変更でき、必ずタスクの最適配置がもたらされる
ことである。タスク平衡化は、下で図５１に示された流
れ図を参照して詳細に説明する。

【０１２９】次に、ブロック７１３で、ホストのメモリ
・マップとタスク・マップを編成する。このブロックで
は、DSPマネージャが各タスクの記憶位置と使用位置の
情報を示すことによって、メモリ・マップを構築する。
各タスクは、アプリケーション作者によって、本発明の
好ましい実施例に従って、MIPS、メモリ必要量、使用す
る割込みおよびチャネルの既知の値を用いて事前定義さ
れている。ブロック７１５で、タスクを適切なDSPにダ
ウンロードする。下記の図５１のタスク平衡化処理がこ
のタスクをどこに置くよう命ずるかに基づいて、その作
業を実行するDSPの命令メモリおよびデータ・メモリに
タスクをダウンロードする。その後、ブロック７１７
で、DCMとITCBのためのDSPデータ・メモリを割り振る。
次に、ブロック７１９で、特定のデーモンを適切なDSP
にダウンロードする。デーモンは、通信チャネルを介す
るDSP間通信の実現に使用される。デーモンは、DCMのポ
インタも更新するが、これについては上で説明した。こ
のブロック７１９では、他のデータがDCM用の空間を上
書きしないように、DCM用の空間を記憶する。この時点
で、命令プログラムがロードされており、相互通信デー
モンが特性設定され、位置をロードされており、メモリ
がマップに割り振られている。この時点で、システムは
動作の準備が調っている。その後、ブロック７２１で、
別のタスクをロードするかどうかの判定を行う。すべて
のタスクをロードするまで、ブロック７０９へのループ
・バックを継続する。すべてのタスクをロードした後に
は、ブロック７２３で機能を走行させる。機能は複数の
タスクから構成されるので、機能を走行させる前に他の
タスクをロードする必要があるかどうかを調べることが
適切である。ブロック７２５で、追加の機能をロードし
なければならないかどうかの判定を行う。追加の機能を
ロードする必要がなくなるまで、ブロック７０７に戻
る。ブロック７２５で、ユーザ入力を検査して、ユーザ
が動作前または動作中に別の機能の追加を決定したかど
うかを判定する。追加の機能をロードする必要がなくな
った時には、ブロック７２７で、追加のコマンドを待
つ。

【０１３０】ここで図５１を参照すると、「局所化され
た相互接続バス」とも称する「ローカル・バス」によっ
て互いに接続されたDSPのタスク平衡化のための処理の
流れ図が示されている。ブロック７３１で、タスク平衡
化の処理が始まる。DSPマネージャは、アプリケーショ
ン・プログラムによって要求される機能とそれを構成す
るタスクを識別し終えている。この時点で、MIPS、命令
メモリ必要量、データ・メモリ必要量、DCMのタイプお
よびサイズなどのタスクの特性を考慮する。ブロック７
３３で、DCMが他のタスクに接続されるかどうかの判定
を行う。タスクを他のDSPに割り当てられるようになる
前に、DSPが、所与のDSP上に既に配置されているロード
すべきタスクと同一の機能を構成するタスクにDCMを接
続したかどうかを判定することが重要である。他のタス
クと共用しなければならないデータを有しない場合、そ
のタスクはどのDSPに割り当ててもかまわない。他のタ
スクに接続されたDCMがある場合、タスクを特定のDSPに
置く前に、より多くの情報を判定しなければならない。

【０１３１】DCMが他のタスクに接続される場合、ブロ
ック７３５で、これらのDCMがリアルタイムDCMであるか
どうかの判定を行う。リアルタイム接続は、タスクが互
いにすばやく効率的に通信しなければならず、わずかな
通信遅延だけを有する必要があることを意味する。確立
しようとしているDCMがリアルタイムでない場合、通信
チャネル（すなわち、DSPを相互接続するローカル・バ
ス）が、チャネル上の他の活動に割り込まずにこの追加
の通信を成功裡に処理できるかどうかに関する検査を行
う。この判定は、どのタスクがどのDSPに既にロードさ
れているかと、ローカル・バス上でどれほどの通信トラ
フィックが発生するかと、そのチャネル自体の本来の能
力とを知っているDSPマネージャ内で走行する小さいサ
ブルーチンで行われる。DCMがリアルタイムDCMである場
合、ブロック７３７で、DSPに置かれたDCMに基づいて、
DSPを選択する。この処理では、ロードされるタスクと
同一の機能の一部であるタスクに接続されたDCMを含むD
SPを選択する。

【０１３２】次に、ブロック７３９で、このDCM接続を
有するDSP上に十分なMIPSがあるかどうかの判定を行
う。MIPS単位で測定されるプロセッサ・パワーは、複数
の異なる方法で判定できる。Mwave DSPは、Internation
al Business Machines Corporation社とTexas Instrume
nts, Inc.社から入手可能であり、使用可能MIPSに関す
るデータを取得することができるレジスタを有する。そ
の代わりに、各DSP上で最低優先順位のプログラムまた
はタスクとしてデーモンを走行させることができる。こ
のデーモンが走行した時間の量を使用して、使用可能な
MIPSまたは処理能力を示すことができる。これらのデー
モンからのデータは、DSPマネージャが要求を送り、そ
の結果、このデータ要求を、DSPによる処理のためにス
ケジューリングさせることによって要求できる。非常に
大量のタスクまたはタスクの集合が、既に１つのDSPに
置かれている可能性があるので、通信の観点からこれを
行うとしても、別のタスクをロードするために使用可能
な処理能力や処理サイクルが不十分な場合がある。した
がって、このステップは、その可能性を検査するために
必要である。この特定のDCM接続を有するDSP上で十分な
MIPSが使用可能な場合、そのDSP上に十分な命令メモリ
とデータ・メモリが存在するかどうかの判定を、ブロッ
ク７４１で行う。そのDSP上に十分な命令メモリとデー
タ・メモリが存在する場合、ブロック７４２で、このDS
Pをこのタスク用のDSPとして識別する。その後、ブロッ
ク７１４で処理を終了する。

【０１３３】ブロック７３９およびブロック７４１に戻
って、十分なMIPSまたは十分な命令メモリおよびデータ
・メモリが存在しない場合、ブロック７４３で、追加の
データ・フローを扱うのに十分なチャネル資源が使用可
能であるかどうかの判定を行う。この時点で、元々選択
されたDSPにタスクをロードできないので、DSP間チャネ
ルが新しいDCMの通信要件をサポートできるかどうかを
調べるための検査を行う。使用可能なチャネル資源が不
十分な場合、ブロック７４５で、タスクをロードできな
いことを伝えるメッセージをオペレーティング・システ
ムに送る。ブロック７４３に戻って、十分なチャネル資
源を使用できる場合、ブロック７４７で、すべてのDSP
のMIPSを比較し、最大量のMIPSを使用可能なDSPを選択
する。このブロックを実行するのは、接続を必要とする
DCMが存在しないか、DSP間通信を処理するのに十分なチ
ャネル資源が存在するからである。この時点で、すべて
のDSPを比較して、最大の使用可能MIPSが残っているDSP
を調べ、最大の使用可能MIPSが残っているDSPを選択す
る。ブロック７４９で、このDSPにタスクをロードする
のに十分なMIPSが使用可能であるかどうかの判定を行
う。十分なMIPSが存在する場合、ブロック７５１で、こ
のDSPに十分な命令メモリとデータ・メモリが存在する
かどうかの判定を行う。命令メモリとデータ・メモリが
十分な場合、ブロック７５４で、このDSPをそのタスク
用のDSPとして識別し、ブロック７５６で処理を終了す
る。ブロック７５１に戻って、十分な量のMIPSが使用可
能でないか、DSP上に十分な命令メモリおよびデータ・
メモリが存在しない場合には、ブロック７５３で、他の
DSPが存在するかどうかを判定する。ブロック７４９に
戻って、十分な量のMIPSが使用可能でない場合、ブロッ
ク７４５に進んで、タスクをロードできないことを伝え
るメッセージを送る。

【０１３４】他のDSPが存在しない場合、ブロック７４
５で、タスクをロードできないことを伝えるメッセージ
をオペレーティング・システム送る。他のDSPが存在す
ると、ブロック７５７で、次に大きい使用可能MIPSを有
するDSPが選択されることになる。その後、処理はブロ
ック７４９に戻る。ブロック７３５に戻って、リアルタ
イムDCMが存在しない場合、ブロック７５９で、このタ
スクを別のDSPに置いた場合に十分なチャネル帯域幅が
存在するかどうかを判定する。接続するDCMがリアルタ
イムではなく、DSPと他のすべてのトラフィックの間の
通信を扱うのに十分なチャネル帯域幅がある場合、どの
DSPがこのタスクの走行に最適であるかを判定する部分
のコードに移る。十分なチャネル帯域幅がない場合、検
査を行って、このDCMが接続されるタスクを既に有するD
SPにこのタスクをロードできるかどうかを調べる。十分
なチャネル帯域幅が存在する場合、上で述べたように処
理はブロック７３９に進む。十分なチャネル帯域幅が存
在すると、前に述べたように処理がブロック７４７に進
むことになる。ブロック７３３に戻って、DCMが他のタ
スクに接続されない場合、処理は上で述べたブロック７
４７に進む。

【０１３５】ここで図５２を参照すると、前にロードさ
れ走行中の機能を除去するための処理の流れ図が示され
ている。ブロック７７１で、タスクをリストする。タス
クを除去するには、どのタスクが動作中であるか、どの
メモリがそれらのタスクに割り振られているか、どのDC
Mが存在するか、どのDSPにタスクが置かれているかをリ
ストしなければならない。言い換えると、除去しようと
するタスクの明細を知る必要がある。ブロック７７３
で、このリストからの１タスクが、DSPオペレーティン
グ・システム内のフレームから除去され、このタスク
は、フレーム・マネージャ（元のDSPマネージャのサブ
セクション）にこのタスクを無視するように命令するこ
とによって、フレームから除去されなければならない。
このタスクは、今後はこのフレームの活動が走行する時
に処理されなくなる。この処置は、単一DSP環境でも複
数DSP環境でも同一になるはずである。その後、ブロッ
ク７７５で、タスクを停止させ、その後、ブロック７７
７で、DCMとITCBに関するメモリ・マークを除去する。
影響を受けるDCMに関連するメモリの開始点、終了点お
よび中間位置を、データ・メモリから除去し、これによ
ってこれらの位置を他の活動のために解放しなければな
らない。次に、ブロック７７９で、ホストのメモリ・ツ
リーからタスクを除去する。データ・メモリ空間を解放
した後に、このタスクに関連する命令空間も割振り解除
する。この特徴を用いると、DSPマネージャが、DSPのそ
れぞれの作業負荷を監視し、動的に維持できるようにな
る。ブロック７８１で、リスト上に他のタスクがあるか
どうかの判定を行う。通常は１機能について複数のタス
クが存在するので、１時に除去すべきタスクが複数存在
する。他の機能は、タスクが除去されている間であって
も継続する。すべてのタスクが除去されるまで、ブロッ
ク７７３に戻ってこの処理を継続する。その後、ブロッ
ク７８３で処理を停止する。タスクをロードする時に
は、図５０のブロック７０７ないしブロック７２７に記
載の処理に従う。

【０１３６】まとめとして、本発明の構成に関して以下
の事項を開示する。

【０１３７】（１）各機能が少なくとも１つのタスクか
ら構成される、データ処理システム内の複数のディジタ
ル信号プロセッサによる機能の実行を管理するためのデ
ータ処理システムであって、データ処理動作用の中央処
理装置と、前記中央処理装置に接続され、通信チャネル
によって互いに接続された、複数のディジタル信号プロ
セッサと、ディジタル信号プロセッサ・マネージャとを
含み、前記ディジタル信号プロセッサ・マネージャが、
ディジタル信号プロセッサのために存在するプロセッサ
資源を識別するための第１識別手段と、機能がディジタ
ル信号プロセッサにロードされることの表示に応答し
て、前記機能の一部を構成する、ディジタル信号プロセ
ッサにロードされるタスクを識別するための第２識別手
段と、機能が除去されることの表示に応答して、前記機
能の一部を構成する、ディジタル信号プロセッサ上の、
ディジタル信号プロセッサから除去されるタスクを識別
するための第３識別手段と、第１識別手段と、追加され
るタスクを識別する第２識別手段とに応答して、識別さ
れたタスクの実行をサポートするのに十分な資源を有す
るディジタル信号プロセッサを選択するための選択手段
と、選択手段によるディジタル信号プロセッサの選択に
応答して、ディジタル信号プロセッサ上で実行中の別の
機能を構成するタスクのいずれの実行にも割り込まず
に、追加すべきタスクを選択されたディジタル信号プロ
セッサにロードするためのロード手段と、除去すべきタ
スクを識別する第３識別手段に応答して、ディジタル信
号プロセッサ上で実行中の別の機能を構成するタスクの
いずれの実行にも割り込まずに、識別されたタスクをデ
ィジタル信号プロセッサから除去するための除去手段と
を含む前記ディジタル信号プロセッサ・マネージャとを
含むことを特徴とするデータ処理システム。 （２）前記除去手段が、除去すべき識別されたタスクを
フレームから除去する手段と、除去すべき識別されたタ
スクの実行を停止させる手段と、除去すべき識別された
タスクに関連するデータ通信モジュールのそれぞれのメ
モリ・マークを除去する手段と、除去すべき識別された
タスクをメモリ・ツリーから除去する手段とを含むこと
を特徴とする、上記（１）のデータ処理システム。 （３）データ処理システム内の複数のディジタル信号プ
ロセッサによるタスクの実行を管理するための前記デー
タ処理システムであって、データ処理動作用の中央処理
装置と、通信チャネルによって互いに接続され、前記中
央処理装置に接続された、複数のディジタル信号プロセ
ッサと、ディジタル信号プロセッサ・マネージャとを含
み、前記ディジタル信号プロセッサ・マネージャは、デ
ィジタル信号プロセッサによって実行される機能の識別
に応答して、機能の一部を構成するタスクをロードのた
めに識別するための第１識別手段と、機能の一部を構成
するロードされたタスクに接続されたデータ通信モジュ
ールが存在するかどうかを識別するための第２識別手段
と、接続されたデータ通信モジュールの存在の識別に応
答して、接続されたデータ通信モジュールがリアルタイ
ム・データ通信モジュールであるかどうかを判定する第
１判定手段と、リアルタイム・データ通信モジュールの
存在に応答して、識別されたタスクをサポートするのに
十分なプロセッサ資源が、データ通信モジュールを含む
ディジタル信号プロセッサ用に存在するかどうかを判定
するための第２判定手段と、リアルタイム通信モジュー
ルを含む前記ディジタル信号プロセッサ用の十分なプロ
セッサ資源の存在に応答して、識別されたタスクをディ
ジタル信号プロセッサに追加するための追加手段と、リ
アルタイム通信モジュールを含む前記ディジタル信号プ
ロセッサ用の十分なプロセッサ資源の不在またはリアル
タイム・データ通信モジュールの不在のいずれかに応答
して、通信チャネルが追加のデータ通信モジュールをサ
ポートするのに十分な通信資源を有するかどうかを判定
するための第３判定手段と、追加のデータ通信モジュー
ルをサポートするのに十分な通信資源の存在またはデー
タ通信モジュールの不在のいずれかに応答して、識別さ
れたタスクをサポートする能力を有する、最大量のプロ
セッサ資源を有するディジタル信号プロセッサを選択す
るための手段と、ディジタル信号プロセッサの選択に応
答して、選択されたディジタル信号プロセッサに識別さ
れたタスクをロードするための手段とを含む前記ディジ
タル信号プロセッサ・マネージャを含み、１機能を構成
するタスクを、ディジタル信号プロセッサ上で実行中の
別の機能を構成するタスクの実行に割り込まずに、ディ
ジタル信号プロセッサにロードできることを特徴とする
データ処理システム。 （４）ディジタル信号プロセッサからの除去のため、デ
ィジタル信号プロセッサ上で実行中の機能の一部を構成
するタスクを識別するための第４識別手段と、別の機能
を構成するタスクの実行に割り込まずに、ディジタル信
号プロセッサから識別されたタスクを除去するための除
去手段とをさらに含む、上記（３）のデータ処理システ
ム。 （５）前記除去手段が、識別されたタスクを含むフレー
ムから、識別されたタスクを除去するための手段と、識
別されたタスクの実行を終了させるための終了手段と、
データ通信モジュールへのメモリ・マークを除去するた
めの手段と、ホストのメモリ・ツリーから識別されたタ
スクを除去するための手段とを含むことを特徴とする、
上記（４）のデータ処理システム。 （６）各機能が少なくとも１つのタスクからなり、デー
タ処理システムが、複数のディジタル信号プロセッサに
接続された、データ処理動作用の中央処理装置を含み、
ディジタル信号プロセッサが、通信チャネルによって互
いに接続される、データ処理システム内の複数のディジ
タル信号プロセッサによる機能の実行を管理するため
の、データ処理システム内の方法であって、データ処理
システムによって実施される、ディジタル信号プロセッ
サ用に存在するプロセッサ資源を識別するステップと、
機能がディジタル信号プロセッサにロードされることの
表示に応答して、その機能の一部を構成する、ディジタ
ル信号プロセッサにロードされるタスクを識別するステ
ップと、機能が除去されることの表示に応答して、その
機能の一部を構成する、ディジタル信号プロセッサから
除去されるディジタル信号プロセッサ上のタスクを識別
するステップと、プロセッサ資源の識別と追加されるタ
スクの識別とに応答して、識別されたタスクの実行をサ
ポートするのに十分な資源を有するディジタル信号プロ
セッサを選択するステップと、選択ステップによるディ
ジタル信号プロセッサの選択に応答して、ディジタル信
号プロセッサ上で実行中の別の機能を構成するタスクの
いずれの実行にも割り込まずに、選択されたディジタル
信号プロセッサに追加すべきタスクをロードするステッ
プと、除去すべきタスクの識別に応答して、ディジタル
信号プロセッサ上で実行中の別の機能を構成するタスク
のいずれの実行にも割り込まずに、ディジタル信号プロ
セッサから識別されたタスクを除去するステップとを含
む方法。

【０１３８】

【発明の効果】図５０および図５１に示された処理は、
本発明の好ましい実施例によってDSPマネージャ７１に
組み込まれる。本発明は、いずれも米国ニューヨーク州
ArmonkのInternational Business Machines Corporatio
n社の製品であるIBM PS/2コンピュータまたはIBM RISC
SYSTEM/6000コンピュータなどの適当なホスト・プロセ
ッサを使用して実施できる。"RISC SYSTEM/6000"およ
び"PS/2"はInternationalBusiness Machines Corporati
on社の登録商標である。Mwaveにあるディジタル信号プ
ロセッサなどのディジタル信号プロセッサを使用するこ
とができる。Mwaveは、単一ディジタル信号プロセッサ
を使用するマルチメディア・データ・ストリーム処理用
の基板のファミリーである。Mwaveは、International B
usiness Machines Corporation社の登録商標であり、In
ternational Business Machines Corporation社およびT
exas Instruments, Inc.社によって供給される。Mwave
用の現在入手可能なDSPマネージャは、米国マサチュー
セッツ州CambridgeのIntermetrics' Inc.社から入手可
能なMwave Development Tool kit and the User's Guid
eを使用して、複数DSPを管理するように修正することが
できる。

【図面の簡単な説明】

【図１】複数のマルチメディア末端装置に接続され、マ
ルチメディア・アプリケーションの処理に特に適したマ
ルチメディア・データ処理システムを示す絵図である。

【図２】マルチメディア末端装置の動作を制御するマル
チメディア・アプリケーションの実行に利用される主な
ハードウェア構成要素を示すブロック図である。

【図３】マルチメディア・ディジタル信号処理動作の主
なソフトウェア構成要素を示すブロック図である。

【図４】複数のディジタル信号プロセッサの図を含む、
図３の構成要素を示すもう１つのブロック図である。

【図５】ハードウェア・ディジタル信号プロセッサとそ
のそれぞれのインターフェース・ドライバおよびBIOSイ
ンターフェースの図を含む、図３の構成要素を示すもう
１つのブロック図である。

【図６】DSP BIOSインターフェースと複数DSP資源マネ
ージャと図５のインターフェース・ドライバの間でのイ
ンターフェースのステップを示す流れ図である。

【図７】図５のインターフェース・ドライバとDSP資源
マネージャの間の割込み処理のステップを示す流れ図で
ある。

【図８】DSP BIOSドライバの初期設定と複数のDSP BIOS
ドライバのロードのステップを示す流れ図である。

【図９】複数DSP資源マネージャの初期設定のステップ
を示す流れ図である。

【図１０】N個のモジュラー・マルチメディア・ソフト
ウェア・タスクのグループ化を表すモジュールからなる
マルチメディア動作を示すブロック図である。

【図１１】マルチメディア末端装置と専用データ・メモ
リの間でのリアルタイム・データまたは非同期ストリー
ム化データの直接読み書きを示すブロック図である。

【図１２】モジュール化されたオープン・アーキテクチ
ャを得るためのデータ通信モジュールとタスク間制御ブ
ロックの使用を表すブロック図である。

【図１３】モジュール化されたオープン・アーキテクチ
ャを得るためのデータ通信モジュールとタスク間制御ブ
ロックの使用を表すブロック図である。

【図１４】モジュール化されたオープン・アーキテクチ
ャを得るためのデータ通信モジュールとタスク間制御ブ
ロックの使用を表すブロック図である。

【図１５】モジュラー・マルチメディア・ソフトウェア
・タスクとマルチメディア末端装置の間でのデータ転送
のためにデータ通信モジュールを秩序だった形で使用で
きるようにする好ましい動作規則を示す図である。

【図１６】モジュラー・マルチメディア・ソフトウェア
・タスクとマルチメディア末端装置の間でのデータ転送
のためにデータ通信モジュールを秩序だった形で使用で
きるようにする好ましい動作規則を示す図である。

【図１７】モジュラー・マルチメディア・ソフトウェア
・タスクとマルチメディア末端装置の間でのデータ転送
のためにデータ通信モジュールを秩序だった形で使用で
きるようにする好ましい動作規則を示す図である。

【図１８】本発明の好ましい実施例でデータ通信モジュ
ールと共に使用するために確立された４つの標準化通信
プロトコルの１つを表す絵図である。

【図１９】本発明の好ましい実施例でデータ通信モジュ
ールと共に使用するために確立された４つの標準化通信
プロトコルの１つを表す絵図である。

【図２０】本発明の好ましい実施例でデータ通信モジュ
ールと共に使用するために確立された４つの標準化通信
プロトコルの１つを表す絵図である。

【図２１】本発明の好ましい実施例でデータ通信モジュ
ールと共に使用するために確立された４つの標準化通信
プロトコルの１つを表す絵図である。

【図２２】最下位５ビットがデータ通信プロトコルの選
択を表す、１６ビット・ワードを示す図である。

【図２３】オーナー・タスクとユーザ・タスクでの制御
ブロックの作成を示す図である。

【図２４】複数のモジュラー・マルチメディア・ソフト
ウェア・タスクから複数のデータ通信モジュールを介し
て単一のユーザ・タスクに至る、仮想データ通信モジュ
ールの使用を介するデータ・ストリームの通信を表すブ
ロック図である。

【図２５】図２４の仮想データ通信モジュールの動作を
示す、より詳細なブロック図である。

【図２６】複数のモジュラー・マルチメディア・ソフト
ウェア・タスクから単一のCDディジタル・アナログ変換
器への、仮想データ通信モジュールの使用を介するオー
ディオ出力信号の多重化を示すブロック図である。

【図２７】タスク間制御ブロックの動作を示すブロック
図である。

【図２８】同期式プロトコル・モードの動作でのデータ
通信モジュールへの書込タスクを示す流れ図である。

【図２９】同期式プロトコル・モードの動作でのデータ
通信モジュールからの読取タスクを示す流れ図である。

【図３０】ユーザ・データ駆動プロトコル・モードの動
作でのデータ通信モジュールへの書込タスクを示す流れ
図である。

【図３１】オーナー・データ駆動プロトコルモードの動
作または安全データ駆動プロトコル・モードの動作のい
ずれかでのデータ通信モジュールからのデータ読取タス
クを示す流れ図である。

【図３２】そのうちの一部が通常のハードウェア・マル
チメディア末端装置の動作を仮想化する、複数のモジュ
ラー・マルチメディア・ソフトウェア・タスクの動作を
示すブロック図である。

【図３３】オーディオ出力増幅タスクの動作を示すブロ
ック図である。

【図３４】データ・ストリームの間の位相差を制御する
ためのデータ通信モジュールとモジュラー・マルチメデ
ィア・ソフトウェア・タスクの使用を示す、ブロック図
である。

【図３５】図３のディジタル信号プロセッサ・マネージ
ャ・プログラムを示すブロック図である。

【図３６】図３５のディジタル信号プロセッサ・マネー
ジャAPI制御の詳細を示すブロック図である。

【図３７】図３５のIPCハンドラの詳細を示すブロック
図である。

【図３８】図３５のDSPパーサーの詳細を示すブロック
図である。

【図３９】図３５のDSP BIOSブロックの詳細を示すブロ
ック図である。

【図４０】図３５のDSPリンク・エディタの詳細を示す
ブロック図である。

【図４１】図３５のタスク・マネージャの詳細を示すブ
ロック図である。

【図４２】図３５の資源マネージャの詳細を示すブロッ
ク図である。

【図４３】図３５のDSPタスク・ローダーの詳細を示す
ブロック図である。

【図４４】データ通信モジュールの作成と定義に使用さ
れるアセンブリ言語マクロ・テーブルを示す図である。

【図４５】データ通信モジュール・プロトコルの可能な
組合せを示す表である。

【図４６】仮想データ通信モジュールの作成を可能にす
る制御ブロックに含まれる情報を表す表である。

【図４７】ホストCPUに常駐するディジタル信号プロセ
ッサ・マネージャ・プログラムがディジタル信号プロセ
ッサの動作を調整し制御できるようにする、アプリケー
ション・プログラム・インターフェース（API）の５つ
の大まかなカテゴリーを識別する表である。

【図４８】モジュラー・マルチメディア・タスクを実行
のためにDSPにロードできるかどうかを判定する処理を
示す流れ図である。

【図４９】モジュラー・マルチメディア・ソフトウェア
・タスクを実行するための複数のDSPの「ネットワーク
化」を示すブロック図である。

【図５０】タスクの初期設定と複数のDSPを含むデータ
処理システムへの追加のための処理を示す流れ図であ
る。

【図５１】タスク平衡化のための処理を示す流れ図であ
る。

【図５２】前にロードされ走行中の機能を構成するタス
クを除去するための処理を示す流れ図である。

【符号の説明】 ４５１ ディジタル信号プロセッサ・パーサ ４５３ ディジタル信号プロセッサ・リンク・エディタ ４５５ ディジタル信号プロセッサ・資源マネージャ ４５７ タスク・ローダ ４５９ タスク・マネージャ ４６１ ディジタル信号プロセッサ・マネージャ・アプ
リケーション・プログラム・インターフェース・コント
ローラ ４６３ 割込みおよびプロセッサ・コール・バック・ハ
ンドラ ４６５ ディジタル信号プロセッサBIOSインターフェー
ス ４６７ モジュール・ロード・ファイル ４６９ タスク・ロード・ファイル ４７１ スレッド・ロード・ファイル ４７３ 制御ファイル ４７５ セグメント割振りファイル ４７７ マネージャ初期設定ファイル ４７９ データ・イメージ・ロード・ブロック ４８１ コード・イメージ・ロード・ブロック ４８３ 制御ブロック ４８５ DSPプロセッサ初期設定ファイル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ホセ・エイ・エドゥアルテス アメリカ合衆国33141 フロリダ州マイ アミ・ビーチ フェアウェイ・ドライブ 285 (72)発明者 ズイ・キュー・フィン アメリカ合衆国33431 フロリダ州ボ カ・ラトン グリーンウッド・テラス 2600 ジー209 (72)発明者 ポール・アール・スィングル アメリカ合衆国33445 フロリダ州デル レイ・ビーチ ノース・ウエスト ナイ ンス・ストリート 3727 (72)発明者 サクソーン・ヨン アメリカ合衆国33498 フロリダ州ボ カ・ラトン ワンハンドレッドアンドエ イティーンシクスス・コートサウス 10299 (56)参考文献 欧州特許出願公開473444（ＥＰ，Ａ ２) 特許2516317（ＪＰ，Ｂ２) 真野克己，外１名，マルチメディアと 情報圧縮を追う４ マルチメディアの一 翼をＤＳＰが担う，エレクトロニクス, 株式会社オーム社，1992年 ７月 １ 日，第37巻，第７号，ｐ．６−12 高橋秀一，ＤＳＰソフト開発用市販Ｏ Ｓ解説 ＤＳＰのためのマルチタスク・ リアルタイムＯＳ，インターフェース, ＣＱ出版株式会社，1993年11月 １日, 第19巻，第11号，ｐ．213−217 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06F 9/06 G06F 9/46 - 9/54 G06F 15/16 - 15/177 G06F 17/00 - 17/18

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】データ処理システム内の複数のディジタル
   信号プロセッサによるタスクの実行を管理するための前
   記データ処理システムであって、 （Ａ）データ処理動作用の中央処理装置と、 （Ｂ）通信チャネルによって互いに接続され、前記中央
   処理装置に接続された、複数のディジタル信号プロセッ
   サと、 （Ｃ）ディジタル信号プロセッサ・マネージャとを含
   み、前記ディジタル信号プロセッサ・マネージャは、 （ａ）ディジタル信号プロセッサによって実行される機
   能の識別に応答して、機能の一部を構成するタスクをロ
   ードのために識別するための第１識別手段と、 （ｂ）第１識別手段によって識別されたタスクをロード
   するための手段と、 （ｃ）ロードされるタスクに接続されたデータ通信モジ
   ュールが存在するかどうかを識別するための第２識別手
   段と、 （ｄ）接続されたデータ通信モジュールの存在の識別に
   応答して、接続されたデータ通信モジュールがリアルタ
   イム・データ通信モジュールであるかどうかを判定する
   第１判定手段と、 （ｅ）リアルタイム・データ通信モジュールの存在に応
   答して、識別されたタスクをサポートするのに十分なプ
   ロセッサ資源が、リアルタイム・データ通信モジュール
   を含むディジタル信号プロセッサ用に存在するかどうか
   を判定するための第２判定手段と、 （ｆ）リアルタイム・データ通信モジュールを含む前記
   ディジタル信号プロセッサ用の十分なプロセッサ資源の
   存在に応答して、識別されたタスクをディジタル信号プ
   ロセッサに追加するための追加手段と、 （ｇ）リアルタイム・データ通信モジュールを含む前記
   ディジタル信号プロセッサ用の十分なプロセッサ資源の
   不在またはリアルタイム・データ通信モジュールの不在
   のいずれかに応答して、通信チャネルが追加のデータ通
   信モジュールをサポートするのに十分な通信資源を有す
   るかどうかを判定するための第３判定手段と、 （ｈ）追加のデータ通信モジュールをサポートするのに
   十分な通信資源の存在またはデータ通信モジュールの不
   在のいずれかに応答して、識別されたタスクをサポート
   する能力を有する、最大量のプロセッサ資源を有するデ
   ィジタル信号プロセッサを選択するための手段と、 （ｉ）ディジタル信号プロセッサの選択に応答して、選
   択されたディジタル信号プロセッサに識別されたタスク
   をロードするための手段とを含む前記ディジタル信号プ
   ロセッサ・マネージャを含み、 （Ｄ）１機能を構成するタスクを、ディジタル信号プロ
   セッサ上で実行中の別の機能を構成するタスクの実行に
   割り込まずに、ディジタル信号プロセッサにロードでき
   ることを特徴とするデータ処理システム。
2. 【請求項２】ディジタル信号プロセッサからの除去のた
   め、ディジタル信号プロセッサ上で実行中の機能の一部
   を構成するタスクを識別するための第４識別手段と、 別の機能を構成するタスクの実行に割り込まずに、ディ
   ジタル信号プロセッサから識別されたタスクを除去する
   ための除去手段とをさらに含む、請求項１のデータ処理
   システム。
3. 【請求項３】前記除去手段が、 識別されたタスクを含むフレームから、識別されたタス
   クを除去するための手段と、 識別されたタスクの実行を終了させるための終了手段
   と、 データ通信モジュールへのメモリ・マークを除去するた
   めの手段と、 ホストのメモリ・ツリーから識別されたタスクを除去す
   るための手段とを含むことを特徴とする、請求項２のデ
   ータ処理システム。
4. 【請求項４】各機能が少なくとも１つのタスクから構成
   される、データ処理システム内の複数のディジタル信号
   プロセッサによる機能の実行を管理するためのデータ処
   理システムであって、 データ処理動作用の中央処理装置と、前記中央処理装置
   に接続された複数のディジタル信号プロセッサと、各々
   が前記複数のディジタル信号プロセッサのうちの少なく
   とも１つのディジタル信号プロセッサに関連づけられた
   複数のデータ通信モジュールと、ディジタル信号プロセ
   ッサ・マネージャと、を含み、 前記ディジタル信号プロセッサ・マネージャが、 （Ａ）機能の一部を構成する、ディジタル信号プロセッ
   サにロードされるタスクを識別するための第１識別手段
   と、 （Ｂ）前記第１識別手段に応答して、タスクを処理する
   ための十分なプロセッサ資源を有するディジタル信号プ
   ロセッサを識別するための第２識別手段であって、ディ
   ジタル信号プロセッサに関連づけられたデータ通信モジ
   ュールの特色がディジタル信号プロセッサの識別の際に
   評価されるものであり、 （ａ）データ通信モジュールが他のタスクに接続されて
   いるかを判定する第１判定手段と、 （ｂ）データ通信モジュールがディジタル信号プロセッ
   サ上で実行される他のタスクに接続されているのに応答
   して、他のタスクに接続されているデータ通信モジュー
   ルがリアルタイム・データ通信モジュールであるかを判
   定する第２判定手段と、 （ｃ）ロードされるタスクと同じ機能の一部を構成する
   少なくとも１つのタスクに接続されたデータ通信モジュ
   ールを含むディジタル信号プロセッサであって、該ディ
   ジタル信号プロセッサと該ディジタル信号プロセッサ内
   のデータ通信モジュールがタスクをサポートするのに十
   分な資源を有するものを、前記リアルタイム・データ通
   信モジュールの存在に応答して選択する接続手段と、 を有する前記第２識別手段と、 （Ｃ）前記第２識別手段によって識別されたディジタル
   信号プロセッサにタスクをロードするためのロード手段
   と、を含む、ことを特徴とするデータ処理システム。
5. 【請求項５】ディジタル信号プロセッサ上で実行中の別
   の機能の実行に割り込まずに、ディジタル信号プロセッ
   サにロードされたタスクを除去するための除去手段を、
   さらに含む、ことを特徴とする請求項４に記載のデータ
   処理システム。