JP2011034190A - データ処理装置 - Google Patents

Abstract

【課題】複数の処理モジュールを並列に動作させることが可能なデータ処理装置を提供すること。
【解決手段】複数の処理モジュール（２１−ａ，２１−ｂ，２２−ａ，２２−ｂ，２３−ａ，２３−ｂ）のそれぞれに処理フローに対応する処理プロセスが割り当てられ、複数の処理モジュールの中の少なくとも２つの処理モジュールが同じ処理プロセスを実行可能である。ネットワーク１５は、処理モジュールからパケットを受けると、パケットに付加された処理プロセス番号に応じて当該処理プロセスを実行可能な処理モジュールの中から処理モジュールを選択してパケットを出力する調停回路１６を含む。したがって、自律的に各処理モジュール間をパケットが移動するようになり、複数の処理モジュールを並列に動作させることが可能となる。
【選択図】図３

Description

本発明は、複数のハードウェア処理モジュールを用いて処理を行なう技術に関し、特に、複数のハードウェア処理モジュールを並列に動作させて処理を行なうデータ処理装置に関する。

近年、無線通信機器、コンピュータなどのデータ処理装置の高機能化、多機能化が進んでいる。特に、通信、画像処理、画像認識などの分野においては、装置にメディア処理エンジンが搭載され、様々なメディア処理が実現されていることが多い。このような、半導体で実現されるメディア処理エンジンに対して様々な要求がなされてきている。

たとえば、リアルタイムで膨大なメディアデータを処理可能なメディア処理エンジンに対する要求が高まっている。このような要求は、単体のＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）などによる処理だけでは実現不可能となってきている。

また、モバイル環境での利用のためのバッテリ駆動に対する要求や、発熱対策のための低消費電力化に対する要求も高まってきている。

また、半導体プロセスの進展に伴い、ＳｏＣ（System on a Chip）の開発費が高騰しており、開発する半導体チップの種類を削減し、１つの半導体チップで複数のアプリケーションに対応させたいといった要求も高まっている。また、顧客の商品への要求事項の変化が激しいため、商品（最終製品）の開発サイクルを短くする必要がある。そのため、半導体チップにおいても製品化までの期間の短縮が求められている。

また、通信、特に放送機器や携帯電話機を含む無線通信の分野、圧縮／伸張が必要な画像処理などの分野においては、世界中で様々な規格が制定されており、その規格も次世代に向けて絶え間なく更新され続けている。これらの規格に対応可能なマルチモード処理エンジンを実現するために、その半導体チップには高プログラマビリティ、高スケーラビリティが求められている。

さらには、プログラマビリティを有する半導体チップにおいては、ソフトウェアの開発が重要となる。そのソフトウェア開発においても、高性能、高品質、短納期化が求められており、それらを実現するためにソフトウェアの開発容易性に対する要求も高まってきている。

これらに関連する技術として、下記の特許文献１〜４に開示された発明がある。
特許文献１は、並列演算処理装置の各演算ユニットで実施できる処理は決まっており、スケジューリングによっては待ちが発生するという課題を解決することを目的とする。並列演算処理装置は、外部入力手段と、ストリーム入出力手段と、外部出力手段と、バス網と、専用処理回路と、複数の演算ユニットと、第１〜第３のクロックを選択するセレクタと、外部入力処理、外部出力処理、外部入力処理および外部出力処理以外の処理を適応的に複数の演算ユニットに割り当てる制御手段とを備える。

特許文献２は、コストアップをともなう受信バッファ等の増加を行うことなくシステム全体のパフォーマンスを向上させることができる画像処理装置および画像処理方法を提供することを目的とする。画像処理情報が記載されたヘッダーを画像データに付加したデータパケットを用いて、画像処理ＬＳＩが、入力したデータパケットを処理できる場合は画像データの画像処理を行った後、画像処理が終了したことを示す処理終了情報をヘッダーに記載する。また、処理できない場合は処理終了情報を記載せずに出力することにより、画像処理ＬＳＩが画像データを処理できない状態においても、次の画像処理ＬＳＩに対してデータパケットを転送し処理させることができ、画像処理ＬＳＩやバス等のリソースを効率的に利用することができる。

特許文献３は、ＭＰＥＧ−４・ＡＶＣの符号化／復号処理のような、大量のデータ処理量が要求される画像処理に対して、高性能で、高効率な画像処理が行える信号処理装置およびそれを用いた電子機器を提供することを目的とする。信号処理装置は、命令並列プロセッサ、第１データ並列プロセッサ、第２データ並列プロセッサ、および、専用ハードウェアである動き検出ユニットとデブロックフィルタ処理ユニットと可変長符号化／復号処理ユニットとを備える。この構成により、処理量の多い画像圧縮伸張アルゴリズムの信号処理において、ソフトウェアとハードウェアで負荷が分散され高い処理能力と柔軟性を実現した信号処理装置、及びそれを用いた電子機器を提供できる。

