JP6515602B2 - データ処理装置及びデータ処理方法 - Google Patents

Description

本発明は、バッファメモリの管理に関する。

バッファメモリの記憶容量を有効に利用するための種々の技術が知られている（例えば、特許文献１）。一般に、読み出し側と書き込み側で動作周波数及びデータバス幅が異なる場合には、データバス幅が太い（大きい）方に合わせてバッファメモリの管理が行われている。

特開平２−２７８９３８号公報

上述した管理方法では、管理されているデータバス幅よりも少ない容量でリードリクエストが発生した場合に、バッファメモリの容量を使い切れるようなリードリクエストを発行することができなかった。

本発明は、読み出し側と書き込み側のデータバス幅が異なる場合において、バッファメモリを効率的に使用できるようにすることを目的の一つとする。

本発明は、一の態様において、バッファメモリと、第１の動作周波数で動作するとともにｍビットのデータバス幅を有し、前記バッファメモリにデータを書き込む第１の処理手段と、前記第１の動作周波数よりも低い第２の動作周波数で動作するとともにｎビット（ただし、ｎはｎ＞ｍを満たすｍの倍数）のデータバス幅を有し、前記バッファメモリからデータを読み出す第２の処理手段と、前記バッファメモリに記憶されるデータを管理する管理手段とを備え、前記バッファメモリは、前記第２の処理手段からのリクエストに応じて前記第１の処理手段が受信したデータを記憶し、前記管理手段は、前記バッファメモリに記憶されるデータに対してｍビット単位で付与される識別子に基づいて当該データを管理し、前記第２の処理手段は、前記バッファメモリから読み出したデータを前記識別子に基づいて並べ替えてｎビットのデータを生成するデータ処理装置を提供する。

本発明によれば、読み出し側と書き込み側のデータバス幅が異なる場合において、バッファメモリを効率的に使用することが可能である。

図１は、データ処理装置１０の構成を示すブロック図である。 図２は、リプライ管理部７の構成を示すブロック図である。 図３は、データサイズとデータ位置の対応関係を示す図である。 図４は、リプライデータの生成手順を例示する図である。 図５は、データ処理装置１０の動作を示すフローチャートである。 図６は、リプライ管理部７ａの構成を示すブロック図である。 図７は、データ処理装置２０のハードウェア構成を示すブロック図である。

［実施形態］
図１は、本発明の一実施形態に係るデータ処理装置１０の構成を示すブロック図である。データ処理装置１０は、リクエスト送信部１と、リクエスト受信部２と、リクエストバッファ３と、リクエスト生成部４と、リプライ受信部５と、リプライバッファ６と、リプライ管理部７と、リプライ送信部８と、リプライ受信部９とを備える。

データ処理装置１０において、リクエスト生成部４及びリプライ受信部５は、メモリ等を含む図示せぬ外部装置に接続されている。この外部装置は、データ処理装置１０からのリクエストに応じたデータ（以下「リプライデータ」という。）をデータ処理装置１０に送信する。なお、リクエストとリプライデータは、後述するＩＤによって互いに関連付けられている。

データ処理装置１０は、動作周波数が異なる回路を組み合わせて構成されている。具体的には、図１中のリクエストバッファ３及びリプライバッファ６よりも下段にある回路（リクエスト生成部４、リプライ受信部５など）は、第１の動作周波数で動作する。これに対し、リクエストバッファ３及びリプライバッファ６よりも上段にある回路（リクエスト受信部２、リプライ送信部８など）は、第１の動作周波数よりも遅い（低い）第２の動作周波数で動作する。

リクエスト送信部１は、データの読み書きを行う場合に、リクエスト受信部２にリクエストを送信する。ここでいうリクエストには、データの読み出しを要求するリードリクエストと、データの書き込みを要求するライトリクエストとが含まれる。リクエスト送信部１は、リクエスト受信部２がリクエストを受信可能である場合に、リクエスト受信部２にリクエストを送信する。なお、リクエスト受信部２がリクエストを受信可能な状態とは、例えば、リクエストバッファ３に空きがある状態である。

リクエスト受信部２は、リクエスト送信部１からリクエストを受信する。リクエスト受信部２は、リクエスト送信部１から受信したリクエストをリクエストバッファ３に格納し、格納したリクエストのアドレス（ライトアドレス）をリクエスト生成部４に供給する。

