(57)【要約】本発明は、メインプロセッサおよびコプロセッサなどの個々の構成要素のデータ処理システム内への集積化の後に満足のいくように動作するデータ処理システムを備える集積回路を提供する。これは、個々の構成要素間に確立された通信構造の使用率を計測することによって達成される。計測ユニットは、処理ユニットと通信リソースとの間の接続上の、または通信リソース内部の接続上の、通信トラフィックを観測することによって通信負荷の特性を計測する。この計測ユニットは、この観測した特性に統計的演算を行って計測結果を生成する。この計測結果は、計測ソフトウェアによって取り出されてよく、例えばデバッグすることによって、または適応制御によって、データ処理システムを変更するために使用可能である。
2007514214.tif 000002
【特許請求の範囲】
【請求項１】
データ処理システムを備える集積回路であって、前記データ処理システムが複数の処理ユニットと、前記処理ユニットのうちの少なくとも２つによって共有されるリソースと、を備えた集積回路において、
少なくとも１つの計測ユニットを含み、前記計測ユニットは、ある時間間隔にわたって前記複数の処理ユニットによって前記リソースにかけられる通信負荷の特性を計測するように構成されており、さらに前記計測ユニットが前記通信負荷の前記特性に統計的演算を行うようにも構成されおり、前記統計的演算が計測結果を生成する、
ことを特徴とする集積回路。
【請求項２】
前記計測ユニットが第一の接続上の通信トラフィックを観測することによって前記通信負荷の前記特性を計測し、前記第一の接続が処理ユニットと前記リソースとの間に確立されている、請求項１に記載の集積回路。
【請求項３】
前記計測ユニットが第二の接続上の通信トラフィックを観測することによって前記通信負荷の前記特性を計測し、前記第二の接続が前記リソースの部分間に確立されている、請求項１に記載の集積回路。
【請求項４】
前記計測ユニットが計測コントローラと複数の計測データバッファとを備え、前記計測コントローラは、前記統計演算を行って、前記計測結果を前記計測データバッファに格納する、ように構成されている、請求項１に記載の集積回路。
【請求項５】
前記計測コントローラが、さらに、前記通信負荷の前記特性を別個のクラスに分割して、前記別個のクラスのうちの少なくとも１つに前記統計的演算を単独に行うように構成されている、請求項４に記載の集積回路。
【請求項６】
前記時間間隔が複数の単位に分割されており、前記計測コントローラが、さらに、各単位にわたる前記通信負荷の前記特性に統計的演算を行って、経時トレースとして前記計測結果を生成するように構成されている、請求項４に記載の集積回路。
【請求項７】
前記計測コントローラさらに制御プロセッサと通信するように構成されており、前記制御プロセッサがプログラムを備えていて、前記プログラムが前記計測ユニットを設定するように考案されている、請求項４に記載の集積回路。
【請求項８】
前記プログラムがさらに、前記制御プロセッサをイネーブルして、前記計測結果を前記計測ユニットから取り出すように考案されている、請求項７に記載の集積回路。
【請求項９】
前記プログラムがさらに、前記制御プロセッサをイネーブルして、前記リソースの動作を制御し、または前記処理ユニットの動作を制御するように考案されている、請求項７に記載の集積回路。
【請求項１０】
前記計測ユニットが、前記第一の接続を介して、または、前記第二の接続を介して、転送されるデータの量を計測するように構成されており、前記転送されるデータの量が前記通信負荷の前記特性のうちの１つである、請求項２または３に記載の集積回路。
【請求項１１】
前記計測ユニットが、前記第一の接続を介する、または、前記第二の接続を介する、前記リソースへのデータ転送の要求についてのレイテンシを計測するように構成されており、前記データ転送の要求についての前記レイテンシが前記通信負荷の前記特性のうちの１つである、請求項２または３に記載の集積回路。
【請求項１２】
前記計測ユニットが前記第一の接続を介する、または、前記第二の接続を介する、前記リソースへのデータ転送時間を計測するように構成されており、前記データ転送時間が前記通信負荷の前記特性のうちの１つである、請求項２または３に記載の集積回路。
【請求項１３】
前記統計的演算が平均値演算、最低値演算、または最高値演算を含む、請求項１に記載の集積回路。
【請求項１４】
前記統計的演算が発生率の度数分布図を構成する１セットの値を作り出す演算を含む、請求項１に記載の集積回路。
【請求項１５】
前記請求項のうちのいずれかに記載の集積回路を備える映像処理ユニット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システムを備える集積回路に関し、このデータ処理システムは、複数の処理ユニット（処理装置）と、これらの処理ユニットのうちの少なくとも２つによって共有されるリソースと、を備える。また本発明は、このような集積回路を備える映像処理ユニット（ｖｉｄｅｏ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔ）にも関する。
【背景技術】
【０００２】
システムオンシリコン（ｓｙｓｔｅｍｓ−ｏｎ−ｓｉｌｉｃｏｎ）とも呼ばれる集積回路上のデータ処理システムは、しばしばマルチメディア応用において活用される。例えば、画像または映像処理ユニット（ｉｍａｇｅ  ｏｒ  ｖｉｄｅｏ  ｐｒｏｃｅｓｓｉｎｇ  ｕｎｉｔｓ）は、完全な画像処理システムまたは映像処理システムを得るためにデータ処理システムにおいてまとめ（ｐｕｔ  ｔｏｇｅｔｈｅｒ）られうる。かかるデータ処理システムは通常、１つまたは複数の中央処理装置（ＣＰＵ）と、例えば画像処理ユニット等のいくつかの専用処理ユニットとを備える。この場合、１つのＣＰＵが、そのシステムによって行われなければならない複数のタスクを管理し、複数の一般タスクを実行し、そのシステムの動き全体を制御する。このＣＰＵは、制御ＣＰＵと呼ばれる。専用処理ユニットは、制御ＣＰＵからの入力を受け、特定の画像処理タスクを行い、それらの出力を制御ＣＰＵに返す。これらの専用処理ユニットは、コプロセッサとも呼ばれる。他のＣＰＵは、同様にそれらの処理又は進行を制御ＣＰＵに同期させながら、計算タスクを行うことに関わらせられてよい。
【０００３】
集積回路上のデータ処理ユニットの１つの実施形態が、米国特許第５２８７５１１号において提供されており、処理するタスクを意思決定マイクロプロセッサ（ｄｅｃｉｓｉｏｎ−ｍａｋｉｎｇ  ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ）のためのタスクとプログラム可能なリアルタイム信号プロセッサ（ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｌ−ｔｉｍｅ  ｓｉｇｎａｌ  ｐｒｏｃｅｓｓｏｒ）のためのタスクとに分割するためのアーキテクチャおよび方法が開示されている。このようなデータ処理ユニットのもう１つの実施形態は、雑誌記事「Ｖｉｐｅｒ：Ａ  Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ  ＳＯＣ  ｆｏｒ  Ａｄｖａｎｃｅｄ  Ｓｅｔ−ｔｏｐ  Ｂｏｘ  ａｎｄ  Ｄｅｇｉｔａｌ  ＴＶ  Ｓｙｓｔｅｍｓ」、Ｓａｎｔａｎｕ  Ｄｕｔｔａ、Ｒｕｎｅ  ＪｅｎｓｅｎおよびＡｌｆ  Ｒｉｅｃｋｍａｎｎ著、ＩＥＥＥ  Ｄｅｓｉｇｎ  ａｎｄ  ｔｅｓｔ  ｏｆ  ｃｏｍｐｕｔｅｒｓ、２００１年９月／１０月号において開示されている。
【０００４】
集積回路上のデータ処理システムはまた、処理ユニットによって共有される、例えば共有バス等の通信リソースを備える。この通信リソースは、クロスバースイッチ、様々なレベルにキャッシュを有する階層型システム、または複数のルータを備えるネットワークである場合がある。共有メモリは、通常、処理ユニット間を流れるデータの中央リポジトリ（ｃｅｎｔｒａｌ  ｒｅｐｏｓｉｔｏｒｙ）としての機能を果たす。上述の例では、ＣＰＵがバッファを共有メモリ内に割り当てて、行われるタスクのために適当なパラメータを画像処理ユニットの中にプログラムするが、これには使用されるバッファのアドレスの設定が含まれる。実行が開始されると、これらの画像処理ユニットは、独立的にこの共有メモリ内のバッファから画像データを取り出して、処理タスクを行って、その結果をこの共有メモリ内の出力バッファの中に格納する。１つの画像処理ユニットの結果は、他の画像処理ユニットによってもしくはＣＰＵによって使用されてもよく、またはこれらの結果はシステム出力に送られてよい。
【０００５】
共有メモリを有するデータ処理システムでは、バス使用率およびバス帯域幅が非常に重要である。このシステムの効率を最適化するために、この共有メモリとの情報のやり取りは通常、６４バイトまたは１２８バイトの連続するデータのバス転送で行われる。このように、メモリアドレス指定（ｍｅｍｏｒｙ  ａｄｄｒｅｓｓｉｎｇ）は、単一データ項目についてではなく、全転送について行われる必要があるにすぎない。さらに、このシステム全体はパイプライン処理されてよく、バスプロトコルは総メモリ帯域幅などの特定のシステムの選択項目（ｓｙｓｔｅｍ  ｃｈｏｉｃｅｓ）から切り離されてよい。例えば、この共有メモリは、このバスプロトコルに影響を及ぼすことなくシングルデータレートＳＤＲＡＭ（ｓｉｎｇｌｅ  ｄａｔａ  ｒａｔｅ  ＳＤＲＡＭ）またはダブルデータレートＳＤＲＡＭ（ｄｏｕｂｌｅ  ｄａｔａ  ｒａｔｅ  ＳＤＲＡＭ）とすることが可能である。
【０００６】
記載されているデータ処理システムの変更形態が可能である。データのバスは、複数のハブまたはルータを介して結合されたバスの階層から構成されているネットワークである場合がある。このようなバスの階層では、キャッシングが様々なレベルで使用される場合がある。さらに共有メモリは、内蔵型（ｏｎ−ｃｈｉｐ）、外部型（ｏｆｆ−ｃｈｉｐ）、またはその両方の混合とされる場合があり、共有メモリは通常、物理的に分散された内蔵メモリブロック（ｏｎ−ｃｈｉｐ  ｍｅｍｏｒｙ  ｂｌｏｃｋｓ）群を必然的に伴う。
【０００７】
共有メモリの他に、データ処理システムの他の素子が多数のタスク間で共有される場合がある。例えば、１つまたは複数の中央処理装置（ＣＰＵ）は多数のソフトウェアプログラムを実行し、複数のコプロセッサはこのＣＰＵの制御下において多数のデータのストリーム（ｓｔｒｅａｍｓ  ｏｆ  ｄａｔａ）を処理することができる。前述のように、バスは複数のＣＰＵおよびコプロセッサによって共有される。ＣＰＵの共有およびタスクスイッチング（ｔａｓｋ  ｓｗｉｔｃｈｉｎｇ）のトレース（ｔｒａｃｉｎｇ）のためには、多くの技法が既知であるが、これはほとんどのＣＰＵがこのようなトレースを容易にするマルチタスキングオペレーティングシステムをサポートしているためである。最先端技術によれば、マルチプロセッサシステムにおける複数のコプロセッサの動作も、通常、制御ソフトウェアの手段によってトレースすることが可能である。
【０００８】
集積回路上のデータ処理システムは、ＣＰＵ、コプロセッサおよびメモリユニットなどのそのシステムの個々の構成要素の性能が適当に構成されていても、満足のいくように動作しないことがあることがわかっている。このシステム性能の解析、特に一定時間帯における満足のいかない動作の原因を解析することは、極めて困難であることがわかっている。しかしながら、システム応答に関する実時間保証（ｒｅａｌ−ｔｉｍｅ  ｇｕａｒａｎｔｅｅｓ）を目指す動的なシステム制御には適当なシステム性能の解析が要求される。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明の目的は、データ処理システム内への個々の構成要素の集積化の後に満足のいくように動作するデータ処理システムを備える集積回路を提供することである。前記目的を達成するために、この集積回路は請求項１の特徴を示す部分によって特徴付けられている。
【課題を解決するための手段】
【００１０】
本発明は、データ処理システムの性能は単に個々の構成要素（処理ユニット、メモリユニット等）の性能に依存しているのではなく、そのデータ処理システムの通信構造にも依存しているという概念に依存している。集積回路上の多大で複雑なデータ処理システムでは、この通信構造はシステム全体の重要な要素の１つである。特にこれらのシステムにおいて、通信構造はますます主要な性能の障害箇所となりつつある。このデータ処理システムの性能を向上させるためには、この通信構造の性能を考慮に入れる開発方法を用いなければならない。
【００１１】
本発明によるデータ処理システムにおいて、通信構造は計測ユニットを備えている。これらの計測ユニットは、通信チャネル上の通信負荷の特性を観測することによってと、これらの特性に統計的演算を行うことによって、その通信構造から性能に関するデータを収集する。このように性能に関する計測結果が得られる。その場合、このデータ処理システムの様々な構成要素のためのプログラムを書くソフトウェア開発者は、この計測結果を読み取って、プログラムを最適化するためにそれらの結果を使用することができる。特に、通信構造の使用率へのプロラムの影響は、変えられて、最適化されてよい。さらにこの性能に関するデータは、データ処理システムの実時間挙動（ｒｅａｌ−ｔｉｍｅ  ｂｅｈａｖｉｏｒ）を向上させるために、システムおよびタスクのパラメータの設定を動的に変更するように使用されてよい。本発明のもう１つの態様は、計測ソフトウェアが処理ユニットのうちの１つ、または制御プロセッサ上にインストールされてよいことであり、このことは、ソフトウェア開発者が計測ユニットから計測データを取り出すことを可能にし、この計測データを解釈することにおいてソフトウェア開発者を支援する。
【００１２】
本発明による集積回路および方法のさらなる利点は、ソフトウェア開発および開発工程中のソフトウェアのデバッグ作業が促進されることである。ソフトウェア技師は、この処理ユニット上で起動するソフトウェアを改良して、微調整するために、このデータ処理システムにおける共有通信リソースの使用率を反映する計測データを使用することができる。改善されたソフトウェア開発工程は、ソフトウェアの商品化までのより短い時間、予想可能な開発時間およびより能率のよいシステムをもたらすであろう。
【００１３】
ＷＯ０２／２８０２７が分散調停アルゴリズム（ｄｉｓｔｒｉｂｕｔｅｄ  ａｒｂｉｔｒａｔｉｏｎ  ａｌｇｏｒｉｔｈｍ）による共有バスにおける適正なデータ転送についての方法を開示していることが指摘されている。この方法は、トラフィック渋滞状態にあるシステムのモジュール間でのリソースの適正な共有使用を得ることを目指している。この方法は分散調停アルゴリズムを採用し、このアルゴリズムは、システムの様々なモジュールのハードウェアおよびソフトウェアの両方の上、ならびに／または共有バス上の調停に携わるハードウェア機構の上に実装されてよい。これらのモジュールによって生成されるデータの共有バスへのアクセスに重きがおかれ、各モジュール／データの流れに関する比重がタグを介して監視されている。本方法は、共有バスへの許可されたアクセスを把握することによって、および、新たなアクセスの優先順位を決める（決め直す）ことによって、データ処理システムのモジュールによる共有バスへの加重アクセス（ｗｅｉｇｈｔｅｄ  ａｃｃｅｓｓ）のための機構を提供するが、これらのアクセス中のバスの使用率を解析する手段を提供しない。
【００１４】
この集積回路の１つの実施形態が請求項２において定義されており、計測ユニットは、処理ユニットと通信リソースとの間の接続上の通信トラフィックを観測することによって、通信負荷の特性を計測する。もう１つの実施形態が請求項３において定義されており、計測ユニットは、通信リソースの部分間の接続上の通信トラフィックを観測することによって、通信負荷の特性を計測する。状況に応じて、この２つの方法の一方または両方の組合せが使用されてよい。
【００１５】
請求項４による実施形態では、計測ユニットに備えられる計測コントローラが、観測された特性に統計的演算を行って、その結果を複数の計測データバッファ内に格納する。
【００１６】
状況に応じて、通信トラフィックの様々なクラスを識別して、これらのクラスのうちの１つまたは複数のクラスの通信負荷の特性を計測することが有用である場合がある。この場合、請求項５による実施形態が有利であり、計測コントローラは、通信負荷の特性を別個のクラスに分割して、これらの別個のクラスのうちの少なくとも１つに単独に統計的演算を行うように構成される。かかるクラスの例が命令トラフィッククラス（ｉｎｓｔｒｕｃｔｉｏｎ−ｔｒａｆｆｉｃ  ｃｌａｓｓｅｓ）およびデータトラフィッククラス（ｄａｔａ−ｔｒａｆｆｉｃ  ｃｌａｓｓｅｓ）である。
【００１７】
この集積回路の更なる実施形態が請求項６において定義されている。この実施形態は、例えば、ＣＰＵが多数のタスクを行う状況において、データ処理システムの動的挙動が解析されなければならない場合に特に有利である。計測コントローラは、複数の単位時間にわたって通信負荷の特性に統計的演算を行うように構成されており、これらの単位が、統計が生成される時間間隔（タイムインターバル）の部分を形成する。計測コントローラは、例えば各単位時間について最低値、最高値および平均値などの統計を生成する。このように経時的トレースが生成されてよい。
【００１８】
請求項７は、計測コントローラと通信するように構成された制御プロセッサを備える実施形態を定義しており、この計測コントローラはプログラム（計測ソフトウェア）を備えている。このプログラムは、計測ユニットを設定するように活用されてよい。請求項８は、さらなる実施形態を定義しており、このプログラムは計測結果を計測ユニットから取り出すように活用されてよい。請求項９によるこのプログラムも、通信リソースの動作または処理ユニットの動作を制御するように制御プロセッサをイネーブルするために使用されてよい。このように適応制御が実装されてよい。
【００１９】
請求項１０、１１および１２は、計測ユニットによって計測されてよい通信負荷の様々な特性を明記する。請求項１０による計測ユニットは、１つの接続を介して転送されるデータの量を計測するように構成されている。請求項１１による計測ユニットは、リソースへのデータ転送についての要求のレイテンシ（ｌａｔｅｎｃｙ）を計測するように構成されている。請求項１２による計測ユニットは、このような要求についてのデータ転送時間を計測するように構成されている。
【００２０】
請求項１３による実施形態は、観測された特性についてのいくつかの統計的演算を提供し、これらの統計的演算は計測ユニットによって行われてよい。数ある中でも、観測された特性の平均値、観測された特性の最低値、または観測された特性の最高値を提供することが可能である。また、請求項１４において定義されているように、観測された特性の値の発生率の度数分布図を生成することも可能である。
【００２１】
本発明による集積回路は有利には、請求項１５において定義されるように、セットトップボックス、ＤＶＤレコーダ、またはテレビなどの映像処理ユニットに活用されてよい。この映像処理ユニットは、より低い費用で生産することが可能であると同時にその品質は維持することが可能である。
【００２２】
本発明は、図面を参照してより詳細に説明される。
【発明を実施するための最良の形態】
【００２３】
図１は、複数の処理ユニット１０４、１０６、１０８およびこれらの処理ユニットによって共有される通信リソース１１０を備えるデータ処理システム１０２を備える集積回路１００を説明する。この通信リソース１１０は、例えばバスである。処理ユニット１０４、１０６、１０８は、１つまたは複数の中央処理装置（ＣＰＵ）を含んでよく、これらのＣＰＵは、マルチタスキングに適したオペレーションシステムをサポートしながら、一般タスクを行って、タスクの実現を制御する。またこの処理ユニット１０４、１０６、１０８は、コプロセッサとも呼ばれる１つまたは複数の専用処理ユニットを含んでよく、これらのコプロセッサは、画像データストリームまたは映像データストリームの処理などの特定のタスクを行う。これらのＣＰＵは、通信リソースを介して他のＣＰＵまたはコプロセッサと通信し、この通信リソースは通常、バスとして実装される。
【００２４】
図２は、図１に示されるようなデータ処理システムの１つの実施例を説明する。データ処理システム１０２は、ＣＰＵ１０４ならびに２つのコプロセッサ１０６および１０８を備えており、これらは図１に示されるような処理ユニットに対応する。このＣＰＵ  １０４ならびにコプロセッサ１０６、１０８は、バス１１０を介して通信する。さらに、もう１つのコプロセッサ２００が設置されており、その他に処理ユニット１０４、１０６、１０８、２００によって共有されるメモリユニット２０４ならびにこのメモリユニット２０４とバス１１０との間のインターフェースとして活用されるメモリインターフェースＭＩも設置されている。この実施例では、メモリユニット２０４は内蔵型であるが、外部型メモリユニットを有することも可能である。コプロセッサ１０６、１０８、２００は、バスインターフェースＢＩを備えており、これらのインターフェースＢＩは、これらのコプロセッサとバス１１０との間のインターフェースとして活用される。このバス１１０は、アービタ（ａｒｂｉｔｅｒ）素子（図示せず）を含み、この素子は処理ユニット１０４、１０６、１０８、２００からのバスアクセスの要求を調停する。
【００２５】
このようなデータ処理システムにおいて、ＣＰＵ１０４は通常、バッファをメモリユニット２０４内に割り当てて、行われるタスクのために適当なパラメータをコプロセッサ１０６、１０８、２００にプログラムする。これは、使用されるべきバッファのアドレスの設定を含む。実行が開始されると、これらのコプロセッサは、自律的にメモリユニット２０４内のバッファからそれらの入力データを取り出し、それらの処理を行い、それらの結果をメモリユニット２０４内の出力バッファ内に格納する。システム入力データは通常、外部から取り出される（図示せず）。１つのコプロセッサによってもたらされる結果は、他のコプロセッサよってもしくはＣＰＵ１０４によって使用されてよく、またはシステム出力（図示せず）に送られてよい。共有メモリシステムとも呼ばれるこのデータ処理システムでは、バス使用率およびバス帯域幅が非常に重要である。
【００２６】
この共有メモリシステムの効率を最適化するために、処理ユニット１０４、１０６、１０８、２００とメモリユニット２０４との情報のやり取りは通常、６４バイトまたは１２８バイトの連続データのバス転送で行われる。このようなバス転送の長さは、バースト長（ｂｕｒｓｔ  ｌｅｎｇｔｈ）またはデータパケットの大きさとも呼ばれ、この長さは転送されるべきデータの大きさによって変化してよい。小さなデータについては、このデータパケットも小さいことが好ましいが、これはさもなければ、そのパケットの大部分が使用されないことになるためである。バスプロトコルの不利益を縮小するためには、データパケットの大きさは可能な限り大きくするべきであり、したがってデータパケットの大きさは適当に選択されるべきである。
【００２７】
もしもバス転送が使用されたならば、その場合、メモリのアドレス指定は全転送について１回行われる必要があるにすぎず、サイクル遅延の点から見たバスプロトコルの不利益が縮小される。しかしながら、この共有メモリシステムの効率は、個々の処理ユニット１０４、１０６、１０８、２００およびそのアドレス指定機構の効率、または単独的に見たメモリユニット２０４の効率のみに依存しているのではなく、バスの効率のよい使用率にも依存し、このバスは処理ユニットとメモリユニットとの間の通信構造を形成する。さらに全体的なシステムの性能は、個々のタスクのスケジューリング（ｓｃｈｅｄｕｌｉｎｇ）に依存するが、これはそれらの通信要件が動的に変化する場合があるためである。この態様は、ソフトウェア開発中およびデバッギング中にめったに考慮に入れられることがないが、全体的システムの性能に大きな影響を及ぼす場合がある。処理ユニットがバスにアクセスする優先順位は許可されたアクセスの回数によって上下するという意味で、ある処理ユニットによるバスへの許可されたアクセスを把握することを目指す複数の方法およびアーキテクチャが存在する。しかしながら、処理ユニットによって通信リソースにかけられる負荷は計測されない。
【００２８】
図３は、本発明によるデータ処理システムを説明する。データ処理システム１０２はここでも処理ユニット１０４、１０６、１０８これらの処理ユニットによって共有される通信リソース１１０を備える。この場合、通信リソース１１０はアービタ（図示せず）を備えているバスであり、アービタは様々な処理ユニット間で要求の優先順位をつけることができる。このデータ処理システム１０２はさらに、計測ユニット３００、３０２、３０４を備えており、これらの計測ユニットは処理ユニット１０４、１０６、１０８によって通信リソース１１０にかけられる通信負荷の特性を計測する。具体的には、計測ユニットは、本実施例において、
第一の処理ユニット１０４とバス１１０との間の通信負荷を計測する計測ユニット３００と、
第二の処理ユニット１０６とバス１１０との間の通信負荷を計測する計測ユニット３０２と、
第三の処理ユニット１０８とバス１１０との間の通信負荷を計測する計測ユニット３０４とを含む。
【００２９】
図３において説明された構成において、計測ユニット３００、３０２、３０４は、処理ユニット１０４、１０６、１０８とバス１１０との間の通信チャネルに結合されている。代替方法として、計測ユニットは、図５を参照して説明されるように、通信リソース自体内部のチャネルの使用率を解析するように通信リソースの中に備えられてよい。その場合、計測ユニットは、通信リソースの「障害箇所」の近く、すなわち性能に関係する障害が発生することが予想される通信基礎構造の中の場所に配置されることが好ましい。
【００３０】
取り出されてよい計測情報の例は、
通信リソース１１０を介して単位時間内に処理ユニット１０４、１０６または１０８とやり取りされたデータの量、
（処理ユニット１０４、１０６、１０８による）データ転送についての要求の瞬間とアービタによるバスアクセスの許可の瞬間との間で経過する時間として定義される、通信リソース１１０へのデータ転送の要求のレイテンシおよび
アービタによるバスへのアクセスの許可の瞬間とデータ転送が終了して、バスの占有が終わる瞬間との間に経過する時間として定義される、データ転送についての要求のデータ転送時間である。
【００３１】
これらの例は網羅的なものではない。データ処理システムの特定の性質およびその通信構造に応じて、その他の計測データを得ることが有利となる場合がある。
【００３２】
本発明の１つの態様によれば、計測ユニットは、通信リソースと処理ユニットとの間の接続上の通信トラフィックを観測することによって、処理ユニットによって通信リソースにかけられる通信負荷の特性を計測する。本発明のもう１つの態様によれば、計測ユニットは、通信リソース内部、すなわちリソースの様々な部分の間の接続上の通信トラフィックを観測することによって、通信負荷の特性を計測してもよい。例えば、バスの階層を備えるリソース内部では、バス間の通信トラフィックを観測することが有用である場合がある。
【００３３】
計測ユニットは計測結果を生成することができ、これらの結果は格納された後にソフトウェアによって取り出されてよく、または別の方法で活用されてもよい。これらの計測結果は、ある時間間隔（タイムインターバル）における観測された通信負荷の特性についての統計的演算の出力である。この統計的演算は、計測コントローラによって行われることが好ましく、計測結果は、バッファ内、例えば、計測ユニットの内部レジスタ内に格納される。統計的演算は、例えば、観測された特性の最低値もしくは最高値、平均値または全ての値の発生率の完全な度数分布図を生成してよい。
【００３４】
本発明のさらなる態様は、経時的トレースが生成されてよいことである。この目的のために、時間間隔は複数の単位に分割され、計測コントローラは各単位にわたる通信負荷の特性に統計的演算を行うことができる。例えば、結果は、観測された特性の平均値のトレースであってよい。経時的トレースは、通信負荷とシステムの動作との相関関係の解析を可能にするが、その情報が計測ソフトウェアによって取り出されることが可能となる前にその情報を格納するより大きなバッファを必要とする。
【００３５】
通信負荷の特性をクラスに分類することも可能である。このようにいくつかの種類のトラフィックは識別されてよく、例えば、命令を含むトラフィックはデータを含むトラフィックから識別されてよい。その他の分類基準は、通信ピア（ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｐｅｅｒｓ）間（例えばターゲットが内蔵型または外部型であるのか）を識別する場合、または読み出しトラフィックと書き込みトラフィックとを識別する場合がある。クラスはまた、バス転送に関連するアドレスの値が特定のアドレス範囲に属するかを調べることによって互いに識別されてもよい。好ましい実施形態では、関心のある計測クラスに対応するアドレス範囲の境界の値が計測ユニット内のレジスタにおいてローカルに格納され、それらの値は計測ソフトウェアを介して設定される。統計は、各通信クラスについて個別に算出されてよい。データトレースが収集される場合、分類はトレースサンプル（ｔｒａｃｅ  ｓａｍｐｌｅｓ）の部分として格納される場合がある。経時計測値のトレースが収集される場合、これらのトレースは通常、通信リソースへの負荷の統計から構成されることになる。その場合、この統計は、トレース自体の継続時間よりもかなり小さなタイムスロット（ｔｉｍｅ  ｓｌｏｔｓ）にわたって収集される。
【００３６】
この計測結果は、様々な場所に格納されてよく、例えば、
少量の計測データ用に適している、計測ユニット内もしくは計測ユニットに近接するハードウェア内のローカルバッファ内または
より量の多いデータ用に適しているバックグラウンドメモリもしくは共有メモリ内に格納されてよいが、この場所への格納はメモリの帯域幅要件を増大させる。
【００３７】
計測ユニットは、例えば、バスインターフェースにおいてなど、データ処理システムのアーキテクチャ内の様々な場所にハードウェアによって実装されてよい。
【００３８】
ひとたび計測結果が利用可能となると、その後プログラマはプログラム（計測ソフトウェア）を介してそれらの計測結果を取り出すことができ、それらの計測結果をデバッグおよび更なる開発のために使用することができる。代替方法として計測結果は、データ処理システムの実時間挙動を向上させることを目的に、システムおよびタスクパラメータの設定を自動的に変更するために制御ＣＰＵによって使用されてもよい。
【００３９】
当業者は、計測に必要とされるデータの量は通常、観測される通信負荷よりも桁が数桁小さいことを理解されよう。結果として、計測結果の格納および処理は、システムにごく僅かな負担を加えるにすぎないであろう。さらに、計測結果が計測ユニットによって観測される通信リソースを介して通信される場合でも、付加的な計測値の通信負荷の全体的なシステムの動作への影響はごく僅かである。この僅かな影響は、実質的に非侵入的な（ｎｏｎ−ｉｎｔｒｕｓｉｖｅ）実時間計測をもたらす。代替方法として、純然たる非侵入的な実時間でのシステム観測を容易にするように、システム内に専用の計測値の格納手段、通信手段および解析手段が存在してよい。
【００４０】
図４は、本発明による計測ユニットを説明する。本実施例では、計測ユニット３００が処理ユニット１０４とバス１１０との間の通信負荷を計測する。この計測ユニット３００は、計測コントローラ４００を備え、この計測コントローラ４００は、処理ユニット１０４によってリソース１１０にかけられる通信負荷の観測された特性に統計的演算を行うように構成されており、このように計測コントローラ４００は様々な計測結果を生成する。計測コントローラ４００はさらに、様々な計測結果を格納するように、（内部レジスタとして実装された）計測データバッファ４０４ａ、４０４ｂ、４０４ｃ、４０４ｄ、４０４ｅの使用を制御する。計測コントローラ４００は、計測ユニット３００外部にある制御プロセッサ４０２と情報のやり取りを行う。
【００４１】
制御プロセッサ４０２は、計測ユニット３００を設定することが可能な計測ソフトウェアを備えている。この計測ソフトウェアは、単一のプログラム、複数のモジュールまたは独立したプログラムの一群を含んでよいことに留意されたい。この計測ソフトウェアはまた、計測ユニット３００によって生成される計測結果を取り出すことも可能である。代替方法として、この計測ソフトウェアは、処理ユニット１０４またはシステム内の他のＣＰＵの上にインストールされてよい。別の実施形態において、この計測ソフトウェアはまた、例えばアービタの設定を変更することによって、通信リソース１１０の動作を制御することも可能である。あるいは、この計測ソフトウェアは、例えばソフトウェアのタスクを再スケジューリングする（オペレーティングシステムのタスクの優先順位を変更する）ことによって、またはリソースの使用率を軽減するようにソフトウェアおよび／もしくはハードウェアの機能の質を落とすことによって、処理ユニット１０４またはシステム内の他の処理ユニットの動作を制御することが可能である。計測データは、データ処理システムの通信構造を介して、または独立した通信チャネル／リソースを介して取り出されてよい。制御プロセッサ４０２はさらに、システムおよびタスクパラメータの設定を自動的に変更するように、この目的のために設定される処理ユニット１０４の代わりに設定されてよい。
【００４２】
図４は、計測ユニット３００が単に、処理ユニット１０４とバス１１０との間のバス接続を監視（ｏｂｓｅｒｖｅ）する実施形態を描いている。これが１つの好ましい実施形態であるが、それは計測ユニット３００がデータ処理システムの挙動に影響を及ぼさないからである。しかし、異なる実施形態（図示せず）は、処理ユニットおよびバスに直接結合された計測ユニットを使用してよい。その場合、処理ユニットとバスとの間の通信は、計測ユニットを通過する。このような実施形態は、よりすぐれた、すなわちより速い実装を得るために有益となり得る。さらに、このような実施形態は、計測ユニットが（例えば）バスプロトコル適応装置（ｂｕｓ  ｐｒｏｔｏｃｏｌ  ａｄａｐｔｅｒ  ｕｎｉｔ）の部分として集積化されることを可能にする。
【００４３】
図５は、本発明による通信リソース１１０を説明しており、図示の実施例は複数のバス５０２、５０４、５０６およびバス間の接続を備えるバスシステムである。この場合、処理ユニット１０４、１０６、１０８は、これらの処理ユニット自体とバス５０２、５０４、５０６との間の接続に通信負荷をかけるだけではなく、バス５０２と５０６との間およびバス５０４と５０６との間の接続上にもそれぞれ通信負荷をかける。計測ユニット３００、３０２は、これらの接続上の通信負荷の特性を観測するように構成されてよく、処理ユニット１０４、１０６、１０８とバス５０２、５０４、５０６との間の接続についてと同じ統計が生成されてよい。
【００４４】
本発明の集積回路は有利には、セットトップボックス、ＤＶＤレコーダ、テレビ等などの映像処理ユニットに活用されてよい。この集積回路は、より低い費用で同等の信頼性および品質を提供することから、映像処理ユニットは生産がより安価となると同時に同じ品質が保証され得る。
【００４５】
本発明の保護の範囲は、本明細書に記述されている実施形態に制限されないことが記されている。本発明の保護の範囲は、請求項中の参照符号によっても制限されることはない。「備える」という語は、請求項中で言及されているもの以外の部分を排除しない。構成要素に先行する「１つ（ａ（ｎ））」という語は、複数のこれらの構成要素を排除しない。本発明の部分を形成する手段は、専用ハードウェアの形でも、またはプログラムされた汎用プロセッサの形でも実装可能である。本発明は、各新機能の中または機能の組合せに存在する。
【図面の簡単な説明】
【００４６】
【図１】複数の処理ユニットとその処理ユニットによって共有される通信リソースとを備えるデータ処理システムを備える集積回路を説明した図である。
【図２】図１に示されたようなデータ処理システムの１つの実施例を説明した図である。
【図３】本発明によるデータ処理システムを説明した図である。
【図４】本発明による計測ユニットを説明した図である。
【図５】本発明による通信リソースを説明した図である。
【図１】
2007514214.tif 000003
【図２】
2007514214.tif 000004
【図３】
2007514214.tif 000005
【図４】
2007514214.tif 000006
【図５】
2007514214.tif 000007
【国際調査報告】
2007514214.tif 000008
2007514214.tif 000009
2007514214.tif 000010