特許文献４は、回路規模の増大を抑制しつつ、複数のタスクを同時に並行して実行できるマルチタスクプロセッサを提供することを目的とする。このマルチタスクプロセッサは、プログラムを格納する命令メモリと、命令メモリに格納されたプログラムに記述された命令を読み出してデコードし、タスクとして実行する２つの命令処理部と、複数のタスクの優先度にもとづいて２つの命令処理部のためにタスクを選択し、選択されたタスクを２つの命令処理部に割り当てるスケジューラとを備える。

特開２００４−３２６２２８号公報 特開２００１−３１２４７９号公報 特開２００５−０７０９３８号公報 特開２００３−３２３３０９号公報

従来、通信、画像処理、画像認識などの分野においては、高性能化、低消費電力化を実現するために、専用ハードウェア処理エンジンが採用されている。しかしながら、専用ハードウェアでは低開発費、短納期化を実現することができない。また、専用ハードウェアでは処理内容が固定されてしまうため、高プログラマビリティ、高スケーラビリティを満たすことができない。

高プログラマビリティ、高スケーラビリティを実現するために、ＣＰＵ、ＤＳＰ、ＦＰＧＡ（Field Programmable Gate Array）などの汎用のプログラマブルデバイスで、通信処理、画像処理、画像認識処理などを実現する提案がいくつかなされている。しかしながら、汎用のプログラマブルデバイスを用いて専用ハードウェア処理エンジンと同じ性能を実現しようとした場合、チップ面積が非常に大きくなるとともに、消費電力も膨大なものとなり、現時点ではモバイル環境における使用が不可能である。

また、今後、半導体プロセスの開発が進み、集積度がさらに向上すればチップ面積のデメリットはなくなるが、低消費電力化の可能性は低く、むしろ電力密度が高くなって発熱に関する問題がさらに顕在化することが予想される。

本発明は、上記問題点を解決するためになされたものであり、その目的は、複数の処理モジュールを並列に動作させることが可能なデータ処理装置を提供することである。

本発明の一実施例によれば、複数の処理モジュールがバス等のネットワークによって接続されたデータ処理装置が提供される。複数の処理モジュールのそれぞれに処理フローに対応する処理プロセスが割り当てられ、複数の処理モジュールの中の少なくとも２つの処理モジュールが同じ処理プロセスを実行可能である。ネットワークは、処理モジュールからパケットを受けると、パケットに付加された処理プロセス番号に応じて当該処理プロセスを実行可能な処理モジュールの中から処理モジュールを選択してパケットを出力する調停回路を含む。

この実施例によれば、調停回路が、パケットに付加された処理プロセス番号に応じて当該処理プロセスを実行可能な処理モジュールの中から処理モジュールを選択してパケットを出力するので、自律的に各処理モジュール間をパケットが移動するようになり、複数の処理モジュールを並列に動作させることが可能となる。

ハードウェア処理モジュールとＣＰＵとを組合わせたデータ処理装置における問題点を説明するための図である。 処理モジュール１〜３に対してパイプラインで並列に処理を実行させた場合を示す図である。 本発明の第１の実施の形態におけるデータ処理装置の概略構成を示すブロック図である。 処理モジュールの構成例を示す図である。 各処理モジュール内のプログラムメモリ２４に記憶されるプログラム、パラメータなどの情報を示す図である。 パケットの構成例を示す図である。 アプリケーションのプログラムの一例を示す図である。 グラフィカル・ユーザ・インタフェースを用いて記述された処理フローの一例を示す図である。 ライブラリ・処理モジュール対応表６１の一例を示す図である。 処理モジュール・プロセス対応表６２の一例を示す図である。 本発明の第１の実施の形態におけるデータ処理装置のハードウェア実行準備を説明するための図である。 調停回路１６によるバス調停の処理手順を説明するためのフローチャートである。 本発明の第１の実施の形態におけるデータ処理装置をマルチモード対応無線通信ベースバンド回路に適用した場合を示す図である。 ソフトウェアの処理フローをどのようにデータ処理装置１にマッピングするかを示す図である。 図１４に示すマッピング後のデータ処理装置１におけるパケットの流れを説明するための図である。 本発明の第３の実施の形態におけるデータ処理装置の概略構成を示すブロック図である。 有効フラグを付加した処理モジュール・プロセス対応表６３の一例を示す図である。 故障回避機能を付加したデータ処理装置１の構成例を示すブロック図である。

上述の問題を解決するために、高性能、低消費電力の特徴を有するハードウェア処理モジュールと、高プログラマビリティ、高スケーラビリティの特徴を有するＣＰＵとの組み合わせによってデータ処理装置を実現する提案がなされている。

