JP4934000B2 - Arbitration device, arbitration method, and program - Google Patents

Description

  The present invention relates to an arbitration device (arbiter), an arbitration method, and a program for arbitrating transfer requests from a plurality of DMACs (direct memory access controllers) having different priorities, and more specifically, from an DMAC having a higher priority. The present invention relates to an arbitration device, an arbitration method, and a program that improve performance of the entire system by appropriately limiting transfer requests.

  2. Description of the Related Art Conventionally, in a system including a CPU and a plurality of modules, DMA transfer that performs data transfer without CPU intervention is known as a method for performing high-speed data transfer between the modules and the memory on the CPU bus. It has been. When each module performs DMA transfer, the DMAC issues a transfer request (request) to the arbiter and receives transfer permission from the arbiter, and then performs transfer (read or write) to the memory. At this time, if a plurality of DMAC transfer requests compete, the arbiter determines the transfer order based on a preset priority (see Patent Document 1).

  Such a system for performing DMA transfer between a plurality of modules and a memory on the CPU bus is not described in the literature, but there is a multifunction printer (hereinafter referred to as MFP) shown in FIG.

  The MFP includes an ASIC (Application Specific Integrated Circuit) 1, a CPU 2, a memory 3, and a scanner 4. The ASIC 1 and the CPU 2 are connected by a PCI Express I / F (interface) 5, and the CPU 2 and the memory 3 are connected by a DDR (Double Data Rate) 2 I / F 6.

  The first image processing module 11 has a function of performing correction processing such as shading correction and interline correction on the image data input from the scanner 4. Further, a first write DMAC (WDMAC1) 15 for performing control for writing the corrected image data into the memory 3 is provided.

  The second image processing module 12 has a function of performing image processing such as scaling processing and gradation processing on the image data read from the memory 3. A first read DMAC (RDMAC1) 16 for reading image data from the memory 3 and a second write DMAC (RDMAC2) 17 for writing image data subjected to image processing to the memory are provided.

  The arbiter 13 arbitrates transfer requests from the first and second write DMACs 15 and 17 and the first read DMAC 16. The DMAC that receives the transfer permission from the arbiter 13 accesses the memory 3 via the arbiter 13, the PCI Express ENDP (endpoint) 14, the PCI Express I / F 5, and the DDR2 I / F 6 (the CPU 2 does not intervene).

  According to this MFP, the image data input from the scanner 4 to the first image processing module 11 of the ASIC 1 is temporarily written in the memory 3 by the first write DMAC 15, and then read from the memory 3 by the first read DMAC 16. The image processing is performed by the second image processing module 12, and the difference between the scanner input and the image processing speed can be absorbed by writing again in the memory 3 by the second write DMAC 17. With this configuration, when the number of data to be processed increases with respect to the number of input data, for example, at the time of enlargement / reduction, the enlargement / reduction process is not in time for the input from the scanner 4 and the system breaks down. Can be prevented.

  FIG. 9 is an example of a timing chart showing data flowing between the arbiter 13 and the PCI Express ENDP 14 in relation to the operations of the first and second write DMACs 15 and 17 and the first read DMAC 16 shown in FIG. It is. Here, the priority order of the three DMACs is that the first write DMAC 15 is first, the first read DMAC 16 is second, and the second write DMAC 17 is third.

  The first write DMAC 15 is inputted to the first image processing module 11 from the scanner 4, and when 18 lines of image data (W 1 to W 18) processed for one line are transferred to the memory 3, individual images are transferred. A transfer request is sent to the arbiter 13 at the start timing of the data, and the image data is sent immediately. The arbiter 13 processes the transfer request from the first write DMAC 15 having the highest priority six times, and then processes the transfer request of the first read DMAC 16 having the second highest priority twice. (R1, R2). The image data C1 and C2 are read from the memory 3 by processing the transfer request of the first read DMAC 16. There is a delay (Read Delay) between the transfer request timing and the image data transfer timing. For this reason, the time when the first write DMAC 15 is writing the image data W9 and W10 and the time when the first read DMAC 16 is reading the image data C1 and C2 overlap, and this overlap period is the PCI Express I. Image data flows in both directions on / F5.

  The above processing is repeated, and after the first write DMAC 15 finishes transferring the image data for one line, the transfer request from the second write DMAC 17 having the third priority is permitted.

  However, in the case of the timing chart shown in FIG. 9, the first WDMAC 15 transfers image data (W1 to W18) for one line to the memory 3 in a shorter time than one line time (lsync period in the figure) of the scanner 4. On the other hand, the first read DMAC 16 transfers only about half, and the second write DMAC 17 transfers only 1/3. That is, the performance of the first WDMAC 15 is higher than necessary, but the performance of other DMACs is insufficient.