リクエストバッファ３は、リクエスト受信部２から供給されたリクエストを記憶するバッファメモリである。また、リクエストバッファ３は、リクエスト生成部４から読み出し指示があった場合にデータを出力する。また、リクエストバッファ３は、リクエスト受信部２とリクエスト生成部４とで動作周波数が異なるため、いわゆる周波数の乗り換えを実行する。

リクエスト生成部４は、リクエスト受信部２により格納されたリクエストをリクエストバッファ３から読み出す。リクエスト生成部４は、リクエストを読み出したら、読み出したリクエストのアドレス（リードアドレス）をリクエスト受信部２に供給する。

また、リクエスト生成部４は、リクエスト受信部２からライトアドレスを受け取り、リードアドレスと比較する。リクエスト生成部４は、ライトアドレスとリードアドレスに差分があり、リクエストを受け取ることができる場合に、リクエストバッファ３に対して読み出し指示を行い、リクエストを受け取る。

リクエスト生成部４は、リクエストがリードリクエストであった場合には、所定のデータサイズに応じたＩＤを付与したリクエストを外部装置に対して発行する。また、リクエスト生成部４は、ＩＤ、データサイズ、データ位置及びスタートフラグをリプライ管理部７に供給する。

一例として、本実施形態においては、リードリクエストにより要求可能なデータのサイズが８／１６／３２ビットのいずれかであるとする。この場合において、リクエスト生成部４は、リプライ送信部８が送信するデータバス幅（すなわち第２の動作周波数側のデータバス幅）が３２ビット幅であり、リプライ受信部５が受信するデータバス幅（すなわち第１の動作周波数側のデータバス幅）が８ビット幅であるときには、８ビット単位でＩＤを付加してリクエストを生成する。この場合、データ位置は、この８ビット単位のデータが３２ビットのどの位置に相当するか（すなわち並び替え後の位置）を例えば２ビットの値（００、０１、１０、１１）で表す。また、スタートフラグは、要求されたデータのうちの最初の８ビットを識別するためのフラグであり、該当するデータについてのみ「１」となり、その他のデータについて「０」となる。リクエスト生成部４は、例えば、要求されたデータが１６ビットである場合には、８ビットずつに分割した２個のリードリクエストを発行する。

リプライ受信部５は、リクエストに応じて外部装置から送信されたリプライデータのＩＤを参照し、リプライバッファ６の当該ＩＤに対応する格納場所にリプライデータを書き込む。また、リプライ受信部５は、このＩＤをリプライ管理部７に送る。

リプライバッファ６は、リプライデータを記憶するバッファメモリである。リプライバッファ６においては、第１の動作周波数側のデータバス幅でデータ及びＩＤが管理されている。図１の例では、第２の動作周波数側のデータバス幅が３２ビット、第１の動作周波数側のデータバス幅が８ビットである。そのため、リプライバッファ６は、３２ビットのデータが同時に読み出せるように、ＩＤによって８ビット単位で管理された格納場所を４組ずつ用意している。図１に示すように、リプライバッファ６は、データの格納場所がＩＤ（＃０、＃１、…、＃ｎ）によって決められている。リプライバッファ６は、リプライ受信部５から送られるＩＤに基づいてデータを書き込む。例えば、データサイズがそれぞれ８ビット、１６ビットの２個のリードリクエストが供給された場合、最初の８ビットのリードリクエストに応じたデータが＃０、次の１６ビットのリードリクエストに応じたデータが＃１、＃２に、それぞれ格納される。また、リプライバッファ６は、リプライ管理部７から読み出し指示が供給された場合には、該当するデータを読み出してリプライ送信部８に供給する。

リプライ管理部７は、リプライデータをＩＤに基づいて管理する。具体的には、リプライ管理部７は、リプライデータを８ビットに分割した単位によって管理する。以下においては、必要に応じて、このように分割されたリプライデータのそれぞれのことを「分割データ」ともいう。

図２は、リプライ管理部７の構成をより詳細に示すブロック図である。リプライ管理部７は、レジスタ設定部７１と、レジスタ７２と、ＩＤ比較部７３とを備える。