図１は、ハードウェア処理モジュールとＣＰＵとを組合わせたデータ処理装置における問題点を説明するための図である。図１においては、ＣＰＵがプログラムを実行しているときに、ハードウェア処理モジュール（以下、単に処理モジュールとも呼ぶ。）１〜３がシリアルに呼び出され、処理モジュール１〜３による処理がシリアルに実行される。すなわち、処理モジュール１による処理が終了した後に、処理モジュール２の処理が開始される。そして、処理モジュール２による処理が終了した後に、処理モジュール３の処理が開始される。

このように、ＣＰＵがプログラムを実行しているときに処理モジュールをシリアルに呼び出す方式においては、同一時間に処理を実行できる処理モジュールは１つである。そのため、処理性能が低下する。

図２は、処理モジュール１〜３に対してパイプラインで並列に処理を実行させた場合を示す図である。処理モジュール１〜３が並列に処理を実行するため、図１に示す各処理モジュールがシリアルに処理を実行する場合と比較して、処理性能が向上する。

（第１の実施の形態）
図３は、本発明の第１の実施の形態におけるデータ処理装置の概略構成を示すブロック図である。このデータ処理装置１は、データ入力部１１と、コントローラ（ＣＰＵ）１２と、メモリ１３と、データ出力部１４と、処理モジュール１（２１−ａ，２１−ｂ）と、処理モジュール２（２２−ａ，２２−ｂ）と、処理モジュール３（２３−ａ，２３−ｂ）とを含み、これらがネットワーク１５を介して接続される。このネットワーク１５は、例えばスプリットトランザクションバス等のパケット転送型バスである。

データ入力部１１は、外部からデータを入力するためのモジュールであり、入力されたデータを処理単位にまとめてパケットを生成してネットワーク１５に出力する。このパケットの詳細については、後述する。

コントローラ１２は、データ処理装置１の全体的な制御を行なうモジュールであり、データ処理装置１の初期化動作において各処理モジュールのプログラムメモリ２４にプログラムおよびパラメータをロードする。コントローラ１２によるプログラムおよびパラメータのロードが終了すると、各処理モジュールはデータの入力待ち状態となる。

メモリ１３は、フラッシュメモリ、ＭＲＡＭ（Magnetoresistive Random Access Memory）などの不揮発性メモリ、またはＳＲＡＭ（Static Random Access Memory）などの揮発性メモリによって構成される。メモリ１３は、各処理モジュールにロードされるプログラム、パラメータなどの情報を記憶する。

データ出力部１４は、外部にデータを出力するためのモジュールであり、ネットワーク１５からパケットを受けると、そのパケットに含まれるデータを外部ＩＦ（Interface）のプロトコルに変換して出力する。

処理モジュール１（２１−ａ）および処理モジュール１（２１−ｂ）は、それぞれ同様の機能を有しており、同様の処理を選択的に実行することが可能である。また、処理モジュール２（２２−ａ）および処理モジュール２（２２−ｂ）についても同様である。また、処理モジュール３（２３−ａ）および処理モジュール３（２３−ｂ）についても同様である。

ネットワーク１５は、内部に調停回路１６を有しており、各モジュールから受けたパケットを調停し、次の処理を行なう処理モジュールに対してパケットを出力する。この調停回路１６の詳細については後述する。

図４は、処理モジュールの構成例を示す図である。この処理モジュールは、プログラムメモリ２４と、入出力制御部３１と、入出力用メモリ３２と、演算部３３と、演算用中間データ配置用メモリ３４と、演算制御部３５とを含む。

演算部３３は、ＦＰＵ（Floating Point Unit）やＤＳＰ（Digital Signal Processor）等のプログラムにより演算制御可能な演算器、若しくはＦＰＧＡ（Field Programmable Gate Array）等の論理・接続構成を再構築可能な回路で構成される。演算部３３が論理・接続構成を再構築可能な回路で構成される場合、演算制御部３５は演算処理を開始する前に、演算部３３の論理・接続構成を構築するための情報をメモリ１３等から読み出し、演算部３３の論理・接続構成を構築する処理を行なう。

入出力制御部３１は、ネットワーク１５に対するパケットの入出力を制御する。入出力制御部３１は、演算後のデータをパケットに格納してネットワーク１５に出力する際、後述するパケットの処理ステージ番号、処理プロセス番号などの情報を更新する。

入出力用メモリ３２は、ネットワーク１５から受けたパケットおよびネットワーク１５に出力するパケットを一時的に記憶する。

演算制御部３５は、プログラムメモリ２４に記憶される命令コードを順次デコードし、デコード結果に応じて演算部３３の演算処理を制御する。また、演算制御部３５は、デコード結果に応じてプログラムメモリ２４に記憶されるパラメータを演算用中間データ配置用メモリ３４に配置する。

演算用中間データ配置用メモリ３４は、演算部３３が演算を行なう際に使用するデータおよび演算部３３による演算途中のデータ（中間データ）を一時的に記憶する。演算部３３は、演算用中間データ配置用メモリ３４の内容を参照しながら演算処理を実行する。