Therefore, it is conceivable to raise the priority of the first read DMAC 16. However, this has the following problems. Comparing the operations of the write DMAC and the read DMAC, the read DMAC has a large latency (delay) from when a transfer request is accepted until the response (image data) is returned. For this reason, even if the priority of the first read DMAC 16 is increased, the transfer request is issued from the first write DMAC 15 without any gap while the transfer request of the first read DMAC 16 is processed. The number of times the DMAC 15 transfer request is processed increases, resulting in an unnecessarily high performance. In addition, since the transfer request of the first read DMAC 16 is accepted after the processing of the transfer request of the first write DMAC 15 is completed, the required performance cannot be satisfied as a result.
JP 7-13923 A

  The present invention has been made to solve such a problem, and its object is to improve the performance of the entire system when arbitrating transfer requests from a plurality of DMACs having different priorities. .

According to a first invention of the present application, in an arbitration device that arbitrates transfer requests from a plurality of DMACs having different priorities, a predetermined amount of data input every predetermined time can be transferred within the predetermined time and Means for accepting transfer requests sequentially issued for each part of the predetermined amount of data within the predetermined time by the first DMAC set with the highest order; means for executing processing according to the transfer requests; And a means for calculating a cumulative value of the transfer amount due to these transfer requests, and dividing the cumulative value by a transfer rate set for the first DMAC, thereby obtaining a required transfer time of the data of the cumulative value. A means for calculating, a means for measuring an elapsed time for each predetermined time, a means for comparing the elapsed time with the required transfer time, and based on the comparison result, according to the transfer request. And having a means for determining whether to wait or to perform the management.
According to a second invention of the present application, in the first invention, when the elapsed time is within the required transfer time and there is a transfer request from a DMAC other than the first DMAC, The present invention is characterized in that a transfer request is waited and processing according to a transfer request from a DMAC other than the first DMAC is executed.
A third invention of the present application is characterized in that, in the first invention, each means is provided for a DMAC other than the first DMAC.
According to a fourth invention of the present application, in the first invention, the determining means generates a wait request signal for waiting for the process according to the transfer request, and then executes the process from the executing means that has completed the process according to the transfer request. When the completion signal is received, the wait request signal is negated.
According to a fifth aspect of the present invention, in the third aspect, when waiting for a plurality of DMAC transfer requests, when one standby process is completed, it is determined whether there is another DMAC waiting. In some cases, a transfer request from another DMAC is processed while monitoring the processing.
According to a sixth invention of the present application, in an arbitration method for arbitrating transfer requests from a plurality of DMACs having different priorities, a predetermined amount of data input every predetermined time can be transferred within the predetermined time and Receiving a transfer request sequentially issued for each part of the predetermined amount of data within the predetermined time by the first DMAC set with the highest order; and executing a process according to the transfer request; , Calculating a cumulative value of the transfer amount due to these transfer requests, and dividing the cumulative value by the transfer rate set for the first DMAC, thereby reducing the required transfer time of the cumulative value data A step of calculating, a step of measuring an elapsed time for each predetermined time, a step of comparing the elapsed time with the required transfer time, and based on the comparison result, Characterized by a step of determining whether to wait or to execute that process.

  According to the present invention, when mediating transfer requests from a plurality of DMACs having different priorities, the performance of the entire system can be improved by appropriately limiting the transfer requests from DMACs having a higher priority.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[First Embodiment]