レジスタ設定部７１は、レジスタ７２にデータを設定する。レジスタ設定部７１は、より詳細には、リクエスト生成部４から送られるＩＤに対応したエントリに、データサイズ、データ位置及びスタートフラグを格納する。また、レジスタ設定部７１は、これらのデータを格納したら、有効フラグをオフからオン（０から１）にする。レジスタ７２は、有効フラグ、データサイズ、データ位置、スタートフラグ及び受信完了フラグをＩＤと関連付けて記憶する。

ＩＤ比較部７３は、リプライ受信部５からＩＤを受け取ったら、レジスタ７２の当該ＩＤに対応する有効フラグを参照し、有効フラグがオン（１）であれば受信完了フラグをオンにする。同時に、ＩＤ比較部７３は、データサイズ、スタートフラグおよび受信完了フラグを参照し、要求されたデータが全て格納されているか判断する。この判断は、スタートフラグがオンであるエントリのデータサイズを参照し、参照したデータサイズ分のデータの受信が完了しているか否かを受信完了フラグによって判断することで可能である。

ＩＤ比較部７３は、要求された分割データが全て格納されていた場合には、リプライバッファ６に対して読み出し指示を実行する。このとき、ＩＤ比較部７３は、リプライ送信部８に対してＩＤとデータ位置を通知するとともに、読み出し指示によって解放されるエントリ数（すなわちＩＤ数）をリクエスト生成部４に対して通知する。レジスタ設定部７１は、分割データの読み出し後、読み出したデータ位置に対応する有効フラグをオフにする。

リプライ管理部７は、リプライバッファ６の解放に際し、ＩＤ順（ここでは昇順）にのみ分割データが解放されるように制限する。これにより、分割データが順不同（out of order）でデータ処理装置１０に入力された場合であっても、リクエスト順（in order）に並んだリプライデータを生成することが可能となる。

リプライ送信部８は、リプライ管理部７から受け取ったＩＤ及びデータ位置を用いて、リプライバッファ６から供給される分割データを並び替えて３２ビットのリプライデータを生成する。リプライ送信部８は、生成したリプライデータをリプライ受信部９に送信する。リプライ受信部９は、リプライ送信部８からリプライデータを受信して出力する。

図３は、データサイズとデータ位置の対応関係を示す図である。リプライ送信部８は、リプライ管理部７から受け取ったＩＤに基づいてリプライバッファ６における分割データの格納場所を判断するとともに、リプライ管理部７から受け取ったデータ位置に基づいて３２ビット中のどの位置に当該分割データを配置するか判断する。なお、分割データが要求されていない格納場所（図中のハッチングで示されていない部分）に関しては、データの値は不定とする。ここにおいて、不定とは、値を問わないことをいい、例えば、以前のデータのままであっても一定値（０）であってもよい。

図４は、リプライ送信部８によるリプライデータの生成手順を例示する図である。ここでは、リプライ管理部７からＩＤ及びデータ位置が“＃３，１０”、“＃４，１１”である８ビットのデータがそれぞれ要求された場合を示している。このとき、リプライ送信部８は、先頭の１６ビットを不定とし、ここにＩＤがそれぞれ「＃３」、「＃４」である８ビットの分割データを付加して３２ビットのリプライデータを生成する。

図５は、データ処理装置１０の動作を示すフローチャートである。データ処理装置１０は、リードリクエスト又はライトリクエストに応じて以下に示すように動作する。

ステップＳ１において、リクエスト受信部２は、リクエスト送信部１からリクエストを受信し、受信したリクエストをリクエストバッファ３に格納する。リクエストの格納後、リクエスト受信部２は、ライトアドレスをインクリメント（＋１）する。

ステップＳ２において、リクエスト生成部４は、リクエストバッファ３にリクエストが格納されているか否かを判断する。リクエスト生成部４は、自らがカウントしているリードアドレスとリクエスト受信部２によりカウントされたライトアドレスとを比較し、読み出すべきリクエストが格納されているか否かを両者の異同に基づいて判断する。

ライトアドレスがリードアドレスより大きい場合、リクエストバッファ３には、リクエスト生成部４がまだ読み出していないリクエストが存在する。この場合（ステップＳ２：ＹＥＳ）、リクエスト生成部４は、読み出していないリクエストをリクエストバッファ３から読み出す（ステップＳ３）。リクエストを読み出した後、リクエスト生成部４は、リードアドレスをインクリメントする。

一方、リードアドレスとライトアドレスが等しい場合、リクエストバッファ３には、新たに読み出すべきリクエストが格納されていない。この場合（ステップＳ２：ＮＯ）、リクエスト生成部４は、新たなリクエストが格納されるまで待機する。

