JP2004534323A

JP2004534323A - マルチプロセッサシステム及びマルチプロセッサシステムの動作方法

Info

Publication number: JP2004534323A
Application number: JP2003511119A
Authority: JP
Inventors: アイ‐チー、カング; オム、ピー．ガンウォル; アンドレ、ケイ．ニューランド
Original assignee: Koninklijke Philips Electronics NV
Current assignee: Koninklijke Philips NV
Priority date: 2001-06-29
Filing date: 2002-06-20
Publication date: 2004-11-11
Also published as: CN1522405A; JP2004531002A; US20040193693A1; CN1522402A; DE60215007T2; EP1405184A2; DE60215007D1; JP2004522233A; CN1531684A; WO2003003232A3; EP1405175A2; US20040153524A1; WO2003003232A2; ATE341027T1; WO2003005196A2; WO2003005219A2; CN100533370C; EP1421506A2; WO2003005219A3; WO2003005196A3

Abstract

本発明に従ったマルチプロセッサシステムは、少なくとも、専用プロセッサ１．６と、さらなるプロセッサ１．３と、プロセッサ間で共有されるメモリ１．５とを有する。共有メモリ１．５及びプロセッサ１．６、１．３は相互接続ネットワーク１．７へ接続される。これらのプロセッサは同期プロトコルに従ってバッファ２．１を介して、データを交換する。専用プロセッサ１．３は同期プロトコルに関わる情報を管理する機能を有し、この情報の少なくとも一部のコピーが共有メモリ２．１に維持される。

Description