FIG. 1 is a block diagram illustrating a configuration of an arbiter in the MFP according to the first embodiment of this invention. The overall configuration of the MFP according to the present embodiment is the same as that shown in FIG. 8, and the arbiter 113 is provided in the ASIC 1 in the MFP, like the arbiter 13 shown in FIG.

  The arbiter 113 includes a required transfer time calculation unit 121 and a request arbitration unit 122. The required transfer time calculation unit 121 receives the burst length of data from the first write DMAC 15 when a transfer request is issued. In addition, a line start signal and a line end signal are input. Further, necessary transfer rate information Ra is input from the necessary transfer rate holding unit 123. The burst length and the required transfer rate are values that need to be known in advance when the system is studied. The request arbitration unit 122 receives transfer requests from the first write DMAC 15, the second write DMAC 17, and the first read DMAC 16, and receives a wait request signal from the required transfer time calculation unit 121. Here, the priority order of the three DMACs is that the first write DMAC 15 is first, the first read DMAC 16 is second, and the second write DMAC 17 is third.

  The necessary transfer rate holding unit 123 is provided in the ASIC 1. The necessary transfer rate information Ra is set to about 80% of the lsync period, which is the time that the first read DMAC 15 must complete the data transfer. Alternatively, it is desirable to set a value in consideration of the maximum value of processing time for one transfer request. The reason is that the transfer is completed without exceeding the lsync period even when a wait process described later is performed on the last transfer request in one line from the first read DMAC 15.

  FIG. 2 is a block diagram showing an internal configuration of the necessary transfer time calculation unit 121 of FIG. The required transfer time calculation unit 121 includes a required transfer time T2 calculation unit and time comparison unit 1211, a timer 1212, and a wait request signal generation unit 1213.

  The timer 1212 receives a line start signal and a line end signal. Then, an elapsed time T1 from the line start signal is counted (measured) until it is activated by the line start signal and reset by the line end signal.

  The required transfer time T2 calculation unit and the time comparison unit 1211 receive the burst length BL and the elapsed time T1. The necessary transfer time T2 calculation unit and the time comparison unit 1211 hold information on the bus width DW between the first write DMAC 15 and the arbiter 113.

The necessary transfer time T2 calculation unit and time comparison unit 1211 operate as follows.
Based on the burst length BL received when the transfer request is issued and the held bus width DW, the transfer data amount BW (k) is first calculated by the following equation [1]. In this equation, k indicates the order of transfer requests within one line.
BW (k) = BL (k) × DW Equation [1]

Next, this transfer data amount BW (k) is accumulated for each transfer request within one line, and an accumulated transfer amount BW ′ (n) shown in the following equation [2] is calculated.
BW '(n) = BW (1) + BW (2) + ... BW (n) ... Formula [2]

Next, a necessary transfer time T2, which is a time during which the data transfer of the accumulated transfer amount BW ′ (n) must be completed, is calculated by the following equation [3].
T2 = BW '(n) / Ra (3)

  Next, the required transfer time T2 and the elapsed time T1 are compared, and the length relationship is output to the wait request signal generation unit 1213.

  If T1 is longer than T2, the wait request signal generation unit 1213 asserts a wait request signal in response to a transfer request from the first write DMAC 15 until T1 and T2 become equal to the request arbitration unit 122. Output. While the wait request signal is asserted, the request arbitration unit 122 executes wait processing (limits issuing of a transfer request) to the transfer request from the first write DMAC 15.

Next, the operation of the arbiter 113 will be described with reference to the flowchart shown in FIG.
When data transfer is started, the request arbitration unit 122 receives a request (transfer request) in step ST1 of FIG. Next, in step ST2, the request arbitration unit 122 determines whether or not there is a request from the first write DMAC 15 having the highest priority. If there is (ST2: Yes), the required transfer time is determined in step ST3. The calculation unit 121 calculates the necessary transfer time T2. Here, the request arbitration unit 122 can make the determination in step ST2 from the DMACID or the like transmitted from each DMAC when a transfer request is made.

  Next, in step ST4, the required transfer time calculation unit 121 determines whether or not the elapsed time T1 is longer than the required transfer time T2, and if it is longer (ST4: Yes), in step ST7, the request arbitration unit 122 Handles the request from the first write DMAC 15.

  On the other hand, if the elapsed time T1 is within the required transfer time T2 (ST4: No), it is determined in step ST5 whether there is a request from another DMAC (here, the first read DMAC16 and the second write DMAC17). To do. If there is any (ST5: Yes), after processing a request from another DMAC in step ST6, the process returns to step ST4. If not (ST5: No), the request from the first write DMAC 15 is processed in step ST7.

  The presence / absence of a request from the first write DMAC 15 is determined. If there is no request (ST2: No), normal arbitration and request processing are performed on the first read DMAC 16 or the second write DMAC 17 that issued the request. (Step ST8).

  The above processing is repeated until it is determined in step ST9 that all data has been transferred.