図５は、各処理モジュール内のプログラムメモリ２４に記憶されるプログラム、パラメータなどの情報を示す図である。プログラムメモリ２４は、複数のプロセスに対応するプログラムを記憶しており、さらに処理ステージ番号がどの処理プロセス番号に対応するかを示す情報を記憶している。

各処理ステージの領域には、この処理ステージに対応する処理プロセス番号（プログラムの開始アドレス）、次の処理プロセス番号およびパラメータが記憶される。処理モジュールは、処理ステージ番号に対応した処理プロセス番号（プログラムの開始アドレス）を参照して、対応のプロセスの実行を開始する。このとき、その処理ステージに記憶されるパラメータが用いられる。

そして、そのプロセスの処理を終了すると、処理モジュールは次の処理プロセス番号を参照して処理後のデータを渡すプロセスを決定する。

図６は、パケットの構成例を示す図である。パケットは、パケット番号４１と、処理ステージ番号４２と、処理プロセス番号４３と、パケットサイズ４４と、データ本体４５とを含む。

パケット番号４１は、データ入力部１１によって付加され、最初のパケットに対しては“０”、次のパケットに対しては“１”というように順次インクリメントした値が付加される。調停回路１６は、パケット番号４１が小さいデータを優先する。

処理ステージ番号４２は、当該パケットデータが何番目の処理ステージに対応するかを示す。

処理プロセス番号４３は、選択可能な処理モジュール群を示す。どの処理モジュールで処理を実行するかは、調停回路１６によって決定される。たとえば、ＦＦＴ（Fast Fourier Transform）などのように同じ処理を２回実行する場合、処理プロセス番号が同一となるため、この処理プロセス番号４３だけで次の処理プロセスを決定することはできない。しかしながら、１回目の処理と２回目の処理とでは処理ステージ番号が異なるので、処理ステージ番号４２と処理プロセス番号４３との両方の情報を用いることで、次の処理プロセスを決定することができる。

パケットサイズ４４は、アプリケーション中でサイズの異なるパケットを扱う場合に必要となる情報である。アプリケーション中で用いるパケットのサイズが全て同じであれば、このパケットサイズは不要である。

調停回路１６は、各モジュールからのパケットを受けると、パケット番号４１の小さいパケットを優先してバス調停を行なう。パケット番号４１のビット数は予め決められており、パケット番号が有限であるため入力されるパケットのパケット番号が上限を超える場合も想定される。そのときは、パケット番号を“０”に戻し、ラップアラウンド方式でバス調停を行なう。

すなわち、調停回路１６は、パケット番号４１の上位２ビットを比較し、それぞれのパケットの上位２ビットが“００”および“０１”であれば、“００”の方のパケットを優先する。それぞれのパケットの上位２ビットが“０１”および“１０”であれば、“０１”の方のパケットを優先する。それぞれのパケットの上位２ビットが“１０”および“１１”であれば、“１０”の方のパケットを優先する。それぞれのパケットの上位２ビットが“１１”および“００”であれば、“１１”の方のパケットを優先する。

パケット番号４１の上位２ビットが同じ場合には、調停回路１６は、上位２ビット以外のビットを比較し、小さい方のパケットを優先する。

調停回路１６は、動的調停および静的調停のいずれかの方法でバス調停を行なう。動的調停とは、調停回路１６がパケットを受けたときに、各処理ステージに対応する処理を行なう処理モジュールを決定する方法である。処理データのサイズや頻度を予想しなくても、処理を各処理モジュールに平均的に分散することができる。

たとえば、調停回路１６は、パケットの調停を行なってパケットを出力した処理モジュールを処理実行中の処理モジュールとして登録する。そして、その処理モジュールから処理後のデータを格納したパケットを受けたときに、その処理モジュールを処理待ち状態の処理モジュールとして登録する。これによって、処理待ち状態の処理モジュールと処理中の処理モジュールとを区別し、負荷を分散させることができる。

一方、静的調停とは、アプリケーション実行前に、各処理ステージに対応する処理を行なう処理モジュールを予め決めておく方法である。処理データのサイズや頻度がが予め予測できる場合に有効であり、調停回路１６のハードウェアの規模を小さくすることができる。

図７は、アプリケーションのプログラムの一例を示す図である。図７に示すように、アプリケーションのプログラムは、アプリケーションを構成する複数のプロセスの集合として記述される。各プロセスは、Ｃ言語などのようなよく使用される記述言語のライブラリとして提供され、そのライブラリを用いてアプリケーション処理フローが記述される。

図７においては、データ入力の処理プロセスとして“Ｓｔｒｅａｍ＿ｉｎｐｕｔ（）；”が記述され、ＦＦＴの処理プロセスとして“ＦＦＴ（）；”が記述され、インターリーブの処理プロセスとして“Ｉｎｔｅｒｌｅａｖｅ（）；”が記述され、データ出力の処理プロセスとして“Ｓｔｒｅａｍ＿ｏｕｔｐｕｔ（）；”が記述されている。