【技術分野】
【０００１】
本発明はマルチプロセッサシステム及びマルチプロセッサの動作方法に関する。
【背景技術】
【０００２】
信号処理機能は、MPEG-x, DVB, DAB, UMTSのような標準に基づく多くの製品に対する性能要件を定める。信号処理機能は、これらの製品の信号処理部を効率的に実現することを要求する。しかしながら、標準が進展し、また、市場の要求が変化するため、その実現には、柔軟性と拡張が同様に要求される。データのストリームが処理されるので、マクロパイプラインのセットアップはこれらの用途をモデル化する自然な方法である。このセットアップにおいて、機能（タスク）はステージであり、パイプラインを形成するためにステージ間にはバッファが存在する。全てのステージが並列に動作可能であるため、これはタスクレベルの並列処理(TLP)を利用する方法である。
【０００３】
複数のプロセッサを含むマルチプロセッサシステムは、そのようなマクロパイプラインの実現に非常に適している。マルチプロセッサシステムは、例えばRISCプロセッサあるいはVLIWプロセッサといったプログラム可能なプロセッサのようないくつかのタイプのプロセッサ、あるいは専用ハードウェアを含み得る。あるプロセッサは、特定のタスク、あるいは時分割形式において１タスク以上を実行し得る。マルチプロセッサシステムにおける信号処理機能及びそれらの実行の複雑性が益々高まると、そのようなシステムをテスト及びデバッグすることが益々困難になる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明の目的は、比較的容易にデバッグを実行可能なマルチプロセッサシステム及びデバッグを容易にしたマルチプロセッサシステムの動作方法を提供することである。
【課題を解決するための手段】
【０００５】
この目的に応じて、本発明に従ったマルチプロセッサは、クレーム１において請求されている。この目的に応じて、本発明に従った方法は、クレーム８において請求されている。
【０００６】
マルチプロセッサシステムにおいて実行されるマクロパイプラインにおいて、データはプロセッサ間で、例えばバッファを介して、交換されなければならない。同期プロトコルは、パイプラインにおいて、第１のプロセッサのデータ生成を、第１のプロセッサに続く第２のプロセッサのデータ消費と同期させる必要がある。そのような同期プロトコルは、同期情報、例えばセマフォ（semaphore）のペアを用いる。例えば、第１のセマフォは、新しいデータを書き込むために第１のプロセッサに利用可能なバッファエレメントの数を示し、第２のセマフォは、読出しのために第２のプロセッサに利用可能なバッファエレメントの数を示す。
【０００７】
専用プロセッサを含む装置において、管理情報は、最も重要なところに記憶されることが好ましい。例えば、もし専用プロセッサがバッファにデータを書き込む構成であるのならば、第１の信号は、そのプロセッサへ、例えば専用レジスタの形で、早くアクセス可能であるべきである。しかしながら、システムのデバッグが必要なとき、あるいは例えばパイプラインにおけるボトルネックを発見するためにシステムをテストしなければならないとき、この点在した情報をトレースすることは非常に困難である。それ故、本発明によれば、少なくともこの管理情報のペアが共有メモリにおいて維持される。この方法では、より関連した情報がクラスタ化された形（fashion）で利用可能なように、システム動作の解析が非常に簡易化される、また、この情報はメモリ内に存在するので、ソフトウェアデバッガによってアクセス可能である。
【０００８】
米国特許第6,173,307号明細書は、複数のプロデューサと複数のコンシューマとによって共有される循環待ち行列を含むマルチプロセッサシステムを開示している。プロデューサあるいはコンシューマは、待ち行列の正確性を阻害することなく、いつでもプロデューサあるいはコンシューマよりも先に入手する（preempt）ことを許容され得る。
【０００９】
さらに、米国特許第4,916,658号明細書は、動的に制御されるバッファを含む装置について述べている。そのバッファは、記憶されるべき次の記憶位置を指示する第１のインジケータと、検索されるべき次の記憶位置を示す第２のインジケータと、記憶に利用可能な位置の数及び検索に利用可能な位置の数を供給する回路とを備えた回路を伴って、いくつかの記憶位置からなるデータワードを記憶するのに好適である。
【００１０】
マルチプロセッサシステムにおいて、タスクの数はプロセッサの数より大きくあり得るため、各プロセッサは１以上のタスクを実行し得る。さらに、マルチプロセッサシステムは、例えばシステムによって処理されるデータストリームのビットレートの変化に適合するために、動的に再構成され得る。そのような場合、請求項２に請求された本発明に従ったマルチプロセッサシステムの実施例は、有利である。システムを動的に再構成する場合、あるタスクの通信パートナをハードウェアタスク（例えばシェルに記憶された、分配された情報を用いる）からソフトウェアタスク（共有メモリにおける集中化された情報（centralized info）を用いる）に変更することは、両方のフォーマットが既に共存するため、非常に円滑になされ得る。マルチタスクハードウェア装置に対して、各タスクは、シェル（レジスタ）に記憶された、各タスクが使用するバッファの管理情報のプライベートコピーを有する。これは、シェルのサイズを増大する。これは、タスク間でレジスタを共有することによって避けられ得る。しかしながら、タスクがスワップアウトされるごとに、バッファの現在の状態は明白にメモリに保存されなければならず、そして、再びスケジューリングされるごとに、全ての状態が再び回復されなければならない。このことは、実行性能上、負の影響を有する。メモリにおけるバッファ管理情報の集中化されたコピーを常に保つことによって、タスク切替時にバッファ状態を保存することは、それがそこに既に存在しまた最新であるため、要求されない。
【００１１】
クレーム３は同期プロトコルの第１の実現例について述べている。この実現例において、各プロセッサはそれぞれ同期カウンタを維持する。生成プロセッサ（即ちトークンを書き込む）は、第１の同期カウンタNpを維持し、消費プロセッサ（この情報を読み込む）は、第２の同期カウンタNcを維持する。情報の交換に用いられるバッファはサイズNb、を有し、第１のプロセッサに利用可能なトークンの数N1は
（１）N1＝Nc-Np mod Nb
第２のプロセッサに利用可能なトークンの数N2は
（２）N2＝Np-Nc mod Nb
で与えられる。
【００１２】
生成プロセッサがトークンを書き込み、これを消費プロセッサに解放するごとに、それは、第１の同期カウンタNpを更新し、消費プロセッサがトークンを読み込み、それを生成プロセッサに解放するごとに、それは第２の同期カウンタNcを更新する。
【００１３】
いつでもプロセッサは、第１の命令（要求）を発行することによって、使用可能なトークンの数を検査可能である。この結果、両方の同期カウンタを比較することによって、所定量のバッファスペースが利用可能であるかどうかを確認できる。検査のために、第１のプロセッサは式１を用い、第２のプロセッサは式２を用いる。
【００１４】
第２の命令（解放）の結果、解放されたトークンの数で、プロセッサに割り当てられた同期カウンタが増大する。
【００１５】
第１及び第２の命令は、ソフトウェアにおける関数呼び出しの形で、あるいはハードウェアにおける専用信号を用いて、実行され得る。
【００１６】
詳細な具体化がクレーム４に記述されている。この具体化において、少なくとも１つのプロセッサは、例えばランダムアクセスあるいは一時的なデータの記憶のため、任意に使用できるバッファ内にゾーンを予約可能である。
【００１７】
解放されたトークンの数を維持する代わりに、クレーム３の具体化のように、利用可能なトークンの数をカウンタにおいて維持することが可能である。この場合、書き込みのために利用可能なトークンの数に対するカウンタは、消費プロセッサによって増大させられ、生成プロセッサによって減少させられる。読み出しのために利用可能なトークンの数に対するカウンタは、生成プロセッサによって増大させられ、消費プロセッサによって減少させられる。この具体化はクレーム５に記載される。
【００１８】
共有メモリにおけるコピーは、任意の手段によって維持され得るが、専用プロセッサがさらに共有メモリ内のコピーを更新することが好ましい。専用プロセッサは、どの瞬間に管理情報において変化が生じたかを‘知る（knows）’。
【００１９】
例えば管理情報のコピーのために用いられたのと同じメモリを用いて、バッファを共有メモリ内に配置することが好ましい。
【００２０】
プロセッサに結合されたシェルは、プロセッサ自身によって処理されなければならない割込みの数を減少し得る点において、マルチタスクを容易にする。これは、アイドル状態のプロセッサが不必要に活性化されなければならない回数、あるいは、処理中の別のタスクにプロセッサが割り込まなければならない回数を減少する。この方法において、プロセッサの効率が改善される。
【００２１】
割込み信号のタイプとそのコード化方法とに依存する割込み信号を選択するためのそのようなシェルを実現するために、いくつかの選択が可能である。１つの実施例では、割込み信号はプロセッサのデータチャネルを示す。これを実行する実際的な方法は、プロセッサの各入力チャネルに対してレジスタ内にビットを割り当てることによる。例えば３２ビットレジスタは３２の入力チャネルをサポートし得、例えばチャネル０はビット０が割り当てられ、チャネル１はレジスタのビット１が割り当てられる。他のプロセッサがプロセッサのチャネルｋを示す割込み信号を送ったとき、信号レジスタの対応するビットｋがセットされる。受取り側のプロセッサのシェルは、マスクレジスタを用いることによって特定の割込み信号を選択でき、各ビットは、特定のチャネルに対して、プロセッサが割込みを無視するか否かを表し、例えばもしチャネル２に対応するビットがマスクされていれば、この信号はそのプロセッサに割込みを生じさせず、ウェイクアップは起こらない。この例において、プロセッサは処理でビジーであり得、そこでは、全てのビットはマスクされ、あるいは、プロセッサ／タスクはチャネル１において満たされた／空トークンを待機中であり得、その場合、チャネル２で何が生じるかには関心がない。
【００２２】
その信号及びマスクレジスタは、サポートされるべきチャネルの数に依存する任意数のビットを有し得る。代替的に、番号により各チャネルをサポートすることが、また、プロセッサがそのチャネルに対して割り込まれるべきか否かを決定するためにリストあるいはルックアップテーブルを用いることが可能である。しかしながら、これは、より複雑な解決法である。
【００２３】
チャネル番号によって割込み信号を識別する代わりに、割込み信号はタスク番号によって識別可能である。この実施例では、特定のタスクに対する信号を伴う全てのチャネルは、シェルの信号レジスタに同一のビットをセットする。この方法において、信号レジスタ内のビットの数に等しい多くのタスクは、独自にアドレス指定され、各タスクは１以上のチャネルを有し得る。待機状態は、独自のチャネル識別を伴った場合と比べて特定的でないが、不必要なウェイクアップの数は依然として小さく、より多くのチャネルが制限されたハードウェアでサポートされ得る。
【００２４】
もちろん、関係が明確である限り、タスク番号はビット番号と同一である必要はない（その方法で実行することが実に簡易である）。さらに、タスク（のグループ）は、同じ信号割込み番号を共有可能である。
【００２５】
受け取り側によって実行されるタスクを識別する代わりに、送り側のタスク識別番号が伝えられ得る（signal）。その場合、受け取り側のプロセッサは、特定のタスクに対してではなく特定のタスクからの割込み信号を選択し得る。それは、外部タスクの数や、プロセッサ自身の選択に基づくタスクの数すなわち最も有用／効率的と思われるものに依存する。
【発明を実施するための最良の形態】
【００２６】
以下、図面を参照しながら、本発明の特徴について説明する。
【００２７】
図１は、少なくとも第１の処理手段１．６と第２の処理手段１．３とを含むデータ処理装置を示す。
【００２８】
第１の処理装置、即ち特定用途プロセッサ１．６は、メモリ１．５内に配置されたバッファ手段においてトークンを利用可能にすることによってデータを供給可能である。トークンは、さらなる処理のために、第２の処理手段１．３、即ちデジタルシグナルプロセッサによって読出し可能である。データ処理装置は、さらにＲＩＳＣプロセッサ１．１、ＶＬＩＷプロセッサ１．２及びＡＳＩＰ１．４を備える。ＶＬＩＷプロセッサ１．２、ＤＳＰ１．３、ＡＳＩＰ１．４、メモリ１．５及びＡＳＩＣ１．６は第１のバス１．７を介して相互に接続されている。RISCプロセッサ１．１は、第２のバス１．８と接続され、第２のバス１．８は、ブリッジ１．９を介して反対側の第１のバス１．７に接続されている。さらなるメモリ１．１０及び周辺装置１．１１は第２のバス１．８に接続されている。プロセッサは、補助ユニットを有し得る。例えば、ＲＩＳＣプロセッサ１．１は命令キャッシュ１．１．１及びデータキャッシュ１．１．２を有する。同様に、ＶＬＩＷプロセッサは命令キャッシュ１．２．１及びデータキャッシュ１．２．２を有する。ＤＳＰ１．３は命令キャッシュ１．３．１、ローカルメモリ１．３．２及びアドレスデコーダ１．３．３を有する。ＡＳＩＰ１．４はローカルメモリ１．４．１及びアドレスデコーダ１．６．２を有する。ＡＳＩＣ１．６はローカルメモリ１．６．１及びアドレスデコーダ１．６．２を有する。処理手段１．６、１．３にはそれぞれ同期インジケータが割当てられている。両同期インジケータは、第１の処理手段１．６及び第２の処理手段１．３によってアクセス可能である。第１の同期インジケータは少なくとも第１の処理手段１．６によって更新可能であり、第２の処理手段１．３によって読出し可能である。第２の同期インジケータは、少なくとも第２の処理手段１．３によって更新可能であり、第１の処理手段１．６によって読出し可能である。各同期インジケータはそれぞれカウンタで表される。第１の同期インジケータ（writec）を表すカウンタは第１の処理手段１．６によって書き込まれたトークンの数を表す。第２の同期インジケータ（readc）を表すカウンタは第２の処理手段１．３によって読み込まれたトークンの数を表す。
【００２９】
カウンタ値の比較により各プロセッサに利用可能なトークンの数を計算可能な限り、カウンタによってトークンの数を表すいくつかの選択が当業者に可能である。例えば、カウンタ値が、トークンの数mod n（ｎは整数）、に等しいことがあり得る。別の方法では、カウンタの各ステップが、固定されたトークンの数を表し得る、即ち、カウンタ値によるステップの数によってトークンが表され得る。別の方法では、カウンタの各ステップがトークンの固定番号を表し得る、即ち、トークンがカウンタ値のステップ番号によって表され得る。
【００３０】
実際の実施例では、カウンタは、バッファ手段が他のプロセッサに利用可能にされる最大のアドレスに対するポインタである。このことは、概略的に図２に示される。この図は、概略的に、第２の処理手段１．３にデータを供給するために第１の処理手段１．６によって用いられるメモリ１．５内のバッファスペース２．１を示す。バッファスペース２．１は循環バッファとして構成される。バッファスペース２．１は、第１のゾーン２．２と、現時点で第２の処理手段１．３に利用可能な、第１の処理手段１．６によって書き込まれたデータを含む第２のゾーン２．４とを含む。バッファスペース２．１は、さらに、第１の処理手段１．６が新たなデータを書き込むために利用可能な第３のゾーン２．３を含む。プロデューサカウンタwritecは第１のゾーン２．２の終わりを示し、コンシューマカウンタreadcは第２のゾーン２．３の終わりを示す。
【００３１】
第１のゾーン２．２及び第２のゾーン２．４内の部分２．６は、同期カウンタreadcと結合された予約カウンタreadrsvcによって予約される。第３のゾーン２．３内の部分２．５は、同期カウンタwritecと結合された予約カウンタwritersvcによって予約される。図３及び図４を参照して、第１の同期カウンタwritec、第２の同期カウンタreadc及び予約カウンタreadrsvc, writersvcを含む同期情報は、専用用途装置１．６（図３において３．１として示される）に接続された同期シェルのチャネルコントローラにおける他の情報と結合して記憶される。
【００３２】
図３を参照して、専用用途装置３．１は同期シェル３．２を介してバス３．３に接続されている。この方法では、専用用途装置３．１は計算タスクを請け負い、同期シェルは通信タスクを実行する。そのため、同期シェル３．２はバスアダプタ３．４と、同期シェル３．２がメッセージを受け取ったタスクの識別結果を記憶するための信号レジスタ３．５とを含む。同期シェル３．２は、さらに、チャネルコントローラ３．６、３．７を含む。これらは、プロセッサ３．１の命令をバス３．３への信号に変換する。通常、専用用途装置３．１は、プログラム可能なプロセッサ３．１の場合よりも少ないタスクをパラレルに実行する。
【００３３】
図４は、同期シェルのチャネルコントローラ４．１をより詳細に示す。チャネルコントローラ４．１は、汎用バス・マスタ・スレーブ部４．２、レジスタファイル４．３及びコントロール部４．４を含む。
【００３４】
バスアダプタ３．４及び汎用バス・マスタ・スレーブ部４．２は共にチャネルコントローラ４．１をバスへ接続する。バスアダプタ３．４は、特定の相互接続ネットワーク、例えばＰＩバスあるいはＡＨＢバスを一般的なインターフェースに適合させる。汎用バス・マスタ・スレーブ部４．２は上記汎用インターフェースへ同期信号を適合させる。この方法では、異なるチャネルコントローラタイプと異なるバスとを、比較的少数の異なる構成要素でサポートできる。
【００３５】
レジスタファイル４．３は同期情報を記憶する。
【００３６】
プロセッサ３．１のデバイス同期インターフェースが、バッファ内において書込み可能あるいは読出し可能なトークンの数を要求するために、信号Claimを発行する場合、コントロール部４．４は、ローカルに記憶されたリモートカウンタ値remotecをその予約カウンタlocalsvcと比較することによってこの数が利用可能かどうかを確認する。表記（notation）remotecは入力チャネルに対してwritecを、出力チャネルに対してreadcを示す。表記（notation）localrsvcは入力チャネル対してreadrsvcを、出力チャネルに対してwritersvcを示す。
【００３７】
もし確認が肯定的ならば、トークンのアドレスToken Addressが返される。さもなければ、プロセッサ３．１に対して確保されたバッファスペースの上界アドレス（upper boundary address）が返され得る。信号Token Validは、トークンに対する要求が承認されたか否かを示し、プロセッサの同期インターフェースは信号Claimを再び出すことが可能である。このようにして、トークンアドレスが各サイクルでプロセッサに供給され得る。もし第１の確認の結果が否定的であれば、チャネルコントローラ４．１は、アドレスremotecaddrによって示されるリモートカウンタを読み出し、ローカルに記憶された値remotecをそのアドレスに記憶された値によって置き換える。コントロール部４．４は、再び、要求されたトークンの数が利用可能かどうかを確認する。
【００３８】
もし要求が通らなかったならば、チャネルコントローラ４．１はリモートカウンタをポーリングモードで定期的にポーリングするか、あるいは、割込モードで通信を行うプロセッサによる割込みを待つ。その間他のタスクを進めることができる。チャネルコントローラにおけるレジスタファイルは、プロセッサが通信する他方のデバイスの信号レジスタアドレスを示すポインタsgnl_reg_addrを含む。割込みプロセッサは、装置の信号レジスタ内に、割込みが生じたタスクあるいはチャネルの表示を残し得る。
【００３９】
レジスタ内の変数inputchannelはチャネルコントローラに対して現在のチャネルが入力及び出力チャネルのどちらであるかを、またこれらのモードのどちらがこのチャネルに対して選択されたのかを示す。変数maxtoken及びtokensizeはそれぞれ、バッファ内において利用可能な全トークン数及びバイトによるトークンサイズを示す。
【００４０】
要求が成功した後、変数localrsvcは、要求されたトークンの数に従って更新される。
【００４１】
変数remotecの代わりに、レジスタファイルが、最後の確認で計算された利用可能なトークンの数を示す変数を含み得る。
【００４２】
プロセッサ３．１がRelease_reqを送る場合、ローカルカウンタlocalcはこの要求に従って更新される。このローカルカウンタlocalcは入力チャネルに対するreadc及び出力チャネルに対するwritecである。選択的に、信号Release_reqは、プロセッサ３．１がいつでもトークンを解放できるように、高く保たれ得る。しかしながら、この信号は、それがほとんどバスにアクセスできないときに、コントローラが溢れるのを阻止するために用いられ得る。
【００４３】
代替的に、同期プロセスは、要求及び解放関数を用いることによってソフトウェアで実行され得る。要求関数を実行することによって、プロセッサは特定のチャネルに対するトークンの数を要求し、その関数がトークンアドレスを返すまで待つ。解放関数を実行することによってそのプロセッサは特定のチャネルに対するトークンの数を解放する。別個の関数が、書込み用のトークンあるいは読出し用のトークンを要求するために存在し得る。同様に、別個の関数は解放のために用いられ得る。
【００４４】
本発明に従って、少なくとも同期情報の部分のコピーが共有メモリに維持され得る。
【００４５】
コピーとして維持される情報は、専用プロセッサの動作の追跡に有用な情報、例えばそのプロセッサによって維持される同期カウンタの値を含み得る。
【００４６】
例を用いて、共有メモリ内のコピーが、Ｃ言語仕様の以下のデータ構造に従って構成され得る。
【００４７】