The processing of the flowchart of FIG. 3 described above is summarized as follows.
When a request is issued from the DMAC, the arbiter 113 determines which DMAC the request is from. If it is determined that the request is not from the first write DMAC 15, normal arbitration and request processing are performed. If the request is from the first write DMAC 15, the required transfer time T2 is calculated. If the time T1 is longer than T2 compared with the elapsed time T1 from the start of the current line, the request from the first write DMAC 15 is processed as it is. If T2 is longer, if there is a request from another DMAC during that time, it will be processed with priority. If not, the request from the first write DMAC 15 will be processed, and all data transfer has been completed. If not, wait for the next request.

Next, a description will be given based on the timing chart shown in FIG.
The first write DMAC 15 issues a transfer request to the arbiter 113 at the leading timing of each image data when transferring 18 blocks of image data (W1 to W18) for one line to the memory 3. At the time when the transfer request for each of the image data W1 to W4 is received, there is no transfer request from another DMAC. Therefore, the process from the first write DMAC 15 (transfer of the image data W1 to W4) is performed in step ST7 of FIG. ).

  At the time when the transfer request for the image data W5 is received, the first read DMAC 16 has also issued the transfer request R1. At this time, since T1 is shorter than T2, the process proceeds from step ST4: No → ST5: Yes → ST6, the transfer request of the first read DMAC 16 is processed, and the transfer request of the image data W5 from the first write DMAC 15 waits. Let Similarly, the transfer request R2 from the first read DMAC 16 is processed. As a result, the image data C1 and C2 are read from the memory 3.

  At the time when the next transfer request R3 is received, since the transfer request of the image data W5 from the first write DMAC 15 is kept waiting, T1 becomes T2 or more, so that the process proceeds to step ST4: Yes → ST7. The transfer request for the image data W5 from the write DMAC 15 is processed, and the transfer request R3 from the first read DMAC 16 is put on standby. Similarly, the transfer request of the image data W6 to W8 from the first write DMAC 15 is processed. When the transfer of the image data W8 is completed, the process proceeds to step ST2: No → ST8, and the transfer request R3 from the first read DMAC 16 is processed.

  Thereafter, when processing of the transfer request R4 from the first read DMAC 16 is completed, a transfer request for the image data W9 from the first write DMAC 15 is issued. Thereafter, the arbiter 113 transfers data from the first write DMAC 15 and the first read DMAC 16 according to the presence / absence of a transfer request from the first write DMAC 15 and the first read DMAC 16 and the length relationship between T1 and T2. When one of the requests is processed, a process for waiting the other is performed.

  When the first write DMAC 15 completes the transfer of the image data W1 to W18 for one line, the first write DMAC 15 does not issue a transfer request until the end of one sync time (line end signal timing). From the end of the 1 sync time, the transfer request processing of the second write DMAC 17 is started, and the transfer request from the first read DMAC 16 is subsequently processed.

  FIG. 5 shows a timing chart corresponding to FIG. 9 when the data shown in the timing chart of FIG. 4 is viewed between the arbiter 113 and the PCI Express ENDP 14.

  As shown in FIG. 5, in the present embodiment, after the transfer request from the first write DMAC 15 having the highest priority is processed four times in succession, the first read DMAC 16 having the second highest priority is processed. Process the transfer request twice in succession. For this reason, the timing at which the first write DMAC 15 completes the transfer of the image data W1 to W18 for one line is delayed from the case of FIG. However, in response to the transfer request from the first read DMAC 16 and the second write DMAC 17, the transfer of more data is completed in the present embodiment at the end of 1 sync time. I understand.

  In other words, the present embodiment prevents the performance of the first write DMAC 15 from becoming excessive by appropriately limiting the transfer request of the first write DMAC 15 having the highest priority, and the first read. The performance of the DMAC 16 and the second write DMAC 17 is improved, and as a result, the performance of the entire system is improved.

As described above, the arbiter 113 according to the first embodiment of the present invention has the following effects (1) and (2).
(1) By having the necessary transfer time calculation unit 121 and the necessary transfer rate holding unit 123, it is possible to grasp the data transfer status from the first write DMAC 15 having the highest priority and generate a wait request as appropriate. Is possible.
(2) The data transfer amount that must be strictly observed from the first write DMAC 15 having the highest priority level is transferred without fail, while requests from other DMACs can be processed, so that the data transfer amount as a whole And efficient data transfer becomes possible.