ステップＳ４において、リクエスト生成部４は、読み出したリクエストがリードリクエスト又はライトリクエストのいずれであるかを判断する。ライトアドレスを読み出した場合（ステップＳ４：ＹＥＳ）、リクエスト生成部４は、外部装置に対してライトリクエストを発行する（ステップＳ５）。

一方、リードリクエストを読み出した場合（ステップＳ４：ＮＯ）、リクエスト生成部４は、データサイズを判定する（ステップＳ６）。続いて、リクエスト生成部４は、ステップＳ７において、データサイズに応じたＩＤを生成し、生成したＩＤ、データサイズ、データ位置及びスタートフラグといった情報をリプライ管理部７に渡す。リプライ管理部７は、リクエスト生成部４から渡された情報を内部に保持する。

ステップＳ８において、リクエスト生成部４は、生成したＩＤを用いてリードリクエストを外部装置に発行する。続いて、リクエスト生成部４は、ステップＳ９において、リクエストによって要求されたデータ分のリードリクエストを外部装置に対して発行したか否かを判断する（ステップＳ９）。ここで、必要なリードリクエストが発行されていない場合（ステップＳ９：ＮＯ）、リクエスト生成部４は、ステップＳ８の処理を繰り返す。

一方、必要なリードリクエストが発行されていれば（ステップＳ９：ＹＥＳ）、リプライ受信部５は、リードリクエストに応じたリプライデータ（分割データ）の受信（すなわち返却）を待機し、受信したリプライデータをリプライバッファ６に格納する（ステップＳ１０）。このとき、リプライ受信部５は、リプライデータに付与されたＩＤに応じた格納場所にリプライデータを格納する。また、リプライ受信部５は、格納したリプライデータのＩＤをリプライ管理部７に通知する。

ステップＳ１１において、リプライ管理部７は、リードリクエストによって要求された分のリプライデータが格納されたか否かをＩＤに基づいて判断する。リプライ管理部７は、リードリクエストによって要求された分のリプライデータがまだ格納されていなければ（ステップＳ１１：ＮＯ）、リプライ受信部５による格納を待機する。

一方、リードリクエストによって要求された分のリプライデータが格納されていた場合（ステップＳ１１：ＹＥＳ）、リプライ管理部７は、当該リプライデータをリプライバッファ６から読み出す読み出し指示を実行する（ステップＳ１２）。

ステップＳ１３において、リプライ送信部８は、リプライバッファ６から読み出された分割データを受信してリプライデータを生成する。リプライ送信部８は、リプライ管理部７から供給されるＩＤ及びデータ位置を用いることでリプライデータを生成することができる。リプライ送信部８は、生成したリプライデータをリプライ受信部９に送信する。

以上のとおり、本実施形態によれば、リプライ管理部７が複数あるデータ幅のうちの小さい方（狭い方）に合わせてリプライデータを管理することにより、より多くのリプライデータを格納することが可能になる。例えば、本実施形態によれば、リードリクエストが８ビットのリクエストのみであるとした場合には、エントリ数の４倍のリードリクエストを処理することが可能である。したがって、本実施形態によれば、リプライバッファ６をより効率的に使用することが可能である。

また、本実施形態によれば、リプライ管理部７による管理によって、さまざまなサイズのリードリクエストに対して効率的にリプライバッファ６を使用することが可能である。これにより、小さいサイズのリードリクエストをより多く発行することが可能になる。

さらに、本実施形態によれば、分割データが順不同で返却された場合であっても、ＩＤに基づいて適切な順序で分割データを並び替えてリプライデータを生成することが可能である。したがって、ＩＤによるリプライデータの管理を行わない場合に比べ、データを並び替えるための内部論理回路等を別途設ける必要がなく、構成及び制御を簡略化することが可能である。
［変形例］
本発明は、上述した実施形態に限らず、以下の変形例に示す形態でも実施可能である。また、本発明は、複数の変形例を組み合わせてもよい。