同期カウンタ値writec及びreadc、予約カウンタ値writersvc及びreadrsvcの他に、このデータ構造は以下のデータを含む。
【００４８】
idは、複数のチャネルを識別する値であって、例えば、第１の処理手段から第２の処理手段にデータを転送する第１のチャネル、第２の処理手段から第１の処理手段にデータを転送する第２のチャネル、及び第２の処理手段から第３の処理手段にデータを転送する第３のチャネルを含む処理スキームを実行可能にするチャネルを識別する値である。
【００４９】
maxtokensの値はバッファサイズ、即ち、バッファ内に記憶可能なトークンの数を示す。
【００５０】
flagsの値は、チャネルの属性、例えば同期がポーリングあるいは割込みベースである場合、チャネルバッファが直接あるいは間接に割り当てられるかどうかを示す。代替方法として、所定のチャネル属性を与えること、例えば直接割り当てられたバッファと同期した割り込みの実行を制限することが決定され得る。その場合、flagsの値は省略され得る。
【００５１】
producer及びconsumerは、第１の処理手段すなわちプロデューサのタスク、及び第２の処理手段すなわちコンシューマのタスクを記述する構造へのポインタである。
【００５２】
そのタスク構造は、例えば、以下を含む。
【００５３】
- タスクに対する識別子（それは誰のタスク構造であるか）
- 関数ポインタ（もしそれが組み込みプロセッサにおけるタスクであるのならば、ブートの後、ルートタスクがこの関数にジャンプし、そのアプリケーションを開始し得る。さもなければ無効にする）
- 装置タイプ：タスクがどんなタイプの装置で実行されるかを示す。これは、ブート処理に対して有用である。：DSPあるいは組み込みプロセッサにおいて実行されるタスクは、専用ハードウェアで実行されるタスクと異なった方法で初期化されなければならない。主要な装置タイプを有することによって適正なブート手順の選択が容易になる。
【００５４】
- 装置番号：これは、例えば第１のハードウェアプロセッサ第２のハードウェアプロセッサを識別することを可能にする。これは、それらに固有の番号を与えることによってなされ得る。
【００５５】
- チャネル数
- チャネルデータ構造に対するポインタのリスト
この方法では、例えば、UNIX（Ｒ）タスクが開始されたとき、それは、まずそのタスク構造を読み出し、次いで、そのタスクに接続された全てのチャネルについて全ての情報を読み出し得る。このことは、ブート処理を非常に容易にし、また、タスクが追加されるたびに、全てのタスクに適正なデータ構造をロードさせるために制御プロセスが変更されなければならないことを阻止する。整数token_sizeは、チャネルを介して交換されるトークンのサイズを示す。
【００５６】
ポインタbufbaseaddrは、メモリにおけるバッファのベースアドレスを示す。
【００５７】
ポインタCHP_channel_hwT*pchanregs及びCHP_channel_hwT*cchanregsは、ソフトウェアによるチャネルコントローラのレジスタへのアクセスを容易にする。これらは、単に、ハードウェアレジスタの物理ロケーションに対するポインタである。もし、そのフィールドのどれかが０であるならば、このことは、対応するタスクがソフトウェアタスクであることを意味する。
【００５８】
完全性を期すため、我々は、さらに、２つのハードウェアタスクが通信する場合を論じる。この場合、プロデューサのsignaladdrが、コンシューマの同期シェルにおける信号レジスタのアドレスにセットされ、remotecaddrが、コンシューマチャネルコントローラのlocalcレジスタのアドレスにセットされる。別の選択は、共有メモリにおけるチャネルレコードにおけるreadcフィールドにremotecaddrを設定することである。しかし、これは、コンシューマのシェルがそのローカルレジスタを更新した後、少し遅れてメモリを更新するので、リモートカウンタの読み出し値が少し古くなり得るという不利益を有する。コンシューマに対するレジスタのセットはちょうど逆である。
【００５９】
動的な再設定は、特定のアプリケーションを表すタスクグラフ（task graph）のトポロジーを変更することを伴う。このことは、例えば、タスクが停止及び除去され、そして、特定のチャネルが他のタスクに再接続され得るということを意味する。この場面において最も興味深いシナリオは、特定のチャネルが、いつ一方（プロデューサあるいはコンシューマ）において別のタスクに再接続されるかということであり、それは種々の実行からなる（it is of a different implementation）。例えば、プロデューサタスク（ハードウェア）がハードウェアコンシューマタスクに接続され、再設定の後、それはソフトウェアタスクと通信しなければならない。この場合、チャネルレコードは既に存在し且つ最新であるので、ソフトウェアタスクは即座にそのチャネルを用いることができる。ハードウェアタスクに対して、そのチャネル管理レジスタにおけるいくつかのフィールドが変更されなければならない、すなわち、signaladdrが、新しいソフトウェアタスクが実行されるCPUの信号コントロールアドレスにセットされる。
【００６０】
remotecaddrは、チャネルレコードにおけるreadcフィールドのアドレスにセットされる。このステップは、たとえ２つのハードウェアが通信していたとしても、もし以前にそのケースが既に存在したのならば、必要とされないことに注意する。
【００６１】
これらのレジスタが更新されている間、これらのレジスタをハードウェアタスクが用いることを回避するため、更新がなされた後、それは、まず停止され、そして再開される。
【００６２】
さらに、タスクの通信パートナをハードウェアタスクから別のハードウェアタスクに切り替えることは、メモリにおけるチャネルレコードを伴って、さらに容易になされる。新たなタスクのチャネルコントローラレジスタは、開始される前に、共有メモリから簡易にアップロードされる。
【００６３】
マルチタスクは、１つの単一のハードウェア装置、例えばDCTやIDCTに対応づけられ得る。両方のタスクが異なった入力及び出力チャネルを有し得、それ故、別個のチャネルコントローラ及びレジスタを必要とし得る。あるいは、両方のタスクに対するチャネルを実行するために、装置シェルにおける同じレジスタのセットを用いることができ、それによってシリコン領域を減少できる。メモリにおける管理情報のコピーなしで、これは以下のこと、すなわち、タスクがスケジュールアウトしたとき、そのチャネルの管理情報は明らかにメモリに保存されなければならず、いったんそれが再スケジュールされると、該当するチャネルの管理情報はメモリからレジスタへ復帰され得ること、を必要とする。
【００６４】
提案されたアプローチを伴って、チャネルレジスタの“シャドー(shadow)状態”はいつもメモリに存在し、それ故、ハードウェア装置におけるタスク切替えは、チャネル管理情報の状態保存が必要とされないため、加速される。さらに、スケジュールアウトしたタスクと通信しているタスクは、それが依然として共有メモリチャネルレコードで動作し得るため、このタスク切替えに決して気づかない。
【００６５】
本発明の保護範囲は上述した実施例に限定されない。また、本発明の一部を構成する手段は、専用ハードウェアあるいはプログラムされた一般用途プロセッサで実現され得る。本発明は新たな特徴あるいは新たな特徴の組み合わせを有する。
【図面の簡単な説明】
【００６６】
【図１】データ処理装置を概略的に示す。
【図２】同期カウンタがバッファのパーティションを表す方法を示す。
【図３】プロセッサに対する同期シェルを示す。
【図４】チャネルコントローラを示す。