記述されたアプリケーションは、シミュレーション用ライブラリを用いてシミュレーションを行ない、実行結果を確認することが可能である。

図８は、グラフィカル・ユーザ・インタフェースを用いて記述された処理フローの一例を示す図である。処理フローの記述として、たとえばＭＡＴＬＡＢなどのグラフィカル・ユーザ・インタフェースが用いられる。図７に示すプログラムと同様に、この記述は、各ライブラリ５１〜５８を含んでおり、ライブラリの処理順序に従って記述される。

図７に示すプログラムや図８に示す処理フローにおける記述は各プロセスに対応しており、それらがどの処理モジュールで実行可能かの対応付けがなされる。図９は、ライブラリ・処理モジュール対応表６１の一例を示す図である。

図９において、たとえば、“ＦＦＴ”を実行可能な処理モジュールが“１”であり、“Ｉｎｔｅｒｌｅａｖｅ−１”を実行可能な処理モジュールが“２”であり、“Ｍａｐ”を実行可能な処理モジュールが“１”であることを示している。“Ｖｉｔｅｒｂｉ”、“Ｉｎｔｅｒｌｅａｖｅ−２”、“Ｒｅｅｄ Ｓｏｌｏｍｏｎ”についても同様である。あるプロセスを実行可能な処理モジュールは複数登録される。

図１０は、処理モジュール・プロセス対応表６２の一例を示す図である。アプリケーションを構成する全プロセスに対して、処理モジュールとの対応のリストが作成されて調停回路１６に記憶される。このとき、図７または図８に示す処理フローに基づいて、図５に示すような処理ステージ番号と次の処理プロセス番号との対応が作成されてメモリ１３に記憶される。

図１１は、本発明の第１の実施の形態におけるデータ処理装置のハードウェア実行準備を説明するための図である。データ処理装置１がリセットされると、システムが初期状態となる。システムの初期化動作において、コントローラ（ＣＰＵ）１２は、メモリ１３から各処理モジュール（２１−ａ〜２３−ａ，２１−ｂ〜２３−ｂ）のプログラムメモリ２４に、図５に示すようなプログラムおよびパラメータをロードする。

この処理が完了すると、システムはＲｅａｄｙ状態となり、データ入力部１１によるデータ入力および各処理モジュールによる処理が可能な状態となる。このとき、データ入力部１１は、データの入力待ち状態となる。

データ入力部１１は、外部からデータを入力すると、データを処理単位にまとめてパケットを生成し、パケット番号４１としてシリアル番号を付加し、パケットの処理ステージ番号４２に“１”を付加する。そして、データを最初に処理する処理プロセスに対応する処理プロセス番号４３を付加する。データ入力部１１は、生成したパケットをネットワーク１５に出力する。

ネットワーク１５内の調停回路１６は、バス調停を行なってパケットを処理モジュールに出力する。処理モジュールは、パケットが入力されると処理プロセス番号４３に対応したプログラムアドレスに分岐し、処理を実行する。このとき、処理モジュールは、ＦＦＴのポイント数などのパラメータに基づいて処理を行なう。

処理モジュールは処理を終了すると、パケットの処理ステージ番号４２をインクリメントし、処理プロセス番号４３を次の処理プロセス番号に基づいて更新する。そして、パケットをネットワーク１５に出力する。

各処理モジュールによる処理が終了し、データ出力部１４がパケットを受けると、パケットに含まれるデータを外部ＩＦのプロトコルに変換して出力する。

図１２は、調停回路１６によるバス調停の処理手順を説明するためのフローチャートである。まず、調停回路１６はデータパケットを入力すると（Ｓ１１）、図１０に示す処理プロセス番号と処理モジュールとの対応表（処理モジュール・プロセス対応表６２）を参照して、実行対象の処理モジュールを選択する（Ｓ１２）。この処理は、パケットの処理プロセス番号４３に基づいて行なわれ、上述のように動的調停または静的調停によって処理モジュールが選択される。

次に、調停回路１６は、同一処理モジュールに対する要求が複数あるか否かを判定する（Ｓ１３）。同一処理モジュールへの要求が複数ない場合には（Ｓ１３，Ｎｏ）、ステップＳ１６に処理が進む。

また、同一処理モジュールへの要求が複数ある場合には（Ｓ１３，Ｙｅｓ）、当該パケットのシリアル番号（パケット番号４１）が最小か否かを判定する（Ｓ１４）。当該パケットのシリアル番号が最小であれば（Ｓ１４，Ｙｅｓ）、ステップＳ１６に処理が進む。また、シリアル番号が最小でなければ（Ｓ１４、Ｎｏ）、そのパケットの出力を待たせる（Ｓ１５）。