（１）変形例１
図６は、リプライ管理部７ａの構成を示すブロック図である。リプライ管理部７ａは、上述したデータ処理装置１０に適用可能なリプライ管理部７（図２参照）の変形例である。つまり、データ処理装置１０は、リプライ管理部７をリプライ管理部７ａに置換可能である。リプライ管理部７ａは、リプライ管理部７と比較すると、レジスタ７２に代えてレジスタ７２ａを備える点において相違し、その他の点において共通の構成を有する。また、レジスタ７２ａは、関連ＩＤ情報を含む点においてレジスタ７２と異なる。

関連ＩＤ情報は、同一のリクエストに割り当てられるＩＤを示す情報である。ここにおいて、同一のリクエストとは、分割前に単一であったリクエスト同士をいう。例えば、１６ビット分のデータを要求するリクエストが２個のリクエストに分割された場合、リクエスト生成部４は、これらのリクエストに割り当てるＩＤを事前に決定しておく。この場合、２個のリクエストのうちの先行する一方のリクエストに対応するエントリには、後続する他方のリクエストに割り当てられたＩＤが関連ＩＤ情報として格納される。同様に、他方のリクエストに対応するエントリにも、一方のリクエストに割り当てられたＩＤが関連ＩＤ情報として格納される。また、３２ビット分のデータが要求される場合であれば、関連ＩＤ情報には３個のＩＤが格納される。

なお、有効な関連ＩＤ情報の数は、データサイズから判断することが可能である。リプライ管理部７ａは、リプライ受信部５から分割データのＩＤを受け取ると、当該ＩＤに対応するデータサイズに基づいて有効な関連ＩＤ情報の数を判断するとともに、関連ＩＤ情報に示されたＩＤに対応する受信完了フラグが全てオンであるか否かを判断する。リプライ管理部７ａは、これらの受信完了フラグが全てオンであれば、リプライデータの生成に必要な分割データが揃っていると判断し、読み出し指示を実行する。また、リプライ管理部７ａは、読み出した分割データに対応する有効フラグをオフにし、解放したＩＤをリクエスト生成部４に通知する。なお、この場合において、リクエスト生成部４は、ＩＤを順番に使用するのではなく、空いているＩＤから順次使用する。

本例においては、リプライデータが順不同で返却されるものの、ＩＤ順という制限を受けないため、リクエスト時に要求されたリプライデータが揃った時点でこれを返却することが可能になる。これにより、同一のリクエストでＩＤを連続して（連番で）確保する必要がなくなるため、リプライバッファ６をより効率的に使用することが可能になる。

（２）変形例２
図７は、本発明の別の実施形態に係るデータ処理装置２０のハードウェア構成を示すブロック図である。データ処理装置２０は、第１の処理部１１と、バッファメモリ１２と、第２の処理部１３と、管理部１４とを備える。データ処理装置２０は、第２の処理部１３からのリクエストに応じて外部装置から送信されるデータを第１の処理部１１において受信し、バッファメモリを介して第２の処理部１３に供給（返却）する。

第１の処理部１１は、バッファメモリ１２にデータを書き込む。第２の処理部１３は、バッファメモリ１２からデータを読み出す。第１の処理部１１と第２の処理部１３は、例えば、上述した実施形態のリプライ受信部６とリプライ送信部８にそれぞれ相当する。

ここにおいて、第１の処理部１１と第２の処理部１３は、互いに動作周波数及びデータバス幅が異なる。具体的には、第１の処理部１１の動作周波数をｆ_１（第１の動作周波数）、第２の処理部１３の動作周波数をｆ_２（第２の動作周波数）としたとき、これらはｆ_１＞ｆ_２を満たす関係にある。ただし、ｆ_１、ｆ_２の具体的な値は、特に限定されない。

また、第１の処理部１１及び第２の処理部１３のデータバス幅は、典型的には、８、１６、３２、６４ビットのいずれかである。なお、第２の処理部１３のデータバス幅は、第１の処理部１１のデータバス幅よりも大きい（太い）ものとする。以下においては、第１の処理部１１のデータバス幅をｍとし、第２の処理部１３のデータバス幅をｎとする。ここにおいて、ｍは１以上の整数であり、ｎはｎ＞ｍを満たすｍの倍数である。

バッファメモリ１２は、第１の処理部１１により書き込まれたデータを記憶する。バッファメモリ１２に記憶されたデータは、管理部１４による読み出し指示に応じて読み出される。バッファメモリ１２は、例えば、上述した実施形態のリプライバッファ６に相当する。