[Second Embodiment]
FIG. 6 is a block diagram showing the configuration of the arbiter in the MFP according to the second embodiment of the present invention. The overall configuration of the MFP according to this embodiment is the same as that shown in FIG. 9, and the arbiter 213 is provided in the ASIC 1 in the MFP, like the arbiter 13 shown in FIG.

  The arbiter 213 includes a first required transfer time calculation unit (required transfer time calculation unit 1) 2211, a second required transfer time calculation unit (required transfer time calculation unit 2) 2212, and a third required transfer time calculation unit (necessary A transfer time calculation unit 3) 2213 and a request arbitration unit 222 are provided.

  The first required transfer time calculation unit 2211 receives the first burst length of data (burst length 1) from the first write DMAC 15 when a transfer request is issued. In addition, a line start signal and a line end signal are input. Further, necessary transfer rate information Ra1 is input from the necessary transfer rate holding unit 123. Similarly, the second required transfer time calculation unit 2212 receives the second burst length of data (burst length 2), the line start signal, and the line end signal from the first read DMAC 16, and maintains the necessary transfer rate. The required transfer rate information Ra2 is input from the unit 123. The third required transfer time calculator 2213 receives the third burst length of data (burst length 3), the line start signal, and the line end signal from the second write DMAC 17, and maintains the required transfer rate. The required transfer rate information Ra3 is input from the unit 123.

  The request arbitration unit 222 receives transfer requests from the first write DMAC 15, the second write DMAC 17, and the first read DMAC 16. Further, the first required transfer time calculation unit 2211, the second required transfer time calculation unit 2212, and the third required transfer time calculation unit 2213 receive the first wait request signal (wait request signal 1) S 1, respectively. The second wait request signal (wait request signal 2) S2 and the third wait request signal (wait request signal 3) S3 are input. Furthermore, a first request processing completion signal (request processing completion signal 1) is sent to each of the first required transfer time calculation unit 2211, the second required transfer time calculation unit 2212, and the third required transfer time calculation unit 2213. S4, a second request processing completion signal (request processing completion signal 2) S5, and a third request processing completion signal (request processing completion signal 3) S6 are transmitted.

  Here, the first required transfer time calculation unit 2211, the second required transfer time calculation unit 2212, and the third required transfer time calculation unit 2213 are the same as the required transfer time calculation unit 121 in the first embodiment, respectively. The necessary transfer times T21, T22, and T23 are calculated using equations similar to the equations [1] to [3], respectively.

  That is, in the arbiter 113 of the first embodiment, the required transfer time calculation unit is provided only for the first write DMAC 15, but in this embodiment, the required transfer time calculation unit is provided for all DMACs. The necessary transfer time information Ra1, Ra2, and Ra3 are supplied to the necessary transfer time calculation unit for, and arbitration is performed so that each DMAC can keep the required transfer rate.

  Here, as in the first embodiment, the priority order of the three DMACs is that the first write DMAC 15 is first, the first read DMAC 16 is second, and the second write DMAC 17 is third. Then, a transfer rate is calculated for each DMAC, and if it exceeds the required transfer rate, a wait request signal can be asserted for each DMAC.

