JP2016170607A

JP2016170607A - Data processing apparatus and data processing method

Info

Publication number: JP2016170607A
Application number: JP2015049691A
Authority: JP
Inventors: 雅夫深川; Masao Fukagawa
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2015-03-12
Filing date: 2015-03-12
Publication date: 2016-09-23
Anticipated expiration: 2035-03-12
Also published as: JP6515602B2

Abstract

PROBLEM TO BE SOLVED: To efficiently use a buffer memory.SOLUTION: A data processing apparatus 20 includes: a buffer memory 12; a first processing section 11 which operates with a first operation frequency, has an m-bit data bus width, and writes data to the buffer memory 12; a second processing section 13 which operates with a second operation frequency lower than the first operation frequency, has an n-bit data bus width, and reads data from the buffer memory 12; and a management section 14 which manages data to be stored in the buffer memory 12. The buffer memory 12 stores the data received by the first processing section 11, in response to a request from the second processing section 13. The management section 14 manages the data to be stored in the buffer memory 12, on the basis of an identifier to be applied by m bits with respect to the data. The second processing section 13 rearranges the data read from the buffer memory 12, on the basis of the identifier, to generate n-bit data.SELECTED DRAWING: Figure 7

Description

本発明は、バッファメモリの管理に関する。 The present invention relates to buffer memory management.

バッファメモリの記憶容量を有効に利用するための種々の技術が知られている（例えば、特許文献１）。一般に、読み出し側と書き込み側で動作周波数及びデータバス幅が異なる場合には、データバス幅が太い（大きい）方に合わせてバッファメモリの管理が行われている。 Various techniques for effectively using the storage capacity of the buffer memory are known (for example, Patent Document 1). In general, when the operating frequency and the data bus width are different between the read side and the write side, the buffer memory is managed in accordance with the thicker (larger) data bus width.

特開平２−２７８９３８号公報JP-A-2-278938

上述した管理方法では、管理されているデータバス幅よりも少ない容量でリードリクエストが発生した場合に、バッファメモリの容量を使い切れるようなリードリクエストを発行することができなかった。 In the management method described above, when a read request is generated with a capacity smaller than the managed data bus width, a read request that can use up the capacity of the buffer memory cannot be issued.

本発明は、読み出し側と書き込み側のデータバス幅が異なる場合において、バッファメモリを効率的に使用できるようにすることを目的の一つとする。 An object of the present invention is to make it possible to efficiently use a buffer memory when the data bus widths on the read side and the write side are different.

本発明は、一の態様において、バッファメモリと、第１の動作周波数で動作するとともにｍビットのデータバス幅を有し、前記バッファメモリにデータを書き込む第１の処理手段と、前記第１の動作周波数よりも低い第２の動作周波数で動作するとともにｎビット（ただし、ｎはｎ＞ｍを満たすｍの倍数）のデータバス幅を有し、前記バッファメモリからデータを読み出す第２の処理手段と、前記バッファメモリに記憶されるデータを管理する管理手段とを備え、前記バッファメモリは、前記第２の処理手段からのリクエストに応じて前記第１の処理手段が受信したデータを記憶し、前記管理手段は、前記バッファメモリに記憶されるデータに対してｍビット単位で付与される識別子に基づいて当該データを管理し、前記第２の処理手段は、前記バッファメモリから読み出したデータを前記識別子に基づいて並べ替えてｎビットのデータを生成するデータ処理装置を提供する。 In one aspect, the present invention provides a buffer memory, a first processing unit that operates at a first operating frequency and has a data bus width of m bits, and writes data to the buffer memory; Second processing means for operating at a second operating frequency lower than the operating frequency and having a data bus width of n bits (where n is a multiple of m satisfying n> m) and reading data from the buffer memory And management means for managing data stored in the buffer memory, wherein the buffer memory stores data received by the first processing means in response to a request from the second processing means, The management means manages the data based on an identifier assigned to the data stored in the buffer memory in units of m bits, and the second processing means includes: The data read from the serial buffer memory to provide a data processing apparatus for generating an n-bit data are rearranged on the basis of the identifier.

本発明によれば、読み出し側と書き込み側のデータバス幅が異なる場合において、バッファメモリを効率的に使用することが可能である。 According to the present invention, the buffer memory can be used efficiently when the data bus widths on the read side and the write side are different.

図１は、データ処理装置１０の構成を示すブロック図である。FIG. 1 is a block diagram showing the configuration of the data processing apparatus 10. 図２は、リプライ管理部７の構成を示すブロック図である。FIG. 2 is a block diagram showing the configuration of the reply management unit 7. 図３は、データサイズとデータ位置の対応関係を示す図である。FIG. 3 is a diagram showing the correspondence between the data size and the data position. 図４は、リプライデータの生成手順を例示する図である。FIG. 4 is a diagram illustrating a procedure for generating reply data. 図５は、データ処理装置１０の動作を示すフローチャートである。FIG. 5 is a flowchart showing the operation of the data processing apparatus 10. 図６は、リプライ管理部７ａの構成を示すブロック図である。FIG. 6 is a block diagram showing the configuration of the reply management unit 7a. 図７は、データ処理装置２０のハードウェア構成を示すブロック図である。FIG. 7 is a block diagram illustrating a hardware configuration of the data processing device 20.