管理部１４は、バッファメモリ１２に記憶されるデータを管理する。管理部１４は、バッファメモリ１２に記憶されるデータに対してｍビット単位で付与される識別子に基づいて当該データを管理する。ここでいう識別子は、上述したＩＤに相当する。第２の処理部１３は、この識別子に基づいて、バッファメモリ１２から読み出したｍビット単位のデータを並べ替えてｎビットのデータを生成する。管理部１４は、例えば、上述した実施形態のリプライ管理部７に相当する。具体的には、リプライ管理部７においては、ｎ＝３２、ｍ＝８である。

本例においても、上述した実施形態と同様に、複数あるデータ幅のうちの小さい方（狭い方）に合わせてデータを管理することが可能であるため、バッファメモリ１２により多くのデータを効率的に格納することが可能である。

（３）変形例３
上述した実施形態におけるデータサイズやデータバス幅などの数値は、あくまでも一例である。本発明は、これらの数値について、その実施を妨げない範囲でさまざまな値を用いることが可能である。

１ リクエスト送信部
２ リクエスト受信部
３ リクエストバッファ
４ リクエスト生成部
５ リプライ受信部
６ リプライバッファ
７、７ａ リプライ管理部
７１ レジスタ設定部
７２ レジスタ
７３ ＩＤ比較部
８ リプライ送信部
９ リプライ受信部
１０、２０ データ処理装置
１１ 第１の処理部
１２ バッファメモリ
１３ 第２の処理部
１４ 管理部

Claims (7)

1. バッファメモリと、
   第１の動作周波数で動作するとともにｍビットのデータバス幅を有し、前記バッファメモリにデータを書き込む第１の処理手段と、
   前記第１の動作周波数よりも低い第２の動作周波数で動作するとともにｎビット（ただし、ｎはｎ＞ｍを満たすｍの倍数）のデータバス幅を有し、前記バッファメモリからデータを読み出す第２の処理手段と、
   前記バッファメモリに記憶されるデータを管理する管理手段とを備え、
   前記バッファメモリは、前記第２の処理手段からのリクエストに応じて前記第１の処理手段が受信したデータを記憶し、
   前記管理手段は、前記バッファメモリに記憶されるデータに対してｍビット単位で付与される識別子に基づいてｍビット単位のデータがｎビットのどの位置に相当するかを示す当該データのデータ位置を管理し、
   前記第２の処理手段は、前記識別子と前記データ位置とに基づいて前記バッファメモリから読み出したデータを並べ替えて、ｎビットのデータを生成する
   データ処理装置。
2. 前記リクエストは、ｍの倍数であってｎよりも小さいサイズのデータを要求するリクエストを含む
   請求項１に記載のデータ処理装置。
3. 前記管理手段は、前記データ位置を前記識別子と関連付けて記憶する
   請求項１又は２に記載のデータ処理装置。
4. 前記管理手段は、前記バッファメモリに記憶されるデータに対応する前記リクエストのデータサイズを前記識別子と関連付けて記憶する
   請求項１ないし３のいずれか１項に記載のデータ処理装置。
5. 前記管理手段は、前記バッファメモリのデータが前記識別子によって決められた順序で読み出されるように前記第２の処理手段による読み出しを制限する
   請求項１ないし４のいずれか１項に記載のデータ処理装置。
6. 前記管理手段は、前記バッファメモリに記憶される第１のデータ及び第２のデータが同一の前記リクエストに対応するデータである場合に、当該第１のデータ及び当該第２のデータの一方に付与された識別子を他方の識別子と関連付けて記憶する
   請求項１ないし４のいずれか１項に記載のデータ処理装置。
7. 第１の動作周波数で動作するとともにｍビットのデータバス幅を有する第１の処理手段によって、前記第１の動作周波数よりも低い第２の動作周波数で動作するとともにｎビット（ただし、ｎはｎ＞ｍを満たすｍの倍数）のデータバス幅を有する第２の処理手段からのリクエストに応じて受信されたデータをバッファメモリに書き込み、
   前記バッファメモリに記憶されるデータに対してｍビット単位で付与される識別子に基づいてｍビット単位のデータがｎビットのどの位置に相当するかを示す当該データのデータ位置を管理し、
   前記第２の処理手段によって前記バッファメモリからデータを読み出し、前記識別子と前記データ位置とに基づいて読み出したデータを並べ替えて、ｎビットのデータを生成する
   データ処理方法。

Images