Next, the operation of the arbiter 213 will be described with reference to the flowchart shown in FIG.
First, in step ST11, the request arbitration unit 222 receives a request. Next, in step ST12, the request arbitration unit 122 determines whether or not there is a request from the first write DMAC 15 having the highest priority. If there is a request (ST12: Yes), in step ST13, the first request DMA The required transfer time calculation unit 2211 calculates the required transfer time T21.

  Next, in step ST14, the first required transfer time calculation unit 2211 determines whether or not the elapsed time T1 is longer than the required transfer time T21. If longer (ST14: Yes), the request is sent in step ST16. The arbitration unit 222 processes the request from the first write DMAC 15.

  On the other hand, if the elapsed time T1 is within the required transfer time T21 (ST14: No), it is determined in step ST15 whether there is a request from another DMAC. If not (ST15: No), the request from the first write DMAC 15 is processed in step ST16.

  On the other hand, if there is a request from another DMAC (ST15: Yes), the process proceeds to step ST19 to determine whether there is a request from the first read DMAC 16 having the second highest priority. Even when it is determined in the previous step ST12 that there is no request from the first write DMAC 15 (ST12: No), step ST19 is executed.

  If it is determined that there is a request from the first read DMAC 16, the second required transfer time calculator 2212 calculates the required transfer time T22 in step ST20. Next, in step ST21, the second required transfer time calculation unit 2211 determines whether or not the elapsed time T1 is longer than the required transfer time T22. If longer (ST21: Yes), the request is sent in step ST22. The arbitration unit 222 processes the request from the first read DMAC 16.

  On the other hand, if the elapsed time T1 is within the required transfer time T22 (ST21: No), it is determined in step ST23 whether the elapsed time T1 is longer than the required transfer time T21. If the result of determination is that it is long, the process proceeds to step ST16 to process the request from the first write DMAC 15. If it is not long, it is determined in step ST24 whether there is a request from another DMAC (other than the first write DMAC 15 and the first read DMAC 16). If there is no determination (ST24: No), the request from the first read DMAC 16 is processed in step ST22.

  If there is a request from another DMAC (ST24: Yes), the process proceeds to step ST25, and the third required transfer time calculation unit 2213 provided for the second write DMAC 17 having the third priority is required. Transfer time T23 is calculated. Even when it is determined in step ST19 that there is no request from the first read DMAC 16 (ST19: No), step ST25 is executed.

  Next, in step ST26, the third required transfer time calculator 2213 determines whether or not the elapsed time T1 is longer than the required transfer time T23. If it is longer (ST26: Yes), the request is sent in step ST27. The arbitration unit 222 processes the request from the second write DMAC 17.

  On the other hand, if the elapsed time T1 is within the required transfer time T23 (ST26: No), it is determined in step ST28 whether the elapsed time T1 is longer than the required transfer time T21. If it is longer, the process proceeds to step ST16 to process the request from the first write DMAC 15. If not, it is determined in step ST29 whether the elapsed time T1 is longer than the necessary transfer time T22. If it is longer, the process proceeds to step ST22 to process the request from the first read DMAC 16.

  After executing the request processing from the first write DMAC 15 (step ST16), the request processing from the first read DMAC 16 (step ST22), or the request processing from the second write DMAC 17 (step ST27), In step ST17, it is determined whether or not there is a waiting request (wait processing). If there is no request, it is repeated from step ST11 until it is determined in step ST18 that the transfer of all data has been completed.

  If there is a waiting request (ST17: Yes), if it is a request from the first write DMAC 15 (ST30: Yes), the process proceeds to step ST14, and the first read is performed instead of the first write DMAC 15. If the request is from the DMAC 16 (ST30: No → ST31: Yes), the process proceeds to Step ST21.

The processing of the flowchart of FIG. 7 described above is summarized as follows.
When a request is issued from the DMAC, the arbiter 213 first determines whether or not the request is from the first write DMAC 15. As a result of the determination, if so, the necessary transfer time T2 is calculated. Then, T2 is compared with the elapsed time T1 from the start of the current line, and if T1 is longer than T2, the request from the first write DMAC 15 is processed as it is. If T2 is longer, if there is a request from another DMAC during that time, it will be processed with priority. If not, the request from the first write DMAC 15 will be processed, and all data transfer has been completed. If not, wait for the next request.

  If the request issuer is not the first write DMAC 15, it is determined whether or not the first read DMAC 16 having the next highest priority is the issuer. If so, the same necessity as the first write DMAC 15 is necessary. The transfer time is calculated, and if a wait is necessary, a wait process is performed. If the request issuance source is not the first read DMAC 16, the remaining is only the second write DMAC 17, so the same calculation is executed for the second write DMAC 17.

  If a request from another DMAC is issued during the wait process for the first write DMAC 15, the process proceeds to a determination process of “whether or not the process is from the first read DMAC 16”. From there, the required transfer time is calculated, and it is determined that the first read DMAC 16 requires wait processing. When this is executed, it is checked whether the wait time of the first write DMAC 15 has elapsed. Execute the process. As a result of the confirmation, if the wait period has expired or there is no request from another DMAC, the request from the first write DMAC 15 is processed.

  When this process ends, a process is performed to determine whether there is any other DMAC in the wait state. This determination can be made based on a wait request signal (“1” indicates a wait request). The logic of the wait request signal for each DMAC is confirmed. If there is a DMAC in a wait state, the process proceeds to the request. If there is no waiting DMAC, it is determined whether or not all data transfer is completed. If it is completed, the process ends. If not, the process proceeds to accept the next request. Once asserted, the wait request signal is not negated until the request is processed. When the request is processed, a request processing completion signal is asserted from the request arbitration unit 222, and a wait request signal is negated in response thereto.