同一時刻に同一処理モジュールへのストア要求が複数存在する可能性がある。この場合、パケットのシリアル番号が小さい方を優先して調停を行なう。これは、シリアル番号が小さい方のパケットを先行して処理を行なわないと、転送先の処理モジュールが処理中のままとなってしまい、システム全体の処理が停止してしまう可能性があるからである。

ステップＳ１６において、調停回路１６は、実行対象の処理モジュールがデータ入力可能か否かを判定する。実行対象の処理モジュールがデータ入力可能でなければ（Ｓ１６，Ｎｏ）、そのパケットの出力を待たせる（Ｓ１７）。

また、実行対象の処理モジュールがデータ入力可能であれば（Ｓ１６，Ｙｅｓ）、調停回路１６はそのデータパケットを実行対象の処理モジュールに出力して（Ｓ１８）、処理を終了する。

図１３は、本発明の第１の実施の形態におけるデータ処理装置をマルチモード対応無線通信ベースバンド回路に適用した場合を示す図である。このベースバンド回路は、ＲＦ／ベースバンド処理ＳｏＣ（データ処理装置）１と、アンテナ７１と、ＡＤ／ＤＡ／ＲＦ回路７２と、ＭＡＣ処理部８５とを含む。また、ＲＦ／ベースバンド処理ＳｏＣ１は、モジュール７３〜８４と、それらを接続するネットワーク１５とを含む。なお、各モジュール内のブロックは、プログラムによって実現される機能などを模式的に示したものである。

モジュール７９は、図３に示すデータ入力部１１に対応しており、ＡＤ／ＤＡ／ＲＦ回路７２とのインタフェースであるＡＤ／ＤＡ ＩＦと、メモリ（ＭＥＭ）と、ＬＤ／ＳＴ部とを含んでおり、上述のデータ入力部１１の処理を実行する。モジュール７９は、メモリ（ＭＥＭ）を使用しながらパケットを生成し、ＬＤ／ＳＴ部によって生成したパケットをネットワーク１５に出力させる。ＬＤ／ＳＴ部は、図４に示す入出力制御部３１に対応している。

処理モジュール７４および８０は同等の機能を有しており、同一の処理プロセスを実行可能である。この処理モジュール７４および８０は、プログラムメモリ２４に記憶されるプログラムを実行することにより、主にＭＡＣ（Multiply Accumulate）演算によって処理を行なう処理モジュールである。

処理モジュール７５および８１は同等の機能を有しており、同一の処理プロセスを実行可能である。この処理モジュール７５および８１は、プログラムメモリ２４に記憶されるプログラムを実行することにより、主に遅延演算によって処理を行なう処理モジュールである。

処理モジュール７６および８２は同等の機能を有しており、同一の処理プロセスを実行可能である。この処理モジュール７６および８２は、プログラムメモリ２４に記憶されるプログラムを実行することにより、主に加算演算によって処理を行なう処理モジュールである。

モジュール８４は、図３に示すデータ出力部１４に対応しており、ＭＡＣ処理部８５とのインタフェースであるＭＡＣ ＩＦと、メモリ（ＭＥＭ）と、ＬＤ／ＳＴ部とを含んでおり、上述のデータ出力部１４の処理を実行する。

なお、モジュール７７および８３は、それぞれ図３に示すコントローラ１２およびメモリ１３に対応している。また、モジュール７３および７８は、それぞれＲＦ（Radio Frequency）部および周辺機器に対応する機能を有するモジュールである。

図１４は、ソフトウェアの処理フローをどのようにデータ処理装置１にマッピングするかを示す図である。図１４（ａ）は、Ｃ言語によって記述されたプログラムを示しており、図７に示すものと同様である。また、図１４（ｂ）は、ＭＡＴＬＡＢによって記述されたフローチャートを示しており、図８に示すものと同様である。

図１４（ｃ）は、図１４（ａ）または図１４（ｂ）に示す記述を各処理モジュールにマッピングしたところを示している。記述５１〜５８がそれぞれ、処理モジュール７９，７４，７５，８０，７６，８１，８２および８４にマッピングされる。

図１５は、図１４に示すマッピング後のデータ処理装置１におけるパケットの流れを説明するための図である。Ｓｔｒｅａｍ ｉｎｐｕｔ５１に対応する処理モジュール７９によってパケットが生成されると、ＦＦＴ５２に対応する処理モジュール７４に出力され、処理モジュール７４によるＦＦＴ処理が行なわれる。

処理モジュール７４による処理が終了すると、処理後のデータがパケットに格納されてＩｎｔｅｒｌｅａｖｅ５３に対応する処理モジュール７５に出力され、処理モジュール７５によるインターリーブ処理が行なわれる。

処理モジュール７５による処理が終了すると、処理後のデータがパケットに格納されてＭａｐ５４に対応する処理モジュールに出力される。このとき、Ｍａｐ処理を実行可能な処理モジュールが２つあるため、調停回路１６は処理モジュール７４および８０のいずれに処理を行なわせるかを各処理モジュールの負荷状態に応じて決定する。図１５において、調停回路１６は、負荷の軽い処理モジュール８０を選択して処理を実行させる。