Claims

少なくとも専用プロセッサと、別のプロセッサと、両前記プロセッサにより共有されるメモリとを備え、前記メモリ及び両前記プロセッサは相互接続ネットワークに接続されたマルチプロセッサシステムであって、
両前記プロセッサは同期プロトコルに従ってバッファを介して互いにデータ転送し、
前記専用プロセッサは前記同期プロトコルに関連した情報を管理し、この情報の少なくとも一部のコピーが前記共有メモリに維持されることを特徴とするマルチプロセッサシステム。
前記情報は少なくとも以下の情報エレメント、
前記バッファの位置を示すアドレス、
前記バッファのサイズの表示、
前記データ転送の進行に関わる同期カウンタ、
を含み、
この情報エレメントのそれぞれのコピーが前記共有メモリに維持されることを特徴とする請求項１に記載のマルチプロセッサシステム。
前記同期カウンタが前記別のプロセッサによって維持され、前記専用プロセッサによって読出し可能であり、前記専用プロセッサは、前記別のプロセッサによって読出し可能な別の同期カウンタを維持し、前記同期プロトコルは、
プロセッサによって発行されたとき、両同期カウンタを比較することによって所定量のバッファスペースがプロセッサに利用可能かどうかを確認する第１の命令と、
プロセッサによって発行されたとき、プロセッサが維持する同期カウンタを更新することによってそのバッファスペースの一部を解放する第２の命令と、
を含むことを特徴とする請求項２に記載のマルチプロセッサシステム。
両前記プロセッサの少なくとも１つは予約カウンタをローカルに維持し、
前記プロセッサによって発行される前記第１の命令は、その予約カウンタを、他方のプロセッサによって維持される同期カウンタと比較することによって、所定量のバッファスペースが利用可能であるかどうかを確認し、もし前記確認の結果が肯定的である場合は、前記予約カウンタを更新することを特徴とする請求項３に記載のマルチプロセッサシステム。
さらなるカウンタを備え、
両カウンタは両プロセッサによって維持され且つ読出し可能であり、これらのカウンタの１つは、前記専用プロセッサに利用可能なバッファスペース量を示し、前記さらなるカウンタは前記別のプロセッサに利用可能なバッファスペース量を示すことを特徴とする請求項２に記載のマルチプロセッサシステム。
前記専用プロセッサは、さらに共有メモリにおける前記コピーを更新することを特徴とする請求項１に記載のマルチプロセッサシステム。
前記バッファは共有メモリに配置されたことを特徴とする請求項１に記載のマルチプロセッサシステム。
少なくとも、専用プロセッサと、別のプロセッサと、両前記プロセッサ間で共有されるメモリとを備え、前記共有メモリ及び両前記プロセッサは相互接続ネットワークに接続されたマルチプロセッサシステムを動作させる方法であって、
両前記プロセッサは同期プロトコルに従ってバッファを介して互いにデータ転送し、前記専用プロセッサは、前記同期プロトコルに関わる管理情報を含み、この管理情報の少なくとも一部のコピーを前記共有メモリにおいて維持することを特徴とする方法。