As described above, the arbiter 113 according to the second embodiment of the present invention has the following effects (1) to (4).
(1) For all DMACs, the data transfer status can be grasped and a wait request can be generated as appropriate.
(2) By performing arbitration while monitoring the data transfer amount of all DMACs, data transfer can be performed more accurately and efficiently.
(3) The DMAC during the wait process can be reliably processed without leaving it.
(4) Even in a wait state for a plurality of DMACs, it is possible to monitor normally and process the request reliably.

FIG. 2 is a block diagram illustrating a configuration of an arbiter in the MFP according to the first embodiment of this invention. It is a block diagram which shows the internal structure of the required transfer time calculation part of FIG. It is a flowchart which shows operation | movement of the arbiter of the 1st Embodiment of this invention. It is a timing chart which shows operation | movement of the arbiter of the 1st Embodiment of this invention. It is another timing chart which shows operation | movement of the arbiter of the 1st Embodiment of this invention. FIG. 6 is a block diagram illustrating a configuration of an arbiter in an MFP according to a second embodiment of this invention. It is a flowchart which shows operation | movement of the arbiter of the 2nd Embodiment of this invention. It is a block diagram which shows the structure of the conventional MFP. It is a timing chart which shows operation | movement of the arbiter in FIG.

Explanation of symbols

  15 ... first write DMAC, 16 ... first read DMAC, 17 ... second write DMAC, 113, 213 ... arbiter, 121 ... required transfer time calculation unit, 122, 222 ... Request arbitration unit, 123,223 ... Necessary transfer rate holding unit, 1211, 2211, 2212, 2213 ... Necessary transfer time T2 calculation unit and time comparison unit, 1212 ... Timer, 1213 ... A wait request signal generation unit.

Claims (8)

In an arbitration device that arbitrates transfer requests from a plurality of DMACs having different priorities,
A predetermined amount of data inputted every predetermined time can be transferred within the predetermined time, and a part of the predetermined amount of data within the predetermined time by the first DMAC set with the highest priority. Means for accepting transfer requests issued sequentially every time, means for executing processing according to the transfer requests, means for calculating a cumulative value of the transfer amount due to the transfer requests, and the cumulative value as the first DMAC By means of dividing by the transfer rate set for the above, means for calculating the required transfer time of the accumulated value data, means for measuring the elapsed time for each predetermined time, the elapsed time and the required transfer An arbitration apparatus comprising: means for comparing time; and means for determining whether to execute the processing according to the transfer request or to wait based on the comparison result. The arbitration device according to claim 1,
The means for determining causes the process according to the transfer request to be executed when the elapsed time exceeds the required transfer time, and waits for the process according to the transfer request when the elapsed time is within the required transfer time. Arbitration device characterized by letting it be. The arbitration device according to claim 2, wherein
The determining means is configured to execute processing according to a transfer request when the elapsed time is within the required transfer time and there is a transfer request from a DMAC other than the first DMAC. apparatus. In the arbitration device according to claim 1,
The arbitration apparatus is characterized in that the respective units are provided for DMACs other than the first DMAC. The arbitration device according to claim 1,
The determining means negates the wait request signal when it receives a processing completion signal from the executing means that has completed the processing according to the transfer request after generating the wait request signal for waiting for the processing according to the transfer request. An arbitration device characterized by that. The arbitration device according to claim 4, wherein
When waiting for transfer requests of a plurality of DMACs, when one standby process is completed, it is determined whether or not there are other DMACs that are waiting. An arbitration device that processes a transfer request from a DMAC. In an arbitration method for arbitrating transfer requests from a plurality of DMACs having different priorities,
A predetermined amount of data inputted every predetermined time can be transferred within the predetermined time, and a part of the predetermined amount of data within the predetermined time by the first DMAC set with the highest priority. A step of receiving a transfer request issued sequentially every time, a step of executing a process according to the transfer request, a step of calculating a cumulative value of a transfer amount by the transfer request, and the cumulative value as the first DMAC By dividing by a transfer rate set to the above, a step of calculating a required transfer time of the accumulated value data, a step of measuring an elapsed time for each predetermined time, the elapsed time and the required transfer An arbitration method comprising: a step means for comparing time; and a step for determining whether to execute the processing according to the transfer request or to wait based on the comparison result.   A program for causing a computer to execute each step of the arbitration method according to claim 7.

Images