［実施形態］
図１は、本発明の一実施形態に係るデータ処理装置１０の構成を示すブロック図である。データ処理装置１０は、リクエスト送信部１と、リクエスト受信部２と、リクエストバッファ３と、リクエスト生成部４と、リプライ受信部５と、リプライバッファ６と、リプライ管理部７と、リプライ送信部８と、リプライ受信部９とを備える。 [Embodiment]
FIG. 1 is a block diagram showing a configuration of a data processing apparatus 10 according to an embodiment of the present invention. The data processing apparatus 10 includes a request transmission unit 1, a request reception unit 2, a request buffer 3, a request generation unit 4, a reply reception unit 5, a reply buffer 6, a reply management unit 7, and a reply transmission unit 8. And a reply receiving unit 9.

データ処理装置１０において、リクエスト生成部４及びリプライ受信部５は、メモリ等を含む図示せぬ外部装置に接続されている。この外部装置は、データ処理装置１０からのリクエストに応じたデータ（以下「リプライデータ」という。）をデータ処理装置１０に送信する。なお、リクエストとリプライデータは、後述するＩＤによって互いに関連付けられている。 In the data processing device 10, the request generator 4 and the reply receiver 5 are connected to an external device (not shown) including a memory and the like. This external device transmits data corresponding to the request from the data processing device 10 (hereinafter referred to as “reply data”) to the data processing device 10. The request and reply data are associated with each other by an ID described later.

データ処理装置１０は、動作周波数が異なる回路を組み合わせて構成されている。具体的には、図１中のリクエストバッファ３及びリプライバッファ６よりも下段にある回路（リクエスト生成部４、リプライ受信部５など）は、第１の動作周波数で動作する。これに対し、リクエストバッファ３及びリプライバッファ６よりも上段にある回路（リクエスト受信部２、リプライ送信部８など）は、第１の動作周波数よりも遅い（低い）第２の動作周波数で動作する。 The data processing apparatus 10 is configured by combining circuits having different operating frequencies. Specifically, the circuits (request generation unit 4, reply reception unit 5 and the like) below the request buffer 3 and reply buffer 6 in FIG. 1 operate at the first operating frequency. On the other hand, the circuits (request reception unit 2, reply transmission unit 8, etc.) above the request buffer 3 and the reply buffer 6 operate at a second operating frequency that is slower (lower) than the first operating frequency. .

リクエスト送信部１は、データの読み書きを行う場合に、リクエスト受信部２にリクエストを送信する。ここでいうリクエストには、データの読み出しを要求するリードリクエストと、データの書き込みを要求するライトリクエストとが含まれる。リクエスト送信部１は、リクエスト受信部２がリクエストを受信可能である場合に、リクエスト受信部２にリクエストを送信する。なお、リクエスト受信部２がリクエストを受信可能な状態とは、例えば、リクエストバッファ３に空きがある状態である。 The request transmission unit 1 transmits a request to the request reception unit 2 when reading and writing data. The requests here include a read request for requesting data reading and a write request for requesting data writing. The request transmission unit 1 transmits a request to the request reception unit 2 when the request reception unit 2 can receive the request. The state in which the request receiving unit 2 can receive a request is, for example, a state in which the request buffer 3 has an empty space.

リクエスト受信部２は、リクエスト送信部１からリクエストを受信する。リクエスト受信部２は、リクエスト送信部１から受信したリクエストをリクエストバッファ３に格納し、格納したリクエストのアドレス（ライトアドレス）をリクエスト生成部４に供給する。 The request reception unit 2 receives a request from the request transmission unit 1. The request reception unit 2 stores the request received from the request transmission unit 1 in the request buffer 3, and supplies the address (write address) of the stored request to the request generation unit 4.

リクエストバッファ３は、リクエスト受信部２から供給されたリクエストを記憶するバッファメモリである。また、リクエストバッファ３は、リクエスト生成部４から読み出し指示があった場合にデータを出力する。また、リクエストバッファ３は、リクエスト受信部２とリクエスト生成部４とで動作周波数が異なるため、いわゆる周波数の乗り換えを実行する。 The request buffer 3 is a buffer memory that stores the request supplied from the request receiving unit 2. Further, the request buffer 3 outputs data when there is a read instruction from the request generation unit 4. The request buffer 3 performs so-called frequency switching because the operation frequency is different between the request receiving unit 2 and the request generating unit 4.

リクエスト生成部４は、リクエスト受信部２により格納されたリクエストをリクエストバッファ３から読み出す。リクエスト生成部４は、リクエストを読み出したら、読み出したリクエストのアドレス（リードアドレス）をリクエスト受信部２に供給する。 The request generation unit 4 reads the request stored by the request reception unit 2 from the request buffer 3. When the request generation unit 4 reads the request, the request generation unit 4 supplies the address (read address) of the read request to the request reception unit 2.

また、リクエスト生成部４は、リクエスト受信部２からライトアドレスを受け取り、リードアドレスと比較する。リクエスト生成部４は、ライトアドレスとリードアドレスに差分があり、リクエストを受け取ることができる場合に、リクエストバッファ３に対して読み出し指示を行い、リクエストを受け取る。 The request generator 4 receives the write address from the request receiver 2 and compares it with the read address. When there is a difference between the write address and the read address and the request can be received, the request generation unit 4 issues a read instruction to the request buffer 3 and receives the request.

リクエスト生成部４は、リクエストがリードリクエストであった場合には、所定のデータサイズに応じたＩＤを付与したリクエストを外部装置に対して発行する。また、リクエスト生成部４は、ＩＤ、データサイズ、データ位置及びスタートフラグをリプライ管理部７に供給する。 When the request is a read request, the request generation unit 4 issues a request with an ID according to a predetermined data size to the external device. Further, the request generation unit 4 supplies the ID, data size, data position, and start flag to the reply management unit 7.