以上説明したように、本実施の形態におけるデータ処理装置によれば、処理すべきデータを格納したパケットにシリアル番号を持たせ、自律的に各処理モジュール間をパケットが移動するようにしたので、複数の処理モジュールを並列に動作させることができ、いわゆるパイプライン処理を実現することが可能となった。

また、処理モジュールのプログラムメモリに記憶するプログラムを変更することによって処理モジュールの機能を変更することができるため、高プログラマビリティおよび高スケーラビリティを実現することが可能となった。さらに、高性能、低消費電力、低開発費、短納期が可能なデータ処理装置を提供することが可能となった。

また、処理フローをＣ言語などのよく使われる記述言語のライブラリを用いて記述できるため、ソフトウェアの開発が容易となる。

（第２の実施の形態）
本発明の第２の実施の形態におけるデータ処理装置は、各処理モジュール内のメモリを複数バンク化するものである。

図１３に示すベースバンド回路のように、処理モジュール７３〜８４はそれぞれ２つのメモリ（ＭＥＭ）を有しており、一方が処理モジュールの内部データを格納するメモリとして使用され、他方が外部の処理モジュールとのデータ入出力に使用される。これによって、処理モジュールによる演算処理とデータ入出力処理とが並列に行なえる。

以上説明したように、本実施の形態におけるデータ処理装置によれば、処理モジュールのメモリを複数バンク化するようにしたので、処理モジュールによる演算処理とデータ入出力処理とが並列に行なえ、データ処理装置の処理効率をさらに向上させることが可能となった。

（第３の実施の形態）
図１６は、本発明の第３の実施の形態におけるデータ処理装置の概略構成を示すブロック図である。図３に示す第１の実施の形態におけるデータ処理装置と比較して、ネットワーク内に電源制御部１７を設けた点のみが異なる。したがって、重複する構成および機能の詳細な説明は繰り返さない。

電源制御部１７は、調停回路１６から出力される制御情報に基づいて、各処理モジュールの電源のオン／オフを制御する。すなわち、調停回路１６は、パケットの調停を行なう際に電源制御部１７にパケットを出力する処理モジュールの電源をオンさせた後にパケットを送信する。そして、その処理モジュールからパケットを受けたときに、その処理モジュールの処理が終了したものとして電源制御部１７にその処理モジュールの電源をオフさせる。なお、この電源制御に関してはＣＰＵ１２が介在せず、自律的に電源制御が行なわれる。また、記憶素子を不揮発デバイスで構成し、電源オフの場合でもデータを保持できるようにする。

以上説明したように、本実施の形態におけるデータ処理装置によれば、処理モジュールが処理を行なっていない場合には電源がオフとなり、消費電力を削減することが可能となった。

また、記憶素子に不揮発デバイスを利用するため、電源をオンした後の処理モジュールによる処理が直ちに行なえるようになる。

（第４の実施の形態）
本発明の第４の実施の形態におけるデータ処理装置は、定期的に各処理モジュールの故障診断を行ない、各処理モジュールが処理実行可能か否かを判断してパケットを出力するものである。図３に示す第１の実施の形態におけるデータ処理装置と比較して、調停回路内の処理モジュール・プロセス対応表に有効フラグが付加された点のみが異なる。したがって、重複する構成および機能の詳細な説明は繰り返さない。

図１７は、有効フラグを付加した処理モジュール・プロセス対応表の一例を示す図である。この処理モジュール・プロセス対応表６３には、各処理モジュールが処理可能か否かを示す有効フラグが付加されている。たとえば、処理モジュール１（２１−ａ）は有効であり、処理モジュール１（２１−ｂ）が無効であることを示している。

図１８は、故障回避機能を付加したデータ処理装置の構成例を示すブロック図である。コントローラ１２は、各処理モジュールに対して故障診断プログラムを実行して、対象モジュールが故障しているか否かを判断する。調停回路１６は、その診断結果をコントローラ１２から受けて有効フラグとして処理モジュール・プロセス対応表６３に追加する。

調停回路１６は、パケットを調停する際に有効フラグを参照し、有効フラグが“無効”となっている処理モジュールに対する処理の割り当てを行なわない。すなわち、それまで故障した処理モジュールに割り当てられていた処理を動的に他の処理モジュールに割り当て変更することで、システムとしての故障回避を実現する。

図１８においては、処理モジュール１（２１−ｂ）および処理モジュール２（２２−ｂ）が故障と診断されており、この２つの処理モジュールに対する処理の割り当ては行なわれないことを示している。

以上説明したように、本実施の形態におけるデータ処理装置によれば、定期的に故障診断を行ない、故障した処理モジュールに対して処理を割り当てないようにしたので、自律的に故障回避を実現することができ、システムとしての信頼性を向上させることが可能となった。

（第５の実施の形態）
本発明の第５の実施の形態におけるデータ処理装置は、各処理モジュールがパケットにデータを格納する際にデータを圧縮して格納し、そのパケットを受けた処理モジュールがデータを伸張するものである。

図４に示す処理モジュールにおいて、処理モジュール内の入出力制御部３１が、パケットにデータを格納する際、予め決められた方法でデータを圧縮して格納してネットワーク１５に出力する。また、入出力制御部３１は、ネットワーク１５からパケットを受けると、そのパケットに含まれるデータに対して予め決められた方法でデータを伸張する。

圧縮／伸張方法として、データのカテゴリ、たとえば動画、静止画、音声などの種類によって分類された方法が用いられる。入出力制御部３１は、転送されるデータをモニタリングし、そのデータの特徴に合わせて圧縮率が高くなる方法で圧縮を行なう。この圧縮／伸張処理は、ハードウェアおよびソフトウェアのいずれであっても構わない。

以上説明したように、パケットに格納するデータを圧縮するようにしたので、バスで転送されるデータ量が削減し、バスの広帯域化および低消費電力化が可能となった。

今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ データ処理装置、１１ データ入力部、１２ コントローラ、１３ メモリ、１４ データ出力部、１５ ネットワーク、１６ 調停回路、１７ 電源制御部、２１−ａ，２１−ｂ，２２−ａ，２２−ｂ，２３−ａ，２３−ｂ，７３〜８４ 処理モジュール、２４ プログラムメモリ、３１ 入出力制御部、３２ 入出力用メモリ、３３ 演算部、３４ 演算用中間データ配置用メモリ、３５ 演算制御部、４１ パケット番号、４２ 処理ステージ番号、４３ 処理プロセス番号、４４ パケットサイズ、４５ データ本体、６１ ライブラリ・処理モジュール対応表、６２，６３ 処理モジュール・プロセス対応表、７１ アンテナ、７２ ＡＤ／ＤＡ／ＲＦ部、８５ ＭＡＣ処理部。

Claims (10)

1. 複数の処理モジュールがネットワークによって接続されたデータ処理装置であって、
   前記複数の処理モジュールのそれぞれに処理フローに対応する処理プロセスが割り当てられ、前記複数の処理モジュールの中の少なくとも２つの処理モジュールが同じ処理プロセスを実行可能であり、
   前記ネットワークは、第１の処理モジュールからパケットを受けると、パケットに付加された処理プロセス番号に応じて当該処理プロセスを実行可能な処理モジュールの中から第２の処理モジュールを選択して前記パケットを出力する調停手段を含む、データ処理装置。
2. 前記第２の処理モジュールは前記調停手段から前記パケットを受けると、前記処理プロセス番号に対応する処理を行ない、前記パケットに処理後のデータと次の処理プロセス番号を格納して前記ネットワークに出力する、請求項１記載のデータ処理装置。
3. 前記データ処理装置はさらに、外部から入力したデータを処理単位にまとめて前記パケットを生成し、該パケットにシリアル番号および前記処理プロセス番号を付加して前記ネットワークに出力するデータ入力手段を含む、請求項１または２記載のデータ処理装置。
4. 前記調停手段は、前記パケットに付加された前記シリアル番号に基づいてパケット出力の優先度を判定してバス調停を行なう、請求項３記載のデータ処理装置。
5. 前記調停手段は、処理モジュールと処理モジュールが実行可能な処理プロセスとの対応表を有しており、前記パケットに付加された処理プロセス番号と前記対応表とに基づいて前記パケットを出力する処理モジュールを決定する、請求項１記載のデータ処理装置。
6. 前記第２の処理モジュールは、演算処理を行なうときに使用する第１のメモリと、前記ネットワークとの間でパケットを入出力するときに使用する第２のメモリとをバンクメモリとして有し、前記演算処理および前記パケット入出力処理を並列に行なう、請求項１記載のデータ処理装置。
7. 前記データ処理装置はさらに、前記複数の処理モジュールのそれぞれの電源を制御する電源制御手段を含み、
   前記調停手段は、処理モジュールの処理開始時に当該処理モジュールの電源をオンするよう前記電源制御手段を制御し、処理モジュールの処理終了時に当該処理モジュールの電源をオフするよう前記電源制御手段を制御する、請求項１記載のデータ処理装置。
8. 前記処理モジュールが実行するプログラムを記憶するメモリが不揮発メモリによって構成される、請求項７記載のデータ処理装置。
9. 前記データ処理装置はさらに、前記複数の処理モジュールの故障診断を行なう故障診断手段を含み、
   前記調停手段は、前記故障診断手段によって故障と診断された処理モジュールを除外して前記パケットを出力する処理モジュールを選択する、請求項１記載のデータ処理装置。
10. 前記複数の処理モジュールの少なくとも１つは、処理後のデータを圧縮して前記パケットに格納する圧縮手段を含む、請求項１記載のデータ処理装置。

Images