一例として、本実施形態においては、リードリクエストにより要求可能なデータのサイズが８／１６／３２ビットのいずれかであるとする。この場合において、リクエスト生成部４は、リプライ送信部８が送信するデータバス幅（すなわち第２の動作周波数側のデータバス幅）が３２ビット幅であり、リプライ受信部５が受信するデータバス幅（すなわち第１の動作周波数側のデータバス幅）が８ビット幅であるときには、８ビット単位でＩＤを付加してリクエストを生成する。この場合、データ位置は、この８ビット単位のデータが３２ビットのどの位置に相当するか（すなわち並び替え後の位置）を例えば２ビットの値（００、０１、１０、１１）で表す。また、スタートフラグは、要求されたデータのうちの最初の８ビットを識別するためのフラグであり、該当するデータについてのみ「１」となり、その他のデータについて「０」となる。リクエスト生成部４は、例えば、要求されたデータが１６ビットである場合には、８ビットずつに分割した２個のリードリクエストを発行する。 As an example, in the present embodiment, it is assumed that the size of data that can be requested by a read request is 8/16/32 bits. In this case, the request generation unit 4 has a data bus width transmitted by the reply transmission unit 8 (that is, a data bus width on the second operating frequency side) of 32 bits and a data bus width received by the reply reception unit 5. When (that is, the data bus width on the first operating frequency side) is 8 bits wide, an ID is added in units of 8 bits to generate a request. In this case, the data position represents, for example, a 2-bit value (00, 01, 10, 11) that corresponds to the 32-bit position of the 8-bit data (that is, the rearranged position). The start flag is a flag for identifying the first 8 bits of the requested data, and is “1” only for the corresponding data, and “0” for the other data. For example, when the requested data is 16 bits, the request generation unit 4 issues two read requests divided into 8 bits.

リプライ受信部５は、リクエストに応じて外部装置から送信されたリプライデータのＩＤを参照し、リプライバッファ６の当該ＩＤに対応する格納場所にリプライデータを書き込む。また、リプライ受信部５は、このＩＤをリプライ管理部７に送る。 The reply receiving unit 5 refers to the ID of reply data transmitted from the external device in response to the request, and writes the reply data in the storage location corresponding to the ID of the reply buffer 6. The reply receiving unit 5 sends this ID to the reply managing unit 7.

リプライバッファ６は、リプライデータを記憶するバッファメモリである。リプライバッファ６においては、第１の動作周波数側のデータバス幅でデータ及びＩＤが管理されている。図１の例では、第２の動作周波数側のデータバス幅が３２ビット、第１の動作周波数側のデータバス幅が８ビットである。そのため、リプライバッファ６は、３２ビットのデータが同時に読み出せるように、ＩＤによって８ビット単位で管理された格納場所を４組ずつ用意している。図１に示すように、リプライバッファ６は、データの格納場所がＩＤ（＃０、＃１、…、＃ｎ）によって決められている。リプライバッファ６は、リプライ受信部５から送られるＩＤに基づいてデータを書き込む。例えば、データサイズがそれぞれ８ビット、１６ビットの２個のリードリクエストが供給された場合、最初の８ビットのリードリクエストに応じたデータが＃０、次の１６ビットのリードリクエストに応じたデータが＃１、＃２に、それぞれ格納される。また、リプライバッファ６は、リプライ管理部７から読み出し指示が供給された場合には、該当するデータを読み出してリプライ送信部８に供給する。 The reply buffer 6 is a buffer memory that stores reply data. In the reply buffer 6, data and ID are managed by the data bus width on the first operating frequency side. In the example of FIG. 1, the data bus width on the second operating frequency side is 32 bits, and the data bus width on the first operating frequency side is 8 bits. For this reason, the reply buffer 6 has four sets of storage locations managed in units of 8 bits by ID so that 32-bit data can be read simultaneously. As shown in FIG. 1, in the reply buffer 6, data storage locations are determined by IDs (# 0, # 1,..., #N). The reply buffer 6 writes data based on the ID sent from the reply receiver 5. For example, when two read requests having a data size of 8 bits and 16 bits are supplied, the data corresponding to the first 8-bit read request is # 0, and the data corresponding to the next 16-bit read request is Stored in # 1 and # 2, respectively. Further, when a read instruction is supplied from the reply management unit 7, the reply buffer 6 reads out the corresponding data and supplies it to the reply transmission unit 8.

リプライ管理部７は、リプライデータをＩＤに基づいて管理する。具体的には、リプライ管理部７は、リプライデータを８ビットに分割した単位によって管理する。以下においては、必要に応じて、このように分割されたリプライデータのそれぞれのことを「分割データ」ともいう。 The reply management unit 7 manages reply data based on the ID. Specifically, the reply management unit 7 manages the reply data in units of 8 bits. Below, each of the reply data divided | segmented in this way is also called "divided data" as needed.

図２は、リプライ管理部７の構成をより詳細に示すブロック図である。リプライ管理部７は、レジスタ設定部７１と、レジスタ７２と、ＩＤ比較部７３とを備える。 FIG. 2 is a block diagram showing the configuration of the reply management unit 7 in more detail. The reply management unit 7 includes a register setting unit 71, a register 72, and an ID comparison unit 73.

レジスタ設定部７１は、レジスタ７２にデータを設定する。レジスタ設定部７１は、より詳細には、リクエスト生成部４から送られるＩＤに対応したエントリに、データサイズ、データ位置及びスタートフラグを格納する。また、レジスタ設定部７１は、これらのデータを格納したら、有効フラグをオフからオン（０から１）にする。レジスタ７２は、有効フラグ、データサイズ、データ位置、スタートフラグ及び受信完了フラグをＩＤと関連付けて記憶する。 The register setting unit 71 sets data in the register 72. More specifically, the register setting unit 71 stores the data size, the data position, and the start flag in the entry corresponding to the ID sent from the request generation unit 4. Further, after storing these data, the register setting unit 71 turns the valid flag from off to on (from 0 to 1). The register 72 stores a valid flag, a data size, a data position, a start flag, and a reception completion flag in association with the ID.

ＩＤ比較部７３は、リプライ受信部５からＩＤを受け取ったら、レジスタ７２の当該ＩＤに対応する有効フラグを参照し、有効フラグがオン（１）であれば受信完了フラグをオンにする。同時に、ＩＤ比較部７３は、データサイズ、スタートフラグおよび受信完了フラグを参照し、要求されたデータが全て格納されているか判断する。この判断は、スタートフラグがオンであるエントリのデータサイズを参照し、参照したデータサイズ分のデータの受信が完了しているか否かを受信完了フラグによって判断することで可能である。 When receiving the ID from the reply receiving unit 5, the ID comparing unit 73 refers to the valid flag corresponding to the ID in the register 72, and turns on the reception completion flag if the valid flag is on (1). At the same time, the ID comparison unit 73 refers to the data size, start flag, and reception completion flag to determine whether all requested data is stored. This determination can be made by referring to the data size of the entry whose start flag is on, and determining whether or not the reception of data for the referenced data size has been completed based on the reception completion flag.

ＩＤ比較部７３は、要求された分割データが全て格納されていた場合には、リプライバッファ６に対して読み出し指示を実行する。このとき、ＩＤ比較部７３は、リプライ送信部８に対してＩＤとデータ位置を通知するとともに、読み出し指示によって解放されるエントリ数（すなわちＩＤ数）をリクエスト生成部４に対して通知する。レジスタ設定部７１は、分割データの読み出し後、読み出したデータ位置に対応する有効フラグをオフにする。 The ID comparison unit 73 issues a read instruction to the reply buffer 6 when all of the requested divided data has been stored. At this time, the ID comparison unit 73 notifies the reply transmission unit 8 of the ID and the data position, and notifies the request generation unit 4 of the number of entries released by the read instruction (that is, the number of IDs). After reading the divided data, the register setting unit 71 turns off the valid flag corresponding to the read data position.

リプライ管理部７は、リプライバッファ６の解放に際し、ＩＤ順（ここでは昇順）にのみ分割データが解放されるように制限する。これにより、分割データが順不同（out of order）でデータ処理装置１０に入力された場合であっても、リクエスト順（in order）に並んだリプライデータを生成することが可能となる。 When releasing the reply buffer 6, the reply management unit 7 restricts the divided data to be released only in the ID order (in ascending order here). Accordingly, even when the divided data is input to the data processing apparatus 10 out of order, it is possible to generate reply data arranged in the request order (in order).

リプライ送信部８は、リプライ管理部７から受け取ったＩＤ及びデータ位置を用いて、リプライバッファ６から供給される分割データを並び替えて３２ビットのリプライデータを生成する。リプライ送信部８は、生成したリプライデータをリプライ受信部９に送信する。リプライ受信部９は、リプライ送信部８からリプライデータを受信して出力する。 The reply transmission unit 8 rearranges the divided data supplied from the reply buffer 6 using the ID and data position received from the reply management unit 7 and generates 32-bit reply data. The reply transmission unit 8 transmits the generated reply data to the reply reception unit 9. The reply receiver 9 receives reply data from the reply transmitter 8 and outputs it.

図３は、データサイズとデータ位置の対応関係を示す図である。リプライ送信部８は、リプライ管理部７から受け取ったＩＤに基づいてリプライバッファ６における分割データの格納場所を判断するとともに、リプライ管理部７から受け取ったデータ位置に基づいて３２ビット中のどの位置に当該分割データを配置するか判断する。なお、分割データが要求されていない格納場所（図中のハッチングで示されていない部分）に関しては、データの値は不定とする。ここにおいて、不定とは、値を問わないことをいい、例えば、以前のデータのままであっても一定値（０）であってもよい。 FIG. 3 is a diagram showing the correspondence between the data size and the data position. The reply transmission unit 8 determines the storage location of the divided data in the reply buffer 6 based on the ID received from the reply management unit 7, and at any position in 32 bits based on the data position received from the reply management unit 7. It is determined whether to arrange the divided data. It should be noted that the data value is undefined for the storage location where the divided data is not requested (the portion not indicated by hatching in the figure). Here, “indefinite” means that the value does not matter. For example, the previous data may remain as it is or may be a constant value (0).

図４は、リプライ送信部８によるリプライデータの生成手順を例示する図である。ここでは、リプライ管理部７からＩＤ及びデータ位置が“＃３，１０”、“＃４，１１”である８ビットのデータがそれぞれ要求された場合を示している。このとき、リプライ送信部８は、先頭の１６ビットを不定とし、ここにＩＤがそれぞれ「＃３」、「＃４」である８ビットの分割データを付加して３２ビットのリプライデータを生成する。 FIG. 4 is a diagram illustrating a procedure for generating reply data by the reply transmission unit 8. Here, a case is shown where 8-bit data whose ID and data position are “# 3, 10” and “# 4, 11” is requested from the reply management unit 7. At this time, the reply transmission unit 8 makes the first 16 bits undefined and adds 32-bit reply data with IDs “# 3” and “# 4” to generate 32-bit reply data. .

図５は、データ処理装置１０の動作を示すフローチャートである。データ処理装置１０は、リードリクエスト又はライトリクエストに応じて以下に示すように動作する。 FIG. 5 is a flowchart showing the operation of the data processing apparatus 10. The data processing apparatus 10 operates as described below in response to a read request or a write request.

ステップＳ１において、リクエスト受信部２は、リクエスト送信部１からリクエストを受信し、受信したリクエストをリクエストバッファ３に格納する。リクエストの格納後、リクエスト受信部２は、ライトアドレスをインクリメント（＋１）する。 In step S 1, the request reception unit 2 receives a request from the request transmission unit 1 and stores the received request in the request buffer 3. After storing the request, the request receiving unit 2 increments (+1) the write address.

ステップＳ２において、リクエスト生成部４は、リクエストバッファ３にリクエストが格納されているか否かを判断する。リクエスト生成部４は、自らがカウントしているリードアドレスとリクエスト受信部２によりカウントされたライトアドレスとを比較し、読み出すべきリクエストが格納されているか否かを両者の異同に基づいて判断する。 In step S 2, the request generator 4 determines whether a request is stored in the request buffer 3. The request generation unit 4 compares the read address counted by itself with the write address counted by the request reception unit 2, and determines whether or not a request to be read is stored based on the difference between the two.

ライトアドレスがリードアドレスより大きい場合、リクエストバッファ３には、リクエスト生成部４がまだ読み出していないリクエストが存在する。この場合（ステップＳ２：ＹＥＳ）、リクエスト生成部４は、読み出していないリクエストをリクエストバッファ３から読み出す（ステップＳ３）。リクエストを読み出した後、リクエスト生成部４は、リードアドレスをインクリメントする。 When the write address is larger than the read address, there is a request in the request buffer 3 that has not yet been read by the request generator 4. In this case (step S2: YES), the request generator 4 reads a request that has not been read from the request buffer 3 (step S3). After reading the request, the request generator 4 increments the read address.

一方、リードアドレスとライトアドレスが等しい場合、リクエストバッファ３には、新たに読み出すべきリクエストが格納されていない。この場合（ステップＳ２：ＮＯ）、リクエスト生成部４は、新たなリクエストが格納されるまで待機する。 On the other hand, when the read address and the write address are equal, the request buffer 3 does not store a request to be newly read. In this case (step S2: NO), the request generator 4 waits until a new request is stored.

ステップＳ４において、リクエスト生成部４は、読み出したリクエストがリードリクエスト又はライトリクエストのいずれであるかを判断する。ライトアドレスを読み出した場合（ステップＳ４：ＹＥＳ）、リクエスト生成部４は、外部装置に対してライトリクエストを発行する（ステップＳ５）。 In step S4, the request generation unit 4 determines whether the read request is a read request or a write request. When the write address is read (step S4: YES), the request generation unit 4 issues a write request to the external device (step S5).

一方、リードリクエストを読み出した場合（ステップＳ４：ＮＯ）、リクエスト生成部４は、データサイズを判定する（ステップＳ６）。続いて、リクエスト生成部４は、ステップＳ７において、データサイズに応じたＩＤを生成し、生成したＩＤ、データサイズ、データ位置及びスタートフラグといった情報をリプライ管理部７に渡す。リプライ管理部７は、リクエスト生成部４から渡された情報を内部に保持する。 On the other hand, when the read request is read (step S4: NO), the request generation unit 4 determines the data size (step S6). Subsequently, in step S 7, the request generation unit 4 generates an ID corresponding to the data size, and passes information such as the generated ID, data size, data position, and start flag to the reply management unit 7. The reply management unit 7 holds the information passed from the request generation unit 4 inside.

ステップＳ８において、リクエスト生成部４は、生成したＩＤを用いてリードリクエストを外部装置に発行する。続いて、リクエスト生成部４は、ステップＳ９において、リクエストによって要求されたデータ分のリードリクエストを外部装置に対して発行したか否かを判断する（ステップＳ９）。ここで、必要なリードリクエストが発行されていない場合（ステップＳ９：ＮＯ）、リクエスト生成部４は、ステップＳ８の処理を繰り返す。 In step S8, the request generation unit 4 issues a read request to the external device using the generated ID. Subsequently, in step S9, the request generator 4 determines whether or not a read request for the data requested by the request has been issued to the external device (step S9). If the necessary read request has not been issued (step S9: NO), the request generator 4 repeats the process of step S8.

一方、必要なリードリクエストが発行されていれば（ステップＳ９：ＹＥＳ）、リプライ受信部５は、リードリクエストに応じたリプライデータ（分割データ）の受信（すなわち返却）を待機し、受信したリプライデータをリプライバッファ６に格納する（ステップＳ１０）。このとき、リプライ受信部５は、リプライデータに付与されたＩＤに応じた格納場所にリプライデータを格納する。また、リプライ受信部５は、格納したリプライデータのＩＤをリプライ管理部７に通知する。 On the other hand, if a necessary read request has been issued (step S9: YES), the reply receiving unit 5 waits for reception (that is, return) of reply data (divided data) according to the read request, and receives the received reply data. Is stored in the reply buffer 6 (step S10). At this time, the reply receiving unit 5 stores the reply data in a storage location corresponding to the ID assigned to the reply data. The reply receiving unit 5 notifies the reply management unit 7 of the ID of the stored reply data.

ステップＳ１１において、リプライ管理部７は、リードリクエストによって要求された分のリプライデータが格納されたか否かをＩＤに基づいて判断する。リプライ管理部７は、リードリクエストによって要求された分のリプライデータがまだ格納されていなければ（ステップＳ１１：ＮＯ）、リプライ受信部５による格納を待機する。 In step S 11, the reply management unit 7 determines based on the ID whether or not the reply data requested by the read request has been stored. If the reply data requested by the read request has not yet been stored (step S11: NO), the reply management unit 7 waits for the reply receiving unit 5 to store the reply data.

一方、リードリクエストによって要求された分のリプライデータが格納されていた場合（ステップＳ１１：ＹＥＳ）、リプライ管理部７は、当該リプライデータをリプライバッファ６から読み出す読み出し指示を実行する（ステップＳ１２）。 On the other hand, if the reply data requested by the read request is stored (step S11: YES), the reply management unit 7 executes a read instruction to read the reply data from the reply buffer 6 (step S12).

ステップＳ１３において、リプライ送信部８は、リプライバッファ６から読み出された分割データを受信してリプライデータを生成する。リプライ送信部８は、リプライ管理部７から供給されるＩＤ及びデータ位置を用いることでリプライデータを生成することができる。リプライ送信部８は、生成したリプライデータをリプライ受信部９に送信する。 In step S 13, the reply transmission unit 8 receives the divided data read from the reply buffer 6 and generates reply data. The reply transmission unit 8 can generate reply data by using the ID and the data position supplied from the reply management unit 7. The reply transmission unit 8 transmits the generated reply data to the reply reception unit 9.

以上のとおり、本実施形態によれば、リプライ管理部７が複数あるデータ幅のうちの小さい方（狭い方）に合わせてリプライデータを管理することにより、より多くのリプライデータを格納することが可能になる。例えば、本実施形態によれば、リードリクエストが８ビットのリクエストのみであるとした場合には、エントリ数の４倍のリードリクエストを処理することが可能である。したがって、本実施形態によれば、リプライバッファ６をより効率的に使用することが可能である。 As described above, according to the present embodiment, the reply management unit 7 can store more reply data by managing reply data in accordance with the smaller (narrower) of the plurality of data widths. It becomes possible. For example, according to this embodiment, when the read request is only an 8-bit request, it is possible to process a read request four times the number of entries. Therefore, according to the present embodiment, the reply buffer 6 can be used more efficiently.

また、本実施形態によれば、リプライ管理部７による管理によって、さまざまなサイズのリードリクエストに対して効率的にリプライバッファ６を使用することが可能である。これにより、小さいサイズのリードリクエストをより多く発行することが可能になる。 Further, according to the present embodiment, the reply buffer 6 can be efficiently used for read requests of various sizes by the management by the reply management unit 7. This makes it possible to issue more small size read requests.

さらに、本実施形態によれば、分割データが順不同で返却された場合であっても、ＩＤに基づいて適切な順序で分割データを並び替えてリプライデータを生成することが可能である。したがって、ＩＤによるリプライデータの管理を行わない場合に比べ、データを並び替えるための内部論理回路等を別途設ける必要がなく、構成及び制御を簡略化することが可能である。
［変形例］
本発明は、上述した実施形態に限らず、以下の変形例に示す形態でも実施可能である。また、本発明は、複数の変形例を組み合わせてもよい。 Furthermore, according to the present embodiment, even when the divided data is returned in random order, the reply data can be generated by rearranging the divided data in an appropriate order based on the ID. Therefore, it is not necessary to separately provide an internal logic circuit or the like for rearranging data, compared to a case where reply data management by ID is not performed, and the configuration and control can be simplified.
[Modification]
The present invention is not limited to the above-described embodiment, and can also be implemented in the forms shown in the following modifications. Moreover, you may combine a some modification in this invention.

（１）変形例１
図６は、リプライ管理部７ａの構成を示すブロック図である。リプライ管理部７ａは、上述したデータ処理装置１０に適用可能なリプライ管理部７（図２参照）の変形例である。つまり、データ処理装置１０は、リプライ管理部７をリプライ管理部７ａに置換可能である。リプライ管理部７ａは、リプライ管理部７と比較すると、レジスタ７２に代えてレジスタ７２ａを備える点において相違し、その他の点において共通の構成を有する。また、レジスタ７２ａは、関連ＩＤ情報を含む点においてレジスタ７２と異なる。 (1) Modification 1
FIG. 6 is a block diagram showing the configuration of the reply management unit 7a. The reply management unit 7a is a modification of the reply management unit 7 (see FIG. 2) applicable to the data processing apparatus 10 described above. That is, the data processing apparatus 10 can replace the reply management unit 7 with the reply management unit 7a. The reply management unit 7a is different from the reply management unit 7 in that a register 72a is provided instead of the register 72, and has a common configuration in other points. The register 72a is different from the register 72 in that it includes related ID information.

関連ＩＤ情報は、同一のリクエストに割り当てられるＩＤを示す情報である。ここにおいて、同一のリクエストとは、分割前に単一であったリクエスト同士をいう。例えば、１６ビット分のデータを要求するリクエストが２個のリクエストに分割された場合、リクエスト生成部４は、これらのリクエストに割り当てるＩＤを事前に決定しておく。この場合、２個のリクエストのうちの先行する一方のリクエストに対応するエントリには、後続する他方のリクエストに割り当てられたＩＤが関連ＩＤ情報として格納される。同様に、他方のリクエストに対応するエントリにも、一方のリクエストに割り当てられたＩＤが関連ＩＤ情報として格納される。また、３２ビット分のデータが要求される場合であれば、関連ＩＤ情報には３個のＩＤが格納される。 The related ID information is information indicating an ID assigned to the same request. Here, the same request is a single request before the division. For example, when a request for requesting 16-bit data is divided into two requests, the request generation unit 4 determines in advance IDs to be assigned to these requests. In this case, the ID assigned to the subsequent request is stored as related ID information in the entry corresponding to the preceding request of the two requests. Similarly, an ID assigned to one request is also stored as related ID information in the entry corresponding to the other request. If 32-bit data is requested, three IDs are stored in the related ID information.

なお、有効な関連ＩＤ情報の数は、データサイズから判断することが可能である。リプライ管理部７ａは、リプライ受信部５から分割データのＩＤを受け取ると、当該ＩＤに対応するデータサイズに基づいて有効な関連ＩＤ情報の数を判断するとともに、関連ＩＤ情報に示されたＩＤに対応する受信完了フラグが全てオンであるか否かを判断する。リプライ管理部７ａは、これらの受信完了フラグが全てオンであれば、リプライデータの生成に必要な分割データが揃っていると判断し、読み出し指示を実行する。また、リプライ管理部７ａは、読み出した分割データに対応する有効フラグをオフにし、解放したＩＤをリクエスト生成部４に通知する。なお、この場合において、リクエスト生成部４は、ＩＤを順番に使用するのではなく、空いているＩＤから順次使用する。 The number of valid related ID information can be determined from the data size. When the reply management unit 7a receives the ID of the divided data from the reply receiving unit 5, the reply management unit 7a determines the number of valid related ID information based on the data size corresponding to the ID, and sets the ID indicated in the related ID information. It is determined whether or not all corresponding reception completion flags are on. If these reception completion flags are all on, the reply management unit 7a determines that the divided data necessary for generating reply data is available, and executes a read instruction. Further, the reply management unit 7a turns off the validity flag corresponding to the read divided data and notifies the request generation unit 4 of the released ID. In this case, the request generation unit 4 does not use the IDs in order, but sequentially uses the available IDs.

本例においては、リプライデータが順不同で返却されるものの、ＩＤ順という制限を受けないため、リクエスト時に要求されたリプライデータが揃った時点でこれを返却することが可能になる。これにより、同一のリクエストでＩＤを連続して（連番で）確保する必要がなくなるため、リプライバッファ６をより効率的に使用することが可能になる。 In this example, although reply data is returned in random order, it is not subject to the restriction of ID order, so that it can be returned when reply data requested at the time of request is prepared. As a result, it becomes unnecessary to secure IDs consecutively (by serial numbers) with the same request, and the reply buffer 6 can be used more efficiently.

（２）変形例２
図７は、本発明の別の実施形態に係るデータ処理装置２０のハードウェア構成を示すブロック図である。データ処理装置２０は、第１の処理部１１と、バッファメモリ１２と、第２の処理部１３と、管理部１４とを備える。データ処理装置２０は、第２の処理部１３からのリクエストに応じて外部装置から送信されるデータを第１の処理部１１において受信し、バッファメモリを介して第２の処理部１３に供給（返却）する。 (2) Modification 2
FIG. 7 is a block diagram showing a hardware configuration of a data processing device 20 according to another embodiment of the present invention. The data processing device 20 includes a first processing unit 11, a buffer memory 12, a second processing unit 13, and a management unit 14. The data processing device 20 receives data transmitted from an external device in response to a request from the second processing unit 13 at the first processing unit 11 and supplies the data to the second processing unit 13 via the buffer memory ( return.

第１の処理部１１は、バッファメモリ１２にデータを書き込む。第２の処理部１３は、バッファメモリ１２からデータを読み出す。第１の処理部１１と第２の処理部１３は、例えば、上述した実施形態のリプライ受信部６とリプライ送信部８にそれぞれ相当する。 The first processing unit 11 writes data in the buffer memory 12. The second processing unit 13 reads data from the buffer memory 12. The first processing unit 11 and the second processing unit 13 correspond to, for example, the reply receiving unit 6 and the reply transmitting unit 8 of the above-described embodiment, respectively.

ここにおいて、第１の処理部１１と第２の処理部１３は、互いに動作周波数及びデータバス幅が異なる。具体的には、第１の処理部１１の動作周波数をｆ_１（第１の動作周波数）、第２の処理部１３の動作周波数をｆ_２（第２の動作周波数）としたとき、これらはｆ_１＞ｆ_２を満たす関係にある。ただし、ｆ_１、ｆ_２の具体的な値は、特に限定されない。 Here, the first processing unit 11 and the second processing unit 13 have different operating frequencies and data bus widths. Specifically, when the operating frequency of the first processing unit 11 is f ₁ (first operating frequency) and the operating frequency of the second processing unit 13 is f ₂ (second operating frequency), these are: There is a relationship satisfying f ₁ > f ₂ . However, specific values of f ₁ and f ₂ are not particularly limited.

また、第１の処理部１１及び第２の処理部１３のデータバス幅は、典型的には、８、１６、３２、６４ビットのいずれかである。なお、第２の処理部１３のデータバス幅は、第１の処理部１１のデータバス幅よりも大きい（太い）ものとする。以下においては、第１の処理部１１のデータバス幅をｍとし、第２の処理部１３のデータバス幅をｎとする。ここにおいて、ｍは１以上の整数であり、ｎはｎ＞ｍを満たすｍの倍数である。 The data bus width of the first processing unit 11 and the second processing unit 13 is typically any of 8, 16, 32, and 64 bits. It is assumed that the data bus width of the second processing unit 13 is larger (thicker) than the data bus width of the first processing unit 11. In the following, the data bus width of the first processing unit 11 is m, and the data bus width of the second processing unit 13 is n. Here, m is an integer of 1 or more, and n is a multiple of m that satisfies n> m.

バッファメモリ１２は、第１の処理部１１により書き込まれたデータを記憶する。バッファメモリ１２に記憶されたデータは、管理部１４による読み出し指示に応じて読み出される。バッファメモリ１２は、例えば、上述した実施形態のリプライバッファ６に相当する。 The buffer memory 12 stores the data written by the first processing unit 11. Data stored in the buffer memory 12 is read in response to a read instruction from the management unit 14. The buffer memory 12 corresponds to, for example, the reply buffer 6 of the above-described embodiment.

管理部１４は、バッファメモリ１２に記憶されるデータを管理する。管理部１４は、バッファメモリ１２に記憶されるデータに対してｍビット単位で付与される識別子に基づいて当該データを管理する。ここでいう識別子は、上述したＩＤに相当する。第２の処理部１３は、この識別子に基づいて、バッファメモリ１２から読み出したｍビット単位のデータを並べ替えてｎビットのデータを生成する。管理部１４は、例えば、上述した実施形態のリプライ管理部７に相当する。具体的には、リプライ管理部７においては、ｎ＝３２、ｍ＝８である。 The management unit 14 manages data stored in the buffer memory 12. The management unit 14 manages the data based on an identifier given to the data stored in the buffer memory 12 in units of m bits. The identifier here corresponds to the ID described above. Based on this identifier, the second processing unit 13 rearranges the m-bit unit data read from the buffer memory 12 to generate n-bit data. The management unit 14 corresponds to, for example, the reply management unit 7 in the above-described embodiment. Specifically, in the reply management unit 7, n = 32 and m = 8.

本例においても、上述した実施形態と同様に、複数あるデータ幅のうちの小さい方（狭い方）に合わせてデータを管理することが可能であるため、バッファメモリ１２により多くのデータを効率的に格納することが可能である。 Also in this example, as in the above-described embodiment, data can be managed in accordance with the smaller (narrower) of a plurality of data widths, so that more data can be efficiently stored in the buffer memory 12. Can be stored.

（３）変形例３
上述した実施形態におけるデータサイズやデータバス幅などの数値は、あくまでも一例である。本発明は、これらの数値について、その実施を妨げない範囲でさまざまな値を用いることが可能である。
(3) Modification 3
The numerical values such as the data size and the data bus width in the above-described embodiment are merely examples. In the present invention, various values can be used for these numerical values as long as the implementation is not hindered.

１リクエスト送信部
２リクエスト受信部
３リクエストバッファ
４リクエスト生成部
５リプライ受信部
６リプライバッファ
７、７ａリプライ管理部
７１レジスタ設定部
７２レジスタ
７３ＩＤ比較部
８リプライ送信部
９リプライ受信部
１０、２０データ処理装置
１１第１の処理部
１２バッファメモリ
１３第２の処理部
１４管理部 DESCRIPTION OF SYMBOLS 1 Request transmission part 2 Request reception part 3 Request buffer 4 Request generation part 5 Reply reception part 6 Reply buffer 7, 7a Reply management part 71 Register setting part 72 Register 73 ID comparison part 8 Reply transmission part 9 Reply reception part 10, 20 Data Processing device 11 First processing unit 12 Buffer memory 13 Second processing unit 14 Management unit

Claims

Buffer memory,
First processing means operating at a first operating frequency and having a data bus width of m bits and writing data to the buffer memory;
It operates at a second operating frequency lower than the first operating frequency, has a data bus width of n bits (where n is a multiple of m satisfying n> m), and reads data from the buffer memory. Two processing means;
Management means for managing data stored in the buffer memory,
The buffer memory stores data received by the first processing means in response to a request from the second processing means,
The management means manages the data based on an identifier given to the data stored in the buffer memory in units of m bits,
The data processing device, wherein the second processing means rearranges data read from the buffer memory based on the identifier to generate n-bit data.

The data processing apparatus according to claim 1, wherein the request includes a request for requesting data having a multiple of m and a size smaller than n.

The data processing device according to claim 1, wherein the management unit stores a rearranged position of data stored in the buffer memory in association with the identifier.

The data processing device according to any one of claims 1 to 3, wherein the management unit stores a data size of the request corresponding to data stored in the buffer memory in association with the identifier.

5. The data processing apparatus according to claim 1, wherein the management unit restricts reading by the second processing unit so that data in the buffer memory is read in an order determined by the identifier. 6. .

The management unit assigns one of the first data and the second data when the first data and the second data stored in the buffer memory correspond to the same request. The data processing device according to any one of claims 1 to 4, wherein the stored identifier is stored in association with the other identifier.

The first processing means operating at the first operating frequency and having a data bus width of m bits operates at a second operating frequency lower than the first operating frequency and is n bits (where n is n Data received in response to a request from the second processing means having a data bus width of (a multiple of m satisfying> m),
Managing the data based on an identifier assigned to the data stored in the buffer memory in units of m bits;
A data processing method for reading data from the buffer memory by the second processing means and rearranging the read data based on the identifier to generate n-bit data.