Data transfer device and method

Abstract

To provide a data transfer device capable of realizing low delay in communication and a method.SOLUTION: A data transfer device comprises issuance means and control means. The issuance means issues a first request for transferring first data via a first interface. In a case where the first request is issued, the control means stops issuance of a second request for transferring second data following the first data from start of input of a response to the first request to the lapse of a period required for completing the input.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] Embodiments of the present invention relate to a data transfer device and method.

Background Art

[0002] In recent years, the use of Ethernet (registered trademark) has been progressing in fields such as industrial networks that connect various industrial devices in a factory and in-vehicle networks that connect control controllers in an automobile.

[0003] In such industrial networks and in-vehicle networks, since high real-time performance is required, various real-time Ethernet standards have been proposed.

[0004] By the way, in a communication device that generally constitutes a communication system, for example, data from a host device is transmitted to a network via a NIC (Network Interface Card). However, in the above-described real-time Ethernet standards, the processing (network processing) between the NIC and the network is defined.

[0005] However, when actually constructing a communication system, if the processing between the host device and the NIC is not considered in addition to the above-described network processing, it may not be possible to achieve high real-time performance (that is, low latency in communication) in communication performed via the network.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0007] Therefore, an object of the present invention is to provide a data transfer device and method capable of realizing low latency in communication.

Means for Solving the Problems

[0008] According to an embodiment, there is provided a data transfer device that sequentially transfers data for which a priority is specified. The data transfer device includes an issuing unit and a control unit. The issuing unit issues a first request for transferring first data via a first interface. When the first request is issued, the control unit stops issuing a second request for transferring second data after the first data until a period required from the start to the completion of the input of a response to the first request via the first interface elapses.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Embodiments for Carrying Out the Invention

[0010] Hereinafter, each embodiment will be described with reference to the drawings. (First Embodiment) First, the first embodiment will be described. FIG. 1 shows an example of the configuration of a communication device in a comparative example of this embodiment. Note that the communication device 1 shown in FIG. 1 is assumed to be a device such as a personal computer (PC), a server device, an application-specific LSI (Large-Scale Integration), or an FPGA (Field Programmable Gate Array), but other devices may also be used.

[0011] As shown in FIG. 1, the communication device 1 includes a CPU 10, a memory 20, a data transfer device 30, a memory 40, and the like.

[0012] The CPU 10 and the memory 20 constitute a host device. The CPU 10 (host processor) is connected to a memory (hereinafter referred to as the host-side memory) 20 via a memory controller within the CPU 10. The CPU 10 executes various application programs loaded in the host-side memory 20. In the present embodiment, it is assumed that by executing an application program by the CPU 10, data (hereinafter referred to as transmission data) transmitted from the communication device 1 to an external device via a network is generated.

[0013] Note that the above-described transmission data and a descriptor (descriptor) in which information regarding the transmission data is described are written into the host-side memory 20 by a driver 10a operating on the CPU 10. The descriptor includes, for example, the data length (size) of the transmission data and the address of the host-side memory 20 in which the transmission data is written.

[0014] Here, the host-side memory 20 includes a region (hereinafter referred to as the transmission data region) 20a into which transmission data is written and a region (hereinafter referred to as the descriptor region) 20b into which a descriptor is written. In the present embodiment, a predetermined priority is specified for the transmission data by the above-described application program, and the transmission data region 20a and the descriptor region 20b have a plurality of queues (a plurality of queues to which the priority is assigned) corresponding to the priority. In the example shown in FIG. 1, the transmission data region 20a and the descriptor region 20b have queues q0 to qN.

[0015] In the present embodiment, the host-side memory 20 is realized by, for example, SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory), or SDRAM (Synchronous Dynamic Random Access Memory).

[0016] The data transfer device 30 corresponds to, for example, a DMAC (Direct Memory Access Controller), and has a function of sequentially transferring the data written in the host-side memory 20 (transmission data area 20a) described above.

[0017] As shown in FIG. 1, the data transfer device 30 includes a host interface 31, a first interface unit 32, a descriptor reading unit 33, a descriptor buffer 34, a transmission data reading unit 35, and a second interface unit 36.

[0018] The host interface 31 is an interface for connecting the data transfer device 30 to the CPU 10 (driver 10a). The host interface 31 has a register area for holding information for accessing the queues q0 to qN corresponding to the above priorities. Descriptor information is stored in the register areas corresponding to the queues q0 to qN of the host interface 31 based on the transfer requests issued from the driver 10a when the above transmission data is generated.

[0019] The first interface unit 32 is an interface for connecting the data transfer device 30 to the host-side memory 20, and is provided to realize DMA processing.

[0020] The descriptor reading unit 33 issues a descriptor request (a request for requesting the descriptor) for reading a descriptor from the host-side memory 20 (descriptor area 20b) based on the descriptor information stored in the queues q0 to qN of the host interface 31. The descriptor request issued by the descriptor reading unit 33 includes the address and data length (size) of the descriptor to be read based on the descriptor request, and is output to the host-side memory 20 via the first interface unit 32.

[0021] As described above, the descriptor read from the descriptor area 20b based on the descriptor request output to the host-side memory 20 is input to the data transfer device 30 via the first interface unit 32. The descriptor thus input to the data transfer device 30 is stored in the descriptor buffer 34. Note that the descriptor buffer 34 has queues q0 to qN corresponding to the above-described priorities.

[0022] The transmission data reading unit 35 issues a transmission data request (a request for the transmission data) for reading transmission data from the host-side memory 20 (transmission data area 20a) based on the descriptors stored in the queues q0 to qN of the descriptor buffer 34. The transmission data request issued by the transmission data reading unit 35 includes the address and data length (size) of the transmission data read based on the transmission data request, and is output to the host-side memory 20 via the first interface unit 32.

[0023] As described above, the transmission data read from the transmission data area 20a based on the transmission data request output to the host-side memory 20 is input to the data transfer device 30 via the first interface unit 32. The transmission data thus input to the data transfer device 30 is output to the memory 40 via the second interface unit 36.

[0024] The second interface unit 36 is an interface for connecting the data transfer device 30 to the memory 40.

[0025] The memory 40 has a queue Q, and the transmission data output from the data transfer device 30 (second interface unit 36) as described above is stored in the queue Q.

[0026] Although omitted in FIG. 1, the memory 40 is used by a network device included in the communication device 1, and the network device transmits the transmission data stored in the memory 40 (queue Q) to a network (for example, a network based on Ethernet). Note that the network device is a device for connecting to a network and includes, for example, a network interface card (NIC: Network Interface Card). In this case, the memory 40 can be referred to as, for example, a transmission memory for NIC (NIC-side memory).

[0027] Also, assume that the above-described descriptor area 20b is realized as a ring buffer for each priority. The ring buffer is configured to store a plurality of data (descriptors), and the data in the ring buffer is managed using a write pointer (Head) indicating the position to write the data and a read pointer (Tail) indicating the position to read the data. Note that the write pointer is updated each time data is written to the ring buffer. Also, the read pointer is updated each time data is read from the ring buffer. When the descriptor area 20b is realized by a ring buffer, the descriptor information of the host interface 31 described above stores the head address of the ring buffer, the length of the ring buffer, the write pointer (Head), the read pointer (Tail), etc. for each priority. The head address of the ring buffer, the length of the ring buffer, etc. are set when the descriptor area 20b is secured, such as at the time of initialization of the data transfer device 30. When the driver 10a transmits data, it checks whether there is an empty area in the ring buffer from the Head and Tail of the corresponding priority. If there is an empty area, after preparing the descriptor and the transmission data, it advances the Head to notify the data transfer device 30 that there is transmission data. When the data transfer device 31 determines that there is transmission data in the ring buffer from the Head and Tail, it performs data transmission processing. By advancing the Tail when a series of processing is completed, it becomes possible to notify the driver 10a that the data transmission has been completed. Although omitted in this embodiment, the data transfer device 30 has a mechanism such as an interrupt signal, and the fact that the Tail has been updated is notified to the CPU 10 by an interrupt.

[0028] Furthermore, although it is assumed that the data transfer device 30 (DMAC) included in the communication device 1 shown in FIG. 1 is used when transferring transmission data between two memories (host-side memory 20 and NIC transmission memory 40), the data transfer device 30 may be used when transferring transmission data between processing devices (devices) other than memories such as NICs and GPUs (Graphics Processing Units).

[0029] Also, in FIG. 1, the data transfer device 30 has been described as including the host interface 31, the first interface unit 32, the descriptor reading unit 33, the descriptor buffer 34, the transmission data reading unit 35, and the second interface unit 36. However, at least a part of the data transfer device 30 may be implemented by software or hardware, or may be implemented by a combination of software and hardware.

[0030] Furthermore, in FIG. 1, the NIC transmission memory 40 has been described as having one queue Q. However, the NIC transmission memory 40 may have a plurality of queues (for example, queues Q0 to QN) prepared for each priority specified for the above-described transmission data.

[0031] Also, in FIG. 1, the communication device 1 has been described as including the CPU 10, the host-side memory 20, the data transfer device 30, and the NIC transmission memory 40. However, a part of the CPU 10, the host-side memory 20, the data transfer device 30, and the NIC transmission memory 40 may be configured integrally. Further, for example, the data transfer device 30 may be incorporated into a NIC or the like as a data transfer unit (transfer processing unit).

[0032] Next, with reference to the flowchart of FIG. 2, an example of the processing procedure of the communication device 1 in the comparative example of the present embodiment will be described. In the present embodiment, a predetermined priority is specified for the transmission data. However, in the following description, the priority may simply be referred to as the priority of the transmission data. Also, the priority of the transmission data may be referred to as the priority of a descriptor (hereinafter referred to as the transmission data descriptor) in which information regarding the transmission data is described, the priority of a transmission request for the transmission data, or the priority of a descriptor request for the descriptor.

[0033] First, when transmission data is generated by the CPU 10 executing an application program, the driver 10a receives a transmission instruction for the transmission data from the application program (step S1).

[0034] When a transmission instruction for transmission data is received in step S1, the driver 10a writes the transmission data and a descriptor of the transmission data into the host-side memory 20 (step S2).

[0035] In step S2, the transmission data is written into a queue corresponding to the priority of the transmission data among the queues q0 to qN included in the transmission data area 20a included in the host-side memory 20. Similarly, the descriptor of the transmission data is written into a queue corresponding to the priority of the descriptor (that is, the priority of the transmission data) among the queues q0 to qN included in the descriptor area 20b included in the host-side memory 20.

[0036] Note that, for example, the queues q0 to qN included in the transmission data area 20a and the queues q0 to qN included in the descriptor area 20b correspond to each other. For example, assuming that the priority of the transmission data corresponds to queue N, the transmission data is written into queue N included in the transmission data area 20a, and the descriptor of the transmission data is written into queue N included in the descriptor area 20b.

[0037] When a descriptor is written into queue N included in the descriptor area 20b, a write pointer that manages the data in the queue N (ring buffer) is updated to indicate the position where the next descriptor will be written. Although queue N included in the descriptor area 20b has been described, the same processing applies if other queues are configured as ring buffers.

[0038] When the process of step S2 is executed, the driver 10a issues a transfer request (a request for transferring transmission data) to the data transfer device 30 (step S3). Note that the transfer request issued in step S3 includes descriptor information. This descriptor information includes a pointer (a read pointer of the ring buffer) indicating the position within the descriptor area 20b where the descriptor was written in step S2, and is stored in the register area corresponding to the priority of the transmission data and the descriptor written to the host-side memory 20 in step S2 among the queue q0 to qN register areas included in the host interface 31 included in the data transfer device 30.

[0039] Here, when the descriptor information is stored in the register area of the host interface 31 as described above, the write pointer that manages the data in the queue (ring buffer) is updated. The descriptor reading unit 33 detects a transfer request from the driver 10a based on such an update of the write pointer.

[0040] In this case, the descriptor reading unit 33 issues a descriptor request based on the pointer included in the descriptor information stored in the queue q0 to qN register area of the host interface 31 (step S4). The descriptor request issued in step S4 is a request for reading a descriptor from the position indicated by the pointer included in the descriptor information, and is output to the host-side memory 20 via the first interface unit 32.

[0041] When the process of step S4 is executed, a descriptor is read from the descriptor area 20b based on the descriptor request, and the read descriptor is input to the data transfer device 30 via the first interface unit 32. The descriptor input to the data transfer device 30 via the first interface unit 32 in this way is stored in the descriptor buffer 34. The descriptor buffer 34 has queues q0 to qN, and the descriptor input to the data transfer device 30 is stored in the queue corresponding to the priority of the descriptor among the queues q0 to qN.

[0042] Next, the transmission data reading unit 35 issues a transmission data request based on the descriptors stored in the queues q0 to qN of the descriptor buffer 34 (step S5). As described above, the descriptor includes the data length of the transmission data and the address of the transmission data area 20a where the transmission data is written. The transmission data request issued in step S5 is a request to read the transmission data of the data length from the address of the transmission data area 20a. The transmission data request is output to the host-side memory 20 via the first interface unit 32.

[0043] When the process of step S5 is executed, transmission data is read from the transmission data area 20a based on the transmission data request, and the read transmission data is input to the data transfer device 30 via the first interface unit 32.

[0044] The transmission data input to the data transfer device 30 via the first interface unit 32 in this way is output to the NIC transmission memory 40 via the second interface unit 36 (step S6).

[0045] In the comparative example of the present embodiment, by executing the process shown in FIG. 2 described above, transmission data can be transferred from the host-side memory 20 to the NIC transmission memory 40 via the first interface unit 32 and the second interface unit 36. The transmission data transferred from the host-side memory 20 to the NIC transmission memory 40 by the data transfer device 30 in this way is transmitted to the network (that is, an external device or the like) via the NIC.

[0046] In the process shown in FIG. 2 described above, for example, a descriptor request is issued based on a pointer included in descriptor information stored in the queue q0 to qN register areas of the host interface 31. However, if a delay occurs in the process of reading the descriptor based on the descriptor request, the write pointer (Head) of the queue q0 to qN register areas of the host interface 31 advances while the delay occurs, and there is a possibility that descriptors of two or more priorities are stored in the descriptor area 20b.

[0047] In this case, the descriptor reading unit 33 selects one of the queues of two or more priorities in which the descriptor information is stored, and operates to issue a descriptor request based on the pointer included in the descriptor information stored in the register area of the selected priority. Specifically, the descriptor reading unit 33 can select, for example, the queue (for example, queue qN) corresponding to the highest priority among the two or more register areas in which the descriptor information is stored according to Strict Priority. Note that the selection of the queue may be performed according to another algorithm such as the Round-Robin method.

[0048] Here, the case where the descriptor reader 33 selects one queue among the queues of the host interface 31 has been described. However, when descriptors are stored in two or more queues among the queues q0 to qN of the descriptor buffer 34, the transmission data reader 35 shall select one queue in the same manner as the descriptor reader 33 and issue a transmission data request. Also, the case where the descriptor reader 33 and the transmission data reader 35 issue requests simultaneously is conceivable. In this case, one request is selected in the first interface unit 32. In this case, priorities may be assigned to the descriptor request and the transmission data request and processed with Strict Priority (for example, setting a priority such that the transmission data request is always prioritized), or the descriptor request and the transmission data request may be alternately issued in a Round-Robin manner. Note that priorities may be set for each of the descriptor request and the transmission data request without distinction, and the request may be selected in the first interface unit 32.

[0049] Note that the queue q0 to qN register areas of the host interface 31 and the multiple queues q0 to qN of the descriptor buffer 34 described above are assumed to have higher priorities in the order of, for example, queue q0, q1,..., qN. However, the priorities corresponding to each of the queues q0 to qN (that is, the correspondence between each of the queues q0 to qN and the priorities) are managed in, for example, a mapping table or the like and may be changed as necessary.

[0050] Hereinafter, with reference to FIG. 3, the processing time of the data transfer device 30 according to the comparative example of the present embodiment will be described. FIG. 3 shows the relationship between Trigger, Req, and Res in the data transfer device 30.

[0051] The trigger shown in FIG. 3 indicates the opportunity for issuing a request. The request indicates a request for transferring data issued based on the trigger. The response is a response to the request, and when the request is issued, it is input to the data transfer device 30 via the first interface unit 32 (read from the host-side memory 20). Also, the horizontal axis (numerical values from 0 to 550) in FIG. 3 indicates the clock cycle (clock period) in the data transfer device 30 (DMAC).

[0052] Here, the requests issued in the data transfer device 30 according to the comparative example of the present embodiment include a descriptor request and a transmission data request.

[0053] Although the request shown in FIG. 3 does not distinguish between the descriptor request and the transmission data request, when the request is a descriptor request, the trigger is that the descriptor information included in the transfer request is stored in one of the queues in the queue q0 to qN register area of the host interface 31, and the descriptor input from the host-side memory 20 based on the descriptor request is the response.

[0054] On the other hand, when the request is a transmission data request, the trigger is that the descriptor is stored in one of the queues in the queue q0 to qN of the descriptor buffer 34, and the transmission data input from the host-side memory 20 based on the transmission data request is the response.

[0055] Note that FIG. 3 shows the operation of the data transfer device 30 regarding the request for transferring the transmission data with priority p1. In the following description, the request for transferring the transmission data with priority p1 is referred to as request p1, the trigger that is the opportunity for issuing the request p1 is referred to as trigger p1, and the response to the request p1 is referred to as response p1.

[0056] First, as shown in FIG. 3, assume that, for example, trigger p1 occurs at the 49th clock cycle. In this case, for example, request p1 is issued at the 50th clock cycle immediately after trigger p1 occurs.

[0057] When request p1 is issued in this way, the request p1 is output to the host-side memory 20 via the first interface unit 32, and the response p1 read from the host-side memory 20 is input to the data transfer device 30 via the first interface unit 32.

[0058] The response p1 (descriptor or transmission data) input to the data transfer device 30 is immediately output to the destination memory (descriptor buffer 34 or NIC transmission memory 40).

[0059] In the comparative example of the present embodiment, the period required from when request p1 is issued until the input of response p1 to the data transfer device 30 actually starts (the head of response p1 is input to the data transfer device 30) is defined as RTC (Round-Tripe Cycle). RTC is represented by, for example, the number of clock cycles, and is generated based on the processing delay in the path between the data transfer device 30 (DMAC) and the host-side memory 20. This processing delay is generated, for example, by a bus such as AXI4 Interconnect or PCIe for connecting to the host-side memory 20 and the processing of the host-side memory controller. Therefore, RTC is not constant and varies depending on the load of the connected IP cores, controllers, buses, and memories.

[0060] In the example shown in FIG. 3, since request p1 is issued at the 50th cycle and the input of response p1 starts at the 250th cycle, RTC is 200 cycles.

[0061] Also, in the comparative example of the present embodiment, the period from the start of the input of the response p1 via the first interface unit 32 until the completion of the input is defined as DTC (Data Transfer Cycle). In view of the fact that the response p1 input to the data transfer device 30 as described above is immediately output to the memory of the output destination, DTC can also be said to be the period required to output (transfer) the response p1 input to the data transfer device 30 to the memory of the output destination. Similar to the RTC described above, DTC is represented by, for example, the number of clock cycles.

[0062] Note that when the data transfer device 30 (DMAC) can process data without delay and there is space in the memory of the output destination (such as a FIFO memory), DTC can be calculated from the data length (transfer size number) of the response p1 with respect to the request p1 issued by the data transfer device 30 to the host-side memory 20 and the bus width (the minimum value of the bus width of the host-side memory 20 and the bus width of the memory of the output destination). That is, DTC corresponds to the minimum number of clock cycles for processing the response to one request.

[0063] As an example, for instance, when a transmission data request for requesting 1580 Byte of transmission data is issued in an environment where the bus width is 32 Byte (256 bit), DTC becomes 1580 / 32 ≒ 50 cycle. In this case, DTC corresponds to the burst length required for burst access such as AXI4.

[0064] The processing clock cycles for one request (the period from the issuance of the request until the completion of the input of the response) are obtained by adding RTC and DTC, and in the example shown in FIG. 3, it is 250 cycle. Note that this processing clock cycle can be converted into processing time by using the operating frequency of the data transfer device 30 (DMAC). For example, assuming that the data transfer device 30 (and the bus) operates at 125 MHz, one clock cycle is 8 ns, and the processing time is 8×250 = 2000 ns.

[0065] Here, although priorities are specified for the transmission data in the comparative example of the present embodiment, a situation is assumed in which a plurality of requests (descriptor requests or transmission data requests) for transferring transmission data with different priorities are sequentially issued.

[0066] Hereinafter, with reference to FIG. 4, an example of the delay that occurs in a situation where a plurality of requests for transferring transmission data with different priorities are sequentially issued will be described. In FIG. 4, detailed descriptions of the same parts as in FIG. 3 will be omitted.

[0067] Note that FIG. 4 shows the operation of the data transfer device 30 regarding requests for transferring transmission data with priorities p1 to p3. In FIG. 3, the request, trigger, and response regarding priority p1 (of the transmission data) were described as request p1, trigger p1, and response p1, respectively. However, in FIG. 4, the requests, triggers, and responses regarding priorities p1 to p3 (of the transmission data) are referred to as requests p1 to p3, triggers p1 to p3, and responses p1 to p3, respectively. Also, here, a case where priority p3 is higher than priorities p1 and p2 is assumed.

[0068] First, as shown in FIG. 4, assume a case where triggers p1 to p3 occur continuously. In this case, the data transfer device 30 issues request p1 immediately after trigger p1 occurs, request p2 immediately after trigger p2 occurs, and request p3 immediately after trigger p3 occurs, in accordance with the occurrence order of the triggers p1 to p3. Here, it is assumed that request p1 is issued at the 50th clock cycle, request p2 is issued at the 70th clock cycle, and request p3 is issued at the 90th clock cycle.

[0069] Here, when request p1 is issued, in data transfer device 30, the input of response p1 starts at the timing when the above-described RTC has elapsed, and the input of the response p1 is completed at the timing when the DTC has elapsed. Specifically, assuming that the RTC is 200 cycles and the DTC is 50 cycles as described above, the input of response p1 starts at the 250th clock cycle and is completed at the 300th clock cycle.

[0070] Next, assume the case when request p2 is issued. If it is assumed that request p1 has not been issued, it is considered that the input of response p2 starts at the 270th clock cycle. However, as shown in FIG. 4, when request p1 has been issued, the input of response p1 is not completed at the timing of the 270th clock cycle, and the input of response p2 cannot be started at the 270th clock cycle. For this reason, the input of response p2 starts at the 300th clock cycle when the input of response p1 is completed, and is completed at the 350th clock cycle.

[0071] Furthermore, assume the case when request p3 is issued. If it is assumed that requests p1 and p2 have not been issued, it is considered that the input of response p3 starts at the 290th clock cycle. However, as shown in FIG. 4, when requests p1 and p2 have been issued, the inputs of responses p1 and p2 are not completed at the timing of the 290th clock cycle, and the input of response p3 cannot be started at the 290th clock cycle. For this reason, the input of response p3 starts at the 350th clock cycle when the inputs of responses p1 and p2 are completed, and is completed at the 400th clock cycle. Therefore, FIG. 4 shows that 310 clock cycles are required from the occurrence of trigger p3 that triggers the above-described request p3 until the input of response p3 is completed.

[0072] That is, according to the example shown in FIG. 4, when request p3 is issued at the 90th clock cycle, although the input of response p3 is completed at the earliest at the 340th clock cycle, due to the fact that low-priority requests p1 and p2 have already been issued, it can be seen that the delay until the input of response p3 for high-priority request p3 is completed becomes large.

[0073] The above-mentioned delay is caused by the influence of the data length (burst access number) that can be input (requested) in one request and the bus bandwidth. For example, assuming that the bus protocol is AXI4 Memory Mapped Interface, when the bus width is 32 bytes, the maximum data size that can be requested in one request is 4KB.

[0074] Note that the maximum burst length in the AXI4 Memory Mapped Interface is 256. In this case, assuming that the bus width is 32 bytes, the data length (maximum request size) that can be requested in one request is considered to be 8192 bytes (32 bytes × 256). However, in AXI-4, burst access beyond the 4KB address boundary is not possible, so actually 4096 bytes (that is, 4KB) is the maximum value.

[0075] Here, the number of clock cycles required to input 4KB (of data) based on a request is 128 (clock cycles) obtained by dividing the 4KB by the bus width of 32 bytes. Therefore, if a request is immediately issued every time a trigger occurs, the number of clock cycles required for the input of the response to the request accumulates, and as a result, it becomes a factor in the delay of the response to a later request (a request for transferring high-priority transmission data).

[0076] Therefore, in the present embodiment, a configuration for suppressing the delay of the response to a request for transferring high-priority data as described in FIG. 4 above will be described.

[0077] FIG. 5 shows an example of the configuration of the communication device in the present embodiment. In FIG. 5, the same parts as those in FIG. 1 described above are denoted by the same reference numerals and the detailed description thereof is omitted, and the parts different from FIG. 1 will be mainly described.

[0078] As shown in FIG. 5, in the communication device 1 in the present embodiment, the data transfer device 30 includes a DTC delay control unit 37.

[0079] The DTC delay control unit 37 holds a counter inside. When issuing the above-described request (descriptor request or transmission data request), the DTC delay control unit 37 sets (sets) the DTC required by the request (that is, the number of clock cycles required from the start of the input of the response to the request until the input is completed) in the counter. The DTC delay control unit 37 stops issuing the next request until the number of clock cycles set in the counter in this way elapses.

[0080] Note that the stop of issuing the request is realized by the DTC delay control unit 37 instructing the descriptor reading unit 33 or the transmission data reading unit 35 that issues the request.

[0081] Also, in the present embodiment, it is described that the DTC is set in the counter held inside the DTC delay control unit 37, but the counter may be set with a value obtained by adding or subtracting a constant to or from the DTC (that is, a predetermined calculation result with respect to the DTC), for example.

[0082] Next, with reference to FIG. 6, an example of the operation of the DTC delay control unit 37 described above will be described. Note that the DTC delay control unit 37 operates, for example, at the timing when the processes in steps S4 or S5 shown in FIG. 2 described above are executed.

[0083] First, when the above-described trigger has not occurred, the DTC delay control unit 37 is in a state of waiting for the issuance of a request (step S11).

[0084] Here, assume a case where a trigger occurs and a request is issued based on the trigger. In this case, the DTC delay control unit 37 sets the DTC required for the issued request in the counter held inside the DTC delay control unit 37 (step S12). Note that the DTC set in the counter is calculated from the data length and bus width of the response to the request.

[0085] Next, the DTC delay control unit 37 subtracts the counter value in which the DTC was set in step S12 for each clock cycle (step S13). Note that the process of step S13 is repeatedly executed until the counter value becomes 0, and the counter value becomes 0 at the timing when the DTC (number of clock cycles) has elapsed. In other words, the DTC delay control unit 37 operates to decrease the counter value according to the clock cycle.

[0086] When the counter value set in the counter is not 0 (that is, it indicates a value other than 0), the DTC delay control unit 37 stops (forbids) the issuance of the next request to the host-side memory 20 and repeats the process of step S13.

[0087] On the other hand, when the counter value set in the counter is 0 (that is, it has been subtracted until the counter value becomes 0), the DTC delay control unit 37 releases the stop (prohibition) of the issuance of the next request to the host-side memory 20 and returns to step S11 to repeat the process.

[0088] When the process is repeated by returning to step S11, if a plurality of triggers have occurred, a high-priority request among the plurality of requests that can be issued based on each of the plurality of triggers is selected, and the selected request is issued (that is, a request with a higher priority is preferentially issued).

[0089] According to the operation of such a DTC delay control unit 37, each time a request is issued, it becomes possible to issue the next request after the DTC (number of clock cycles) required by the request has elapsed.

[0090] As described above, the data transfer device 30 according to the present embodiment, as shown in FIG. 7 for example, when issuing a request p1 (first request) for transferring transmission data (first data) with priority p via the first interface unit 32, the period from the start to the completion of the input of the response p1 to the request p1 via the first interface unit 32 (that is, the DTC required by the request p1) is elapsed. During this period, the issuance of a request p2 (second request) for transferring transmission data (second data) with priority p2 is stopped.

[0091] According to this, for example, when the issuance of request p3 (that is, the third request for transferring the third data) becomes possible due to the occurrence of trigger p3 while the issuance of request p2 is stopped, the request p3 with a higher priority than the low-priority request p2 can be preferentially issued.

[0092] Specifically, unlike FIG. 4 (comparative example of the present embodiment) described above, the data transfer device 30 according to the present embodiment does not immediately issue requests p2 and p3 after the occurrence of triggers p2 and p3 as shown in FIG. 7 by setting the DTC (for example, 50 cycles) required by request p1 in the counter at the timing when request p1 is issued. In the example shown in FIG. 7, the issuance of the next request after request p1 is stopped until the 100th clock cycle.

[0093] Also, in the example shown in FIG. 7, at the timing of the 100th clock cycle when the counter value becomes 0 (that is, the suspension of the issuance of the request is released), the issuance of requests p2 and p3 is possible. In this case, for example, according to Strict Priority, the request p3 with a higher priority is issued.

[0094] According to this, the number of clock cycles required from the occurrence of trigger p3 until the input of response p3 is completed is 260 cycles, and it can be seen that the processing time of the data transfer device 30 is 50 clock cycles shorter than the 310 clock cycles described in FIG. 4 above (that is, the delay is small).

[0095] As shown in FIG. 7, the timing when all the inputs of responses p1 to p3 are completed is the 400th clock cycle, which is the same as that in FIG. 4 (comparative example of the present embodiment) described above. That is, in the present embodiment, even if the issuance of requests is temporarily stopped as described above, the processing of the entire data transfer device 30 is not delayed.

[0096] In the present embodiment, with the above-described configuration, by considering the DTC (request burst length), it is possible to suppress the issuance of low-priority requests from affecting the input (transfer) of responses to high-priority requests, and to achieve low latency (that is, high real-time performance) in communication for transmitting transmission data generated in the host device (application program) via the network.

[0097] In addition, in this embodiment, it is assumed that the issuance of both the descriptor request and the transmission data request is stopped. However, the request whose issuance is stopped may be either the descriptor request or the transmission data request. That is, in this embodiment, for example, when a transmission data request is issued, the issuance of the next transmission data request is stopped until the DTC required for the transmission data request (that is, the number of clock cycles required to input the transmission data) elapses. On the other hand, the descriptor request may be immediately issued at the timing when a trigger occurs. Similarly, in this embodiment, for example, when a descriptor request is issued, the issuance of the next descriptor request is stopped until the DTC required for the descriptor request (that is, the number of clock cycles required to input the descriptor) elapses. On the other hand, the transmission data request may be immediately issued at the timing when a trigger occurs. Even with such a configuration, since it is possible to improve the delay related to the input (reading) of at least one of the descriptor and the transmission data, as a result, it is possible to contribute to the realization of low latency in communication.

[0098] Also, when the issuance of both the descriptor request and the transmission data request is stopped as described above, if the memories holding the descriptor and the transmission data are separate, or if the interfaces accessing the memories are different, the counter values may be individually managed for each of the descriptor request and the transmission data request.

[0099] Note that according to the data transfer device 30 according to the present embodiment, although the issuance of requests is stopped regardless of the priority, the requests whose issuance is stopped may be determined (selected) based on the priority. Specifically, in the present embodiment, it has been described that when the counter value is other than 0, the issuance of requests of all priorities is stopped. However, in the present embodiment, for example, only the issuance of requests whose priority is less than the threshold value (that is, requests with a lower priority than a predetermined priority) is stopped, and the issuance of requests whose priority is equal to or higher than the threshold value is not stopped (that is, even if the counter value is other than 0, the issuance is immediately performed). Such a configuration may also be adopted.

[0100] Incidentally, as described above, in the present embodiment, it is assumed that, for example, transmission data is transmitted to a network based on Ethernet via a NIC. However, for example, the standardization of TSN (Time-Sensitive Network) that realizes high real-time performance on Ethernet is being promoted by the IEEE 802.1 TSN Task. TSN is composed of a plurality of standards and is a standardized extension considering applying AVB (Audio / Video Bridging), which realizes low latency used in, for example, pro audio, to industrial networks and in-vehicle networks. TSN aims to achieve higher reliability in addition to higher real-time performance than AVB.

[0101] One of the TSN standards is IEEE 802.1Qbv. By controlling based on gate control information (schedule information) in which a plurality of queues (transmission queues) with different priorities are preset, IEEE 802.1Qbv can strictly control the transmission timing of frames (data) for each traffic class (priority). Each queue is provided with a gate that permits the transmission of frames. When the gate is open, the transmission of frames is permitted, and when the gate is closed, the transmission of frames is prohibited. The gate control information sets the state (open or closed) of each gate for one cycle.

[0102] NICs and the like compliant with IEEE 802.1Qbv select a queue with a priority level at which a frame can be transmitted based on the current time, gate control information, the start time of gate control (gate control), etc., and perform frame transmission processing. That is, in IEEE 802.1Qbv, the transmission timing of frames is controlled for each traffic class corresponding to the priority level.

[0103] By strictly controlling the frame transmission timing in accordance with such gate control information, it is possible to prevent collisions in the transmission timing between frames with different priorities and reduce the transmission delay time and the fluctuation of the transmission delay time.

[0104] Also, as another TSN standard, IEEE 802.1Qbu / 802.3br interrupts the processing of a frame being transmitted and allows the transmission processing of a high-priority frame to be interrupted when the transmission processing of a high-priority frame occurs.

[0105] By using a real-time Ethernet such as the above-described TSN, it is possible to reduce the network delay related to the transmission of data that requires high real-time performance.

[0106] Note that the scope defined by real-time Ethernet standards such as TSN is network processing between the NIC and the network. However, when actually constructing a communication system, it is necessary to consider the processing between the host device and the NIC as well. Specifically, as described in this embodiment, the process of transferring transmission data (frames) input from the host-side memory 20 to the NIC transmission memory 40 by DMA processing is executed asynchronously with the transmission control timing of TSN. Therefore, when access to the memory or the bus is congested, the DMA processing of low-priority transmission data may affect the DMA processing of high-priority transmission data. Therefore, in the present embodiment, from the above-described viewpoint, by controlling the issue timing of requests for transferring transmission data with different priorities from the host-side memory 20 to the NIC transmission memory 40 (transmission queue), it is possible to suppress the transfer process of low-priority transmission data from affecting the transfer process of high-priority transmission data and reduce the transfer delay.

[0107] Considering the application of TSN to the communication device 1 in the present embodiment as described above, the NIC transmission memory 40 has queues Q0 to QN (destination queues) corresponding to priorities (traffic classes), for example. However, the data transfer device 30 according to the present embodiment may be configured to set attributes for each of the queues Q0 to QN and control (determine) whether to stop issuing requests for each attribute.

[0108] For example, in the case of IEEE 802.1Qbu / 803.3br, the MAC (Media Access Controller) of the queue connection destination is classified into attributes such as Preemptable and Express. In this case, it may be considered to stop only the issuance of requests for transferring transmission data stored in the queue connected to Preemptable, which does not require relatively low-latency transmission.

[0109] In order to realize such a configuration, it is necessary to determine the attributes (Preemptable or Express) of each of the queues Q0 to QN included in the above-described NIC transmission memory 40. However, the data transfer device 30 (DMAC) shall hold a table (hereinafter referred to as an attribute determination table) for determining the attributes of each of the queues Q0 to QN internally. This attribute determination table (that is, the correspondence between the queues Q0 to QN and the attributes) may be set, for example, from the CPU 10 or the like via the host interface 31.

[0110] The attributes of each of the queues Q0 to QN described here may be different in viewpoint from the priorities of the transmission data described in the present embodiment (that is, they may be set without depending on the priorities).

[0111] In the present embodiment, the RTC, DTC, etc. have been described as being represented by the number of clock cycles. However, in view of the fact that the clock cycle can be converted into time using the operating frequency of the data transfer device 30 as described above, the RTC and DTC may be represented by time. In this case, the DTC (counter value) set in the counter held inside the DTC delay control unit 37 as described above may be decreased as time elapses (for example, if it is a counter with a 1 ns granularity, the counter value decreases every 1 ns).

[0112] (Second Embodiment) Next, the second embodiment will be described. In this embodiment, detailed descriptions of the same parts as those in the first embodiment described above will be omitted, and mainly the parts different from the first embodiment will be described.

[0113] First, referring to FIG. 8, taking the data transfer device 30 according to the first embodiment described above as a comparative example in this embodiment, the processing time of the data transfer device 30 will be described. In FIG. 8, detailed descriptions of the same parts as those in FIG. 3 described above will be omitted.

[0114] FIG. 8 shows the relationship between the descriptor request (Req(Dsc)), the transmission data request (Req(Data)), and the transmission data (Data) in the data transfer device 30.

[0115] Note that FIG. 8 shows a series of operations of the data transfer device 30 when transferring transmission data with priority p1. In the following description, the descriptor in which information about the transmission data with priority p1 is described is referred to as descriptor p1, the descriptor request for requesting the descriptor p1 is referred to as descriptor request p1, the transmission data request for requesting the transmission data with priority p1 is referred to as transmission data request p1, and the transmission data with priority p1 is referred to as transmission data p1.

[0116] Also, in FIG. 8, the descriptor request (Req(Dsc)) and the transmission data request (Req(Data)) issued from the data transfer device 30 and the transmission data (Data) input to the data transfer device 30 are shown, but the descriptor (Dsc) input to the data transfer device 30 is omitted. In the following description, the descriptor input to the data transfer device 30 based on the descriptor request p1 is also referred to as descriptor p1 in the same manner as the transmission data p1 and the like.

[0117] As shown in FIG. 8, for example, when the descriptor request p1 is issued at the 50th clock cycle, the descriptor request p1 is output to the host-side memory 20 via the first interface unit 32, and the descriptor p1 read from the host-side memory 20 (descriptor area 20b) is input to the data transfer device 30 via the first interface unit 32. The period (RTC) required from the issuance of the descriptor request p1 until the actual input of the descriptor p1 starts is 200 cycles.

[0118] Here, it is assumed that the time required for the input of the descriptor p1 and the writing to the descriptor buffer 34 is sufficiently small, and the transmission data request p1 is issued at the 250th clock cycle. This is because, in many cases, the size of the descriptor is small, and the DTC required for one-time descriptor transfer is 1 to several cycles. The descriptor p1 (the size and address of the transmission data p1, etc.) is used for the issuance of the transmission data request p1 as information necessary for the transfer of the transmission data p1 (frame).

[0119] When the transmission data request p1 is issued in this way, the transmission data request p1 is output to the host-side memory 20 via the first interface unit 32, and the transmission data p1 read from the host-side memory 20 (transmission data area 20a) is input to the data transfer device 30 via the first interface unit 32. In the example shown in FIG. 8, the period (RTC) required from the issuance of the transmission data request p1 until the actual input of the transmission data p1 starts is 200 cycles.

[0120] Next, after the transmission data request p1 is issued, the input of the transmission data p1 starts at the timing when the RTC has elapsed (the 450th clock cycle). In the example shown in FIG. 8, since the DTC is 50 cycles, the input of the transmission data p1 is completed at the 500th clock cycle.

[0121] As described with reference to FIG. 8, in order to transfer the transmission data (frame), two memory reads of the descriptor and the transmission data occur. Therefore, the transfer time of the transmission data (for example, the period from when the descriptor request is issued until the input of the transmission data is completed) is RTC * 2 + DTC. In the example shown in FIG. 8, the transfer time of the transmission data is 450 cycles. In actuality, since several clock cycles are required for the input of the descriptor and writing to the descriptor buffer, etc., that amount is added to the transfer time.

[0122] Next, with reference to FIG. 9, an example of the delay that occurs when transmission data of different priorities is sequentially transferred will be described. In FIG. 9, detailed descriptions of the same parts as in FIG. 8 are omitted.

[0123] Note that FIG. 9 shows a series of operations of the data transfer device 30 when transferring transmission data of priorities p1 to p5. In FIG. 8, the descriptor request, descriptor, transmission data request, and transmission data regarding priority p1 were described as descriptor request p1, descriptor p1, transmission data request p1, and transmission data p1, respectively. However, in FIG. 9, the descriptor requests, descriptors, transmission data requests, and transmission data regarding priorities p1 to p5 are referred to as descriptor requests p1 to p5, descriptors p1 to p5, transmission data requests p1 to p5, and transmission data p1 to p5, respectively. Also, here it is assumed that priority p5 is higher than priorities p1 to p4.

[0124] First, as shown in FIG. 9, assume that descriptor requests p1 to p4 are continuously issued. Here, descriptor request p1 is issued at the 30th clock cycle, descriptor request p2 is issued at the 50th clock cycle, descriptor request p3 is issued at the 70th clock cycle, and descriptor request p4 is issued at the 90th clock cycle.

[0125] Here, when descriptor request p1 is issued, in the data transfer device 30, after the above-mentioned RTC has elapsed, the input of descriptor p1 starts, and a transmission data request p1 is issued at the timing when the input of the descriptor p1 is completed. In the example shown in FIG. 9, the transmission data request p1 is issued at the 230th clock cycle.

[0126] On the other hand, when descriptor request p2 is issued, in the data transfer device 30, after the above-mentioned RTC has elapsed, the input of descriptor p2 starts and the input of the descriptor p2 is completed. Here, in the comparative example of the present embodiment, as described in the first embodiment above, after the DTC has elapsed after the transmission data request p1 is issued (that is, when the counter value is 0), the transmission data request p2 is transmitted. In the example shown in FIG. 9, the transmission data request p2 is issued at the 280th clock cycle.

[0127] Although descriptor request p2 (transmission data request p2) has been described here, the same applies to descriptor requests p3 and p4 (transmission data requests p3 and p4). Although detailed description is omitted, in the example shown in FIG. 9, the transmission data request p3 is issued at the 330th clock cycle, and the transmission data request p3 is issued at the 380th clock cycle.

[0128] Here, assume that a high-priority descriptor request p5 is issued at the 200th clock cycle. When the descriptor request p5 is issued in this way, in the data transfer device 30, after the RTC has elapsed, the input of descriptor p5 starts, and when the input of the descriptor p5 is completed, a transmission data request p5 is issued. Note that in FIG. 9, it is assumed that after the above-described RTC has elapsed, the input of descriptor p5 is completed, and the transmission data request p5 is issued at the 400th clock cycle.

[0129] However, at the timing when the transmission data request p5 is issued, other transmission data requests p1 to p4 have already been issued. As shown in FIG. 9, the input of the transmission data p5 based on the transmission data request p5 starts after the inputs (transfers) of the transmission data p1 to p4 are all completed.

[0130] Specifically, according to the example shown in FIG. 9, when the descriptor request p5 is issued at the 200th clock cycle, although the input of the transmission data p5 is completed at the earliest at the 650th clock cycle, the input of the transmission data p5 is completed at the 680th cycle (it takes 480 clock cycles from the issuance of the descriptor request p5 until the input of the transmission data p5 is completed). That is, in the comparative example of the present embodiment, due to the transfer processing of the low-priority transmission data p1 to p4, the delay until the input of the high-priority transmission data p5 is completed becomes large.

[0131] The above-mentioned delay occurs because a transmission data request is issued immediately after the input (reading) of each descriptor is completed. Specifically, the input of the above-mentioned transmission data p5 starts at the earliest at the 600th clock cycle (the timing when the RTC has elapsed since the transmission data request p5 was issued at the 400th clock cycle), but if transmission data requests p1 to p4 are issued between the issuance of the descriptor request p5 and the issuance of the transmission data request p5, it is certain that the input (transfer) of the transmission data p1 to p4 will not be completed by the 600th clock cycle. As a result, the transfer of the high-priority transmission data p5 is delayed due to the influence of the transfer of the low-priority transmission data p1 to p4.

[0132] Therefore, in the present embodiment, a configuration for suppressing the delay in the transfer of high-priority transmission data as described in FIG. 9 above will be described.

[0133] FIG. 10 shows an example of the configuration of the communication device in the present embodiment. In FIG. 10, the same parts as those in FIG. 5 described above are denoted by the same reference numerals and the detailed description thereof is omitted, and mainly the parts different from FIG. 5 will be described.

[0134] As shown in FIG. 10, in the communication device 1 in the present embodiment, the data transfer device 30 includes an RTC measurement unit 38 and a window control unit 39.

[0135] The RTC measurement unit 38 monitors requests (descriptor requests and transmission data requests) to the host-side memory 20 and measures the RTC (the period required from when the request is issued until the input of the descriptor and the transmission data to the data transfer device 30 actually starts). The RTC measurement unit 38 holds the measured RTC (information) internally. Note that the RTC held internally by the RTC measurement unit 38 is the minimum value, maximum value, average value, etc. of the RTC measured each time a request is issued as described above.

[0136] The window control unit 39 holds, for example, a counter value for each channel corresponding to the priority of transmission data (hereinafter referred to as the window value). The window value held by the window control unit 39 is set (determined) based on the RTC held inside the above-described RTC measurement unit 38 (that is, the measurement result by the RTC measurement unit 38). The window control unit 39 determines whether to issue the low-priority transmission data request after the high-priority descriptor request is issued, based on the DTC required for the low-priority transmission data request (that is, the data length of the transmission data input based on the transmission data request) and the window value held by the window control unit 39.

[0137] Here, with reference to FIG. 11, an outline of the window value held by the window control unit 39 will be described.

[0138] In this embodiment, it is assumed that priorities 0 to P are specified for the transmission data. Then, the window control unit 39 holds M + 1 window values 0 to M for each of the priorities 0 to P (corresponding channels). In this embodiment, for example, priority 0 is the lowest priority and priority P is the highest priority. The window values 0 to M held for each of the priorities 0 to P are stored, for example, in a ring buffer corresponding to the priority, and are managed using a write pointer (wr_ptr) and a read pointer (rd_ptr).

[0139] The write pointer is a pointer for indicating the area where the window value is set when a descriptor request is issued. The write pointer is updated so as to advance by one at the timing when the window value is set (that is, to indicate the area where the window value will be set next).

[0140] The read pointer is a pointer for indicating the area where the window value to be read (referenced) is set in order to control the issuance and stop of the transmission data request. The above-mentioned window value is set when a high-priority descriptor request is issued as described later. However, the read pointer is updated so as to advance by one at the timing when the transmission data request is issued based on the descriptor input based on the descriptor request issued when the window value is set (that is, it indicates the area where the next window value is set).

[0141] According to the write pointer (wr_ptr) and the read pointer (rd_ptr) shown in FIG. 11, the valid window values (that is, the window values that have been set but not yet referenced) are hatched.

[0142] Also, in FIG. 11, the m-th (m = 0 to M) window value among the M + 1 window values 0 to M with priority p (p = 0 to P) is represented as win[p][m], and the wr_ptr and rd_ptr for managing the M + 1 window values 0 to M with the priority p are represented as wr_ptr[p] and rd_ptr[p], respectively. The same applies in the following description.

[0143] Hereinafter, with reference to FIG. 12, an example of the operation of the above-described window control unit 39 will be described. Note that the window control unit 39 operates, for example, at the timing when the processes of steps S4 and S5 shown in FIG. 2 described above are executed. Here, the operation of the window control unit 39 regarding the update of the m-th window value (win[p][m]) with priority p will be mainly described.

[0144] First, when the data transfer device 30 (DMAC) is started (initialized), the window control unit 39 sets the maximum value of the window value as win[p][m] (step S21). Note that the maximum value of the window value is 16'hffff in the case of 16 bits, but it is not limited to 16 bits. The win[p][m] with the maximum value of the window value set in this way corresponds to an invalid window value.

[0145] Next, when a descriptor request with a priority higher than priority p is issued and the write pointer (wr_ptr) of the ring buffer with priority p indicates the area where win[p][m] is set, the window control unit 39 sets the RTC held inside the RTC measurement unit 38 as the win[p][m] (step S22). The win[p][m] set in step S22 corresponds to a valid window value.

[0146] Note that the RTC set in step S22 is, for example, the minimum value (RTC_min) of the RTC measured each time a request is issued, but it may be a value obtained by adding or subtracting a constant to / from the minimum value of the RTC. Further, the RTC set in step S22 may be, for example, the X-th RTC from the minimum value of the RTC measured each time a request is issued, or it may be the average value of the RTC. Also, the RTC set in step S22 may be a value obtained by performing a predetermined operation on the RTC measured each time a request is issued.

[0147] The window control unit 39 subtracts the win[p][m] (valid window value) set by the RTC in step S22 for each clock cycle (step S23). Note that the process of step S23 is repeatedly executed until win[p][m] becomes 0, and the win[p][m] becomes 0 at the timing when the RTC_min (number of clock cycles) set in step S23 and the like have elapsed. In other words, the window control unit 39 operates to decrease win[p][m] (that is, the window value) according to the clock cycle. Note that win[p][m] does not become less than 0.

[0148] Note that win[p][m] subtracted for each clock cycle in step S23 as described above is used as the DTC of the requestable transmission data. For this reason, although it is omitted in FIG. 12, for example, when the read pointer (rd_ptr[p]) of the ring buffer corresponding to the priority p indicates the area where win[p][m] is held, the transmission data request of the priority p is issued only when the win[p][m] is larger than the DTC required for the transmission data request.

[0149] While the process of step S23 is repeatedly executed as described above (that is, until win[p][m] becomes 0), when a transmission data request (that is, a transmission data request of a priority higher than the priority p) is issued based on the descriptor input based on the descriptor request of a priority higher than the priority p issued when the win[p][m] is set in step S22 as described above, the window control unit 39 resets the win[p][m]. In this case, the window control unit 39 sets the maximum value of the window value (for example, 16h´ffff) as win[p][m] and invalidates win[p][m] (step S24).

[0150] When the process of step S24 described above is executed, the process returns to step S21 and is repeated.

[0151] In addition, when win[p][m] is invalidated by issuing a transmission data request with a priority higher than the priority p as described above, the read pointer (rd_ptr[p]) of the ring buffer corresponding to the priority p is advanced by one, thereby updating the read destination (reference destination) of the window value in the ring buffer.

[0152] Note that the data transfer device 30 may operate, for example, to request (read) a plurality of descriptors in one descriptor request. In this case, the number of descriptors requested in one descriptor request is held, and step S24 is executed at the timing when a transmission data request is issued based on all of the descriptors, and the read pointer is advanced by one.

[0153] Although the update of win[p][m] has been mainly described with reference to FIG. 12, in the present embodiment, other window values are updated in the same manner. In other words, the window control unit 39 operates to update each of the (P + 1) × (M + 1) window values in parallel.

[0154] Further, when all of the window values 0 to M held for each of the priorities 0 to P in the window control unit 39 are invalidated (that is, all window values are set to the maximum value), the issuance of transmission data requests using the window values is not restricted.

[0155] As described above, the data transfer device 30 according to the present embodiment issues descriptor requests p1 to p4 for requesting descriptors p1 to p4 (first descriptors) in which information regarding transmission data p1 to p4 (first data) is described, as shown in FIG. 13, for example, and issues transmission data requests p1 to p4 (first data requests) based on the input descriptors p1 to p4 when the descriptor requests p1 to p4 are issued.

[0156] Also, the data transfer device 30 according to the present embodiment sets a window value at the timing when the descriptor request p5 (a second descriptor request for requesting a second descriptor in which information regarding the second data is described) is issued after the descriptor requests p1 to p4 are issued, and decreases the window value as the clock cycle elapses.

[0157] Furthermore, when the priorities of the transmission data p1 to p4 are lower than the priority of the transmission data p5 as described above, the data transfer device 30 according to the present embodiment issues each of the transmission data requests p1 to p4 based on the period required from the start to the completion of each input of the transmission data p1 to p4 (that is, the DTC required for each of the transmission data requests p1 to p4) and the window value.

[0158] Specifically, referring to FIG. 13, when the priority of the transmission data p5 is 2 and the priorities of the transmission data p1 to p4 are 0 or 1, the RTC held inside the RTC measurement unit 38 is set to the window values (win[0][(wr_ptr[0])], win[1][(wr_ptr[1])]) set in the area indicated by the write pointers of the ring buffers corresponding to priorities 0 and 1 at the time of issuing the descriptor request p5.

[0159] When the RTC is set to win[0][(wr_ptr[0])] and win[1][(wr_ptr[1])] in this way, the write destination of the window value in the ring buffer is updated by advancing each of the wr_ptr[0] and wr_ptr[1] (that is, the write pointers of the ring buffers corresponding to priorities 0 and 1) by one.

[0160] Although not shown in FIG. 13, for example, descriptor requests with the same priority as the transmission data p5 (or a higher priority than the transmission data p5) may be continuously issued following the descriptor request p5. In the present embodiment, the window value is set each time such a descriptor request is issued. Therefore, in the present embodiment, a configuration is adopted in which M + 1 window values can be set for each of priorities 0 to P.

[0161] Here, assume that RTC = 200 cycles is set for the above-mentioned win[0][(wr_ptr[0])] and win[1][(wr_ptr[1])]. The win[0][(wr_ptr[0])] and win[1][(wr_ptr[1])] with 200 cycles set in this way are subtracted as the clock cycles elapse.

[0162] Also, assume that the window value with RTC = 200 cycles set as described above is indicated by the read pointers (rd_ptr[0], rd_ptr[1]). In this case, in the example shown in FIG. 13, the window values (win[0][(rd_ptr[0])], win[1][(rd_ptr[1])]) at the 230th clock cycle when the transmission data request p1 is transmitted are 200 - 30 = 170, and the DTC required for the transmission data request p1 is 50. In this case, since the window value is larger than the DTC required for the transmission data request p1, the issuance of the transmission data request p1 is not stopped (that is, the transmission data request p1 is issued).

[0163] Although the transmission data request p1 has been described here, the window value at the 280th clock cycle when the transmission data request p2 is transmitted is 170 - 50 = 120, and the DTC required for the transmission data request p2 is 50. In this case, since the window value is larger than the DTC required for the transmission data request p2, the issuance of the transmission data request p2 is not stopped.

[0164] Similarly, the window value at the 330th clock cycle when the transmission data request p3 is transmitted is 120 - 50 = 80, and the DTC required for the transmission data request p3 is 50. In this case, since the window value is larger than the DTC required for the transmission data request p3, the issuance of the transmission data request p3 is not stopped.

[0165] On the other hand, the window value at the 380th clock cycle when the transmission data request p4 is transmitted is 80 - 50 = 30, and the DTC required for the transmission data request p4 is 50. In this case, since the window value is smaller than the DTC required for the transmission data request p4, the issuance of the transmission data request p4 is stopped.

[0166] According to this, when the transmission data request p5 is issued without delay at the 400th clock cycle when the issuance of the transmission data request p5 becomes possible, the input of the transmission data p5 can be completed at the 650th clock cycle. Therefore, compared with the case described in FIG. 9, low delay in the transfer of the high-priority transmission data p5 can be realized.

[0167] In the present embodiment, as described above, when the window value is managed and a low-priority transmission data request occurs, the issuance of a transmission data request with a DTC larger than the window value (win[p][rd_ptr]) held in the area indicated by the read pointer of the ring buffer corresponding to the low priority is stopped, thereby making it possible to prevent a delay in the transfer of high-priority transmission data.

[0168] In other words, if the DTC required for the low-priority transmission data request does not exceed the window value, the input of the low-priority transmission data can be completed before the input of the transmission data is started based on the high-priority transmission data request. Therefore, the transfer of the low-priority transmission data does not cause a delay in the transfer of the high-priority transmission data.

[0169] Incidentally, although the data transfer device 30 according to the present embodiment has been described as having an RTC measurement unit 38 and a window control unit 39 added to the data transfer device 30 according to the first embodiment described above, for example, the DTC delay control unit 37 described in the first embodiment may be omitted.

[0170] However, in the case of a configuration in which the DTC delay control unit 37 is omitted, there is a possibility that the delay described in the first embodiment described above may occur.

[0171] Therefore, in the case of a configuration in which the DTC delay control unit 37 is omitted, the window control unit 39 may operate as shown in FIG. 14 below. In FIG. 14, only the parts different from FIG. 12 described above will be described.

[0172] In the example shown in FIG. 14, the window control unit 39 executes the processes of steps S31 to S34 corresponding to the processes of steps S21 to S24 shown in FIG. 12 described above, and in addition to the processes, executes the process of step S35.

[0173] Specifically, in the example shown in FIG. 12, the window control unit 39 simply subtracts win[p][m] for each clock cycle (decreases according to the clock cycle), but in step S35 shown in FIG. 14, when the transmission data request of the priority equal to or lower than the priority p is issued because the window value is larger than the DTC (DTC calculated from the data length of the transmission data required by the transmission data request), the window control unit 39 subtracts the DTC from the window value, waits until the number of clock cycles corresponding to the DTC elapses, and then returns to step S33 (that is, resumes the decrease of the window value after the number of clock cycles elapses). Note that since the transmission data request of the priority equal to or lower than the priority p is issued when the window value is larger than the DTC required by the transmission data request, the window value will not become smaller than 0 even if the process of step S35 is executed.

[0174] According to the operation of the window control unit 39 shown in FIG. 14, when a low-priority transmission data request is issued, the window value is greatly consumed based on the DTC required by the transmission data request. Therefore, for example, until the number of clock cycles corresponding to the DTC elapses (that is, while the window value is decreasing), it is possible to avoid the situation where a low-priority transmission data request is further issued, and an effect equivalent to the configuration including the above-described DTC delay control unit 37 can be obtained.

[0175] According to the data transfer device 30 according to the above-described embodiment, by using the window value set at the timing when a high-priority descriptor request is issued, the issuance of a low-priority transmission data request after the high-priority descriptor request is restricted, thereby suppressing the transfer process of low-priority transmission data from affecting the transfer process of high-priority transmission data (that is, reducing the transfer delay for high-priority transmission data).

[0176] Note that the data transfer device 30 according to the present embodiment may be configured to set attributes for each of the queues Q0 to QN described in the above-described first embodiment and control whether to stop issuing a transmission data request for each attribute.

[0177] As described in the above-described first embodiment, for example, in the case of IEEE 802.1Qbu / 803.3br, since the MAC of the queue connection destination is classified into attributes such as Preemptable and Express, it is conceivable to stop only the issuance of a transmission data request for the transmission data stored in the queue connected to Preemptable, which does not require transmission with relatively low latency.

[0178] Note that in order to realize such a configuration, it is only necessary to hold the attribute discrimination table described in the above-described first embodiment inside the data transfer device 30.

[0179] Also, in this embodiment, it has been described that the RTC (number of clock cycles) is set as the window value and the window value is subtracted for each clock cycle (that is, decreased according to the passage of clock cycles). However, the data length (data size) may be set as the window value. In this case, the window value may be subtracted by the data length (that is, the bus width) that can be transmitted (transferred) per clock cycle between the host-side memory 20 and the data transfer device 30.

[0180] Although detailed description is omitted, the time described in the first embodiment may be set as the window value in this embodiment.

[0181] (Third Embodiment) Next, the third embodiment will be described. This embodiment is different from the first and second embodiments in that it assumes a specific implementation example when TSN is applied to the communication device (data transfer device) described in the above-described first and second embodiments.

[0182] FIG. 15 shows an example of the configuration of the communication device in this embodiment. In FIG. 15, the same reference numerals are given to the same parts as those in FIGS. 5 and 10 described above, and the detailed description thereof is omitted, and mainly the parts different from FIGS. 5 and 10 will be described.

[0183] In this embodiment, a2b represents the process of transmitting data from the host device to an external device via the data transfer device 30, and b2a represents the process of the host device receiving data from the external device via the data transfer device 30.

[0184] The host device shown in FIG. 15 includes the CPU 10 and the host-side memory 20 shown in FIGS. 5 and 10. Although not shown in FIG. 15, the host-side memory 20 is provided with an a2b data area, an a2b descriptor area, a b2a data area, and a b2a descriptor area. The a2b data area and the a2b descriptor area correspond to the transmission data area 20a and the descriptor area 20b shown in FIGS. 5 and 10 described above. The b2a data area is an area where data (received data) related to b2a is written, and the b2a descriptor area is an area where a descriptor in which information related to the received data is described is written.

[0185] Also, in the present embodiment, the host interface 31 has an a2b queue q0 to qN register area in which descriptor information including a pointer indicating the position of the a2b descriptor area in which a descriptor is written is stored, and a b2a queue q0 to qL register area in which descriptor information including a pointer indicating the position of the b2a descriptor area in which a descriptor is written is stored.

[0186] The a2b descriptor read request generation unit 301 generates a descriptor read request (a request including an address, a data length, etc.) necessary for accessing the host-side memory 20 based on the descriptor information stored in the a2b queue q0 to qN register area included in the host interface 31. Note that the a2b descriptor read request generation unit 301 has descriptor read request generation units #0 to #N corresponding to the above-described priorities (traffic classes).

[0187] The b2a descriptor read request generation unit 302 generates a descriptor read request (a request including an address and a data length) necessary for accessing the host-side memory 20 based on the descriptor information stored in the plurality of b2a queue q0 to qL register areas included in the host interface 31. Note that the b2a descriptor read request generation unit 302 has descriptor read request generation units #0 to #L corresponding to the priorities (traffic classes).

[0188] The functional units related to a2b, such as the a2b descriptor read request generation unit 301 described above, have functional units #0 to #N corresponding to priorities, and the functional units related to b2a, such as the b2a descriptor read request generation unit 302, have functional units #0 to #L corresponding to priorities. However, in this embodiment, N and L may be the same numerical value or different numerical values.

[0189] The a2b descriptor buffer 303 corresponds to the descriptor buffer 34 described in the first and second embodiments above, and has a2b queues q0 to qN corresponding to priorities. In the a2b queues q0 to qN, descriptors read from the host-side memory 20 (a2b descriptor area) based on the descriptor read requests generated by the a2b descriptor read request generation unit 301 are stored.

[0190] The a2b data read request generation unit 304 generates a data read request (a request including an address and a data length) necessary for accessing the host-side memory 20 based on the descriptors stored in the a2b descriptor buffer 303. Note that the a2b data read request generation unit 304 has data read request generation units #0 to #N corresponding to the priorities described above.

[0191] The first interface read request selection unit 305 selects the requests generated by the a2b descriptor read request generation unit 301, the b2a descriptor read request generation unit 302, and the a2b data read request generation unit 304 according to the instructions from the DTC delay control unit 37 and the window control unit 39 and Strict Priority described in the first and second embodiments above, and transfers the selected requests to the first interface read processing unit 306.

[0192] The first interface read processing unit 306 accesses the host-side memory 20 based on the request passed from the first interface read request selection unit 305, and inputs a response to the request. Note that the access to the host-side memory 20 by the first interface read processing unit 306 is performed according to a predetermined protocol such as AXI4 or the like.

[0193] When the request passed from the first interface read request selection unit 305 is, for example, a descriptor read request generated by the a2b descriptor read request generation unit 301, the first interface read processing unit 306 inputs the descriptor read from the host-side memory 20 (a2b descriptor area) based on the descriptor read request, and passes the descriptor to the read response distribution unit 307.

[0194] When the request passed from the first interface read request selection unit 305 is, for example, a descriptor read request generated by the b2a descriptor read request generation unit 302, the first interface read processing unit 306 inputs the descriptor read from the host-side memory 20 (b2a descriptor area) based on the descriptor read request, and passes the descriptor to the read response distribution unit 307.

[0195] When the request passed from the first interface read request selection unit 305 is, for example, a data read request generated by the a2b data read request generation unit 304, the first interface read processing unit 306 inputs the transmission data read from the host-side memory (a2b data area) based on the data read request, and passes the transmission data to the read response distribution unit 307.

[0196] The read response distribution unit 307 distributes the response (read) input from the host-side memory 20 by the first interface read processing unit 306.

[0197] The read response distribution unit 307 distributes the descriptor input from the a2b descriptor area to the a2b descriptor buffer 303. As a result, the descriptor input from the a2b descriptor area is stored in the a2b descriptor buffer 303.

[0198] The read response distribution unit 307 distributes the descriptor input from the b2a descriptor area to the b2a descriptor buffer 308. As a result, the descriptor input from the b2a descriptor area is stored in the b2a descriptor buffer 308. Note that the b2a descriptor buffer 308 has b2a queues q0 to qL corresponding to priorities (traffic classes).

[0199] The read response distribution unit 307 distributes the transmission data input from the a2b data area to the second interface write processing unit 309. As a result, the transmission data input from the a2b data area is output from the second interface write processing unit 309 to the transmission queue 401 and written to the transmission queue 401. Note that the second interface write processing unit 309 has write processing units #0 to #N corresponding to priorities (traffic classes).

[0200] Note that the information for the read response distribution unit 307 to distribute the response from the host-side memory 20 is acquired from the first interface read processing unit 306. Note that as the information for distributing the response, for example, the order of issue of the request and protocol information (response ID) for accessing the host-side memory 20 are used.

[0201] The transmission queue 401 corresponds to the NIC transmission memory 40 of the first and second embodiments described above and has queues #0 to #N corresponding to priorities (traffic classes).

[0202] The 802.1Qbv processing unit 402 executes the processing of IEEE 802.1Qbv. Specifically, the 802.1Qbv processing unit 402 holds the gate control information of IEEE 802.1Qbv and includes a gate driver. The gate control information is information in which the opening and closing of the gates of the transmission queues 401 (queues #0 to #N) in which transmission data is stored according to the priority (traffic class) are set. The gate driver controls the opening and closing processing of the gates of the transmission queues 401 (queues #0 to #N) at the timing set in the gate control information. Thereby, it becomes possible to control the transmission timing of each traffic class at the scheduled timing.

[0203] The communication processing unit (802.1Qbu / 802.13br processing unit) 403 executes MAC (Media Access Control) processing including the processing of IEEE 802.1Qbu / IEEE 802.3br. Specifically, in the case of transmission processing, when transmission data (Express) is stored in the eMAC transmission queue (not shown) while the transmission processing unit of pMAC (preemptable Media Access Control) 403a is transmitting the transmission data (Preemptable) stored in the pMAC transmission queue (not shown) by the 802.1Qbv processing unit, the communication processing unit 403 stops the processing of pMAC 403a and interrupts the transmission processing of eMAC (express Media Access Control) 403b. When the transmission processing of eMAC 403b is completed, the communication processing unit 403 resumes the transmission processing of pMAC 403a. Thereby, it becomes possible to transmit high-priority transmission data with low latency.

[0204] Note that the communication device shown in FIG. 15 shows a specific implementation example to which TSN is applied. For example, the first interface read request selection unit 305, the first interface read processing unit 306, and the read response distribution unit 307 shown in FIG. 15 correspond to the first interface unit 32 shown in FIGS. 5 and 10. Also, the a2b descriptor read request generation unit 301 shown in FIG. 15 corresponds to the descriptor read unit 33 shown in FIGS. 5 and 10. That is, the descriptor read request generated by the a2b descriptor read request generation unit 301 corresponds to the descriptor request described in the first and second embodiments described above. Further, the a2b descriptor buffer 303 shown in FIG. 15 corresponds to the descriptor buffer 34 shown in FIGS. 5 and 10. Also, the a2b data read request generation unit 304 shown in FIG. 15 corresponds to the transmission data read unit 35 shown in FIGS. 5 and 10. That is, the data read request generated by the a2b data read request generation unit 304 corresponds to the transmission data request described in the first and second embodiments described above. Further, the second interface write processing unit 309 shown in FIG. 15 corresponds to the second interface unit 36 shown in FIGS. 5 and 10. Also, the transmission queue 401 shown in FIG. 15 corresponds to the NIC transmission memory 40 shown in FIGS. 5 and 10, and the 802.1Qbv processing unit 402 and the communication processing unit 403 operate as part of the NIC.

[0205] On the other hand, the data transfer device 30 provided in the communication device 1 according to the present embodiment includes the DTC delay control unit 37, the RTC measurement unit 38, and the window control unit 39 described in the first and second embodiments described above. In addition to these units 37 to 39, it further includes a gate state confirmation unit 310.

[0206] The gate state confirmation unit 310 confirms the open / closed state of the gate of the queue in which the transmission data is stored during a predetermined period after the transmission data is output to the transmission queue 401, based on the gate control information held in the 802.1Qbv processing unit 402, the RTC held inside the RTC measurement unit 38 (that is, the measurement result by the RTC measurement unit 38), and the maximum value of the data length transferred by the data transfer device 30 (the maximum data length of the transmission data).

[0207] Note that in this embodiment, the DTC delay control unit 37, the RTC measurement unit 38, and the window control unit 39 operate as described in the above-described first and second embodiments. However, the window value in this embodiment is set (determined) based on the confirmation result by the above-described gate state confirmation unit 310.

[0208] By the way, in the above-described first and second embodiments, the functional units mainly related to data transmission were described. However, in the communication device 1 shown in FIG. 15, the functional units related to data reception are further shown. Hereinafter, the functional units related to data reception will be briefly described.

[0209] The received frame distribution processing unit 404 distributes the data received by the communication processing unit 403 (hereinafter referred to as received data) to queues #0 to #L of the reception queue 405. Note that the plurality of queues #0 to #L of the reception queue 405 correspond to priorities (traffic classes).

[0210] The second interface read processing unit 311 accesses the reception queue 405 and inputs (reads) the received data stored in the reception queue 405. Note that the access to the reception queue 405 by the second interface read processing unit 311 is performed according to a predetermined protocol such as AXI4. The second interface read processing unit 311 determines that an area (reception buffer) is secured in the host-side memory 20 when a descriptor (write destination descriptor) exists in the b2a descriptor buffer 308, and reads (inputs) the received data.

[0211] Based on the descriptors stored in the b2a descriptor buffer and the received data input by the second interface reading processing unit 311, the b2a data write request generation unit 312 generates a data write request (a request including an address and a data length) necessary for accessing the host-side memory 20. Note that the b2a data write request generation unit 312 includes data write request generation units #0 to #L corresponding to priorities (traffic classes).

[0212] The a2b descriptor write request generation unit 313 generates a descriptor write request (a request including an address and a data length) for rewriting a descriptor on the host-side memory 20 (a2b descriptor area) (for example, setting a completion flag) in order to notify that transmission data has been output from the second interface writing processing unit 309 (that is, the transmission of the transmission data is completed). Note that the a2b descriptor write request generation unit 313 includes a plurality of descriptor write request generation units #0 to #N corresponding to priorities (traffic classes).

[0213] Based on the fact that a received frame has been input by the second interface reading processing unit 311 (that is, the reception of the received frame is completed), the b2a descriptor write request processing unit 314 generates a descriptor write request (a request including an address and a data length) for rewriting a descriptor on the host-side memory 20 (b2a descriptor area) (for example, setting a completion flag). Note that the b2a descriptor write request processing unit 314 includes descriptor write request processing units #0 to #L corresponding to priorities (traffic classes).

[0214] The first interface write request selection unit 315 selects requests generated by the b2a data write request generation unit 312, the a2b descriptor write request generation unit 313, and the b2a descriptor write request processing unit 314 according to, for example, Strict Priority, etc., and transfers the selected requests to the first interface write processing unit 316.

[0215] The first interface write processing unit 316 accesses the host-side memory 20 based on the request transferred from the first interface write request selection unit 315, and writes the descriptor and received data based on the request. Note that the access to the host-side memory 20 by the first interface write processing unit 316 is performed according to a predetermined protocol such as AXI4.

[0216] Here, with reference to FIGS. 16 and 17, an example of the operations of the window control unit 39 and the gate state confirmation unit 310 in the present embodiment will be described. FIGS. 16 and 17 show a series of operations of the data transfer device 30 when transferring transmission data with priorities p1 to p5, similar to FIGS. 9 and 13 described above.

[0217] As described in the second embodiment above, when the descriptor request (descriptor read request) p5 is issued after the descriptor requests (descriptor read requests) p1 to p4 are issued in the data transfer device 30, and the priority p5 is higher than the priorities p1 to p4, the window value is set at the timing when the descriptor request p5 is issued. According to this, as shown in FIG. 16, the input of the transmission data p5 to the data transfer device 30 starts at the 600th clock cycle and is completed at the 650th clock cycle. The transmission data p5 thus input to the data transfer device 30 is stored in the transmission queue 401, and the transfer of the transmission data p5 from the host-side memory 20 to the transmission queue 401 is completed.

[0218] However, in the present embodiment, since the opening and closing of the gates of the transmission queues 401 (queues #0 to #N) are controlled at the timing set in the gate control information as described above, even if the transfer of the transmission data p5 is completed as described above, if the gate corresponding to the priority (traffic class) of the transmission data p5 (hereinafter referred to as the gate of the transmission data p5) is not open (in an open state), the transmission data p5 cannot be immediately transmitted. For this reason, depending on the opening and closing status of the gates, even if the transfer of the transmission data request p4 is delayed as shown in FIG. 13, the 802.1Qbv processing unit 402 cannot immediately process the transmission data p5, and the delay processing of p4 becomes wasted.

[0219] Therefore, in the present embodiment, the window value set when the descriptor request p5 is issued is determined in consideration of the above-described gate control information.

[0220] Specifically, the gate state confirmation unit 310 refers to the gate control information at the timing when the descriptor request p5 is issued, and the shortest transfer start timing of the transmission data p5 at which RTC*2 held inside the RTC measurement unit 38 has elapsed since the issuance of the descriptor request p5 (that is, the timing at which the input of the transmission data p5 to the data transfer device 30 and the transfer to the transmission queue 401 are started shortest) to confirm whether the gate of the transmission data p5 is open.

[0221] If the gate of the transmission data p5 at the above-described transfer start timing of the transmission data p5 is open, the gate state confirmation unit 310 confirms whether the gate remains open continuously during the period in which the transmission process of the transmission data p5 can be completed from the shortest transfer start timing.

[0222] By the way, since the descriptor p5 of the transmission data p5 is not input at the timing when the descriptor request p5 is issued as described above, the data transfer device 30 cannot grasp the exact data length of the transmission data p5 (that is, cannot grasp the period required for the transmission process of the transmission data p5).

[0223] In this case, in the present embodiment, if the gate of the transmission data p5 is open during the period of DTC_max * 2 from the shortest transfer start timing of the transmission data p5 (the 600th clock cycle shown in FIG. 16), it is considered that the transmission process of the transmission data p5 can be completed. Note that DTC_max corresponds to the DTC calculated from the maximum value of the data length transferred by the data transfer device 30 and the bus width.

[0224] Therefore, the gate state confirmation unit 310 checks whether the gate of the transmission data p5 is open during the period of DTC_max * 2 from the shortest transfer start timing of the transmission data p5 (the 600th clock cycle shown in FIG. 16).

[0225] According to this, as shown in FIG. 16, when the gate state confirmation unit 310 confirms that the gate of the transmission data p5 is open during the period of DTC_max * 2 from the shortest transfer start timing, it can be seen that the transmission data p5 can be transmitted without delay by starting the transfer of the transmission data p5 at the 600th clock cycle. In this case, the window control unit 39 sets the RTC held inside the RTC measurement unit 38 as the window value as described in the second embodiment above.

[0226] On the one hand, as shown in FIG. 17, when the gate control information unit 310 confirms that the gate of the transmission data p5 at the shortest transfer start timing is not open (the gate is not open during the period of DTC_max*2 from the shortest transfer start timing), even if the transfer of the transmission data p5 starts at the 600th clock cycle, it can be seen that the transmission data p5 cannot be transmitted because the gate of the transmission data p5 is closed. In this case, the gate control information unit 310 refers to the gate control information and checks C_nextopen corresponding to the period (number of clock cycles) from the shortest transfer timing until the gate of the next transmission data p5 opens. The window control unit 39 sets, as the window value, the value calculated from the RTC held inside the RTC measurement unit 38, the C_nextopen, and the DTC_max. Specifically, the value obtained by subtracting DTC_max from C_nextopen is set as the window correction value G. When G is 0 or more, RTC+G is set as the window value, and when G is less than 0, RTC is set as the window value. Although not shown in FIG. 17, according to such a window value, it becomes possible to issue a transmission data request (data read request) so that the transmission of the transmission data p5 starts at the timing when the gate opens next.

[0227] As described above, the data transfer device 30 according to the present embodiment checks the open / close state of the gate during a predetermined period (for example, DTC_max*2) from the shortest transfer start timing (the shortest timing at which the second data is output to the second memory) based on the gate control information, the RTC (that is, the measurement result) held inside the RTC measurement unit 38, and the DTC_max (the maximum value of the data length to be transferred), and sets the window value based on the confirmation result.

[0228] In this embodiment, by setting the window value in consideration of the gate control information as described above, for example, in the transmission process of the subsequent stage (i.e., NIC) of the data transfer device 30, it is possible to avoid a situation where the issuance of low-priority transmission data requests is stopped for high-priority transmission data that causes delays, and it becomes possible to realize an efficient transfer process of transmission data.

[0229] In addition, in this embodiment, although it has been described that DTC_max is used when checking the opening and closing state of the gate in a predetermined period from the transfer start timing, this embodiment only needs to be configured to check the opening and closing state of the gate in a period during which it is estimated that the transmission of the transmission data can be completed, and the opening and closing state of the gate in a period different from the period of DTC_max * 2 may be checked.

[0230] Also, as another configuration of the gate state confirmation unit 310, based on the gate control information held in the 802.1Qbv processing unit 402, the RTC held inside the RTC measurement unit 38 (that is, the measurement result by the RTC measurement unit 38), and the maximum value of the data length transferred by the data transfer device 30 (the maximum data length of the transmission data. It may be set individually for each priority), a configuration may be adopted in which the window correction values G0 to GP for each priority 0 to P are always calculated. The calculation formulas for each of G0 to GP are the same as the method described above. In this case, the window control unit 39 sets, as the window value, the value obtained by adding Gp (p = 0 to P) of the corresponding priority and the RTC when setting the above-described window value.

[0231] Also, the gate state confirmation unit 310 may hold inside information equivalent to the gate control information held in the 802.1Qbv processing unit 402. In this case, the gate state confirmation unit 310 always refers to the state of the gate that is RTC * 2 in the future compared to the time referred to by the 802.1Qbv processing unit 402.

[0232] According to at least one of the embodiments described above, it is possible to provide a data transfer device and method capable of realizing low latency in communication.

[0233] (System configuration example) FIG. 18 is a diagram showing a configuration example of a system using the communication device 1 in each of the above-described embodiments. FIG. 18 shows an example of controlling the on-site belt conveyor 601 and the robot arms 602a and 602b from the edge server 700 via the 5G (5th Generation) / Local 5G system 500 in a factory or a plant.

[0234] The 5G / Local 5G system 500 includes a 5G core network 505, a central unit 504, a distributed unit 503, a remote unit 502, and user equipment 501. The 5G / Local 5G system 500 performs 5G communication defined by the standards of the 3GPP (3rd Generation Partnership Project) (registered trademark).

[0235] The communication device 1 in each embodiment can be implemented, for example, in the edge server 700 and the 5G core network 505. Thereby, the real-time performance of communication between the edge server 700 and the 5G core network 505 can be improved.

[0236] Further, the communication device 1 in each embodiment may be used for communication between each part in the 5G / Local 5G system 500. That is, in order to perform communication between the remote unit 502, the distributed unit 503, the central unit 504, and the 5G core network 505, the communication device 1 in each embodiment may be implemented in at least a part of the remote unit 502, the distributed unit 503, the central unit 504, and the 5G core network 505.

[0237] The communication device 1 in each embodiment may be used for communication between at least one of the belt conveyor 601 and the robot arms 602a and 602b and the user equipment 501, or for communication between the belt conveyor 601 and the robot arms 602a and 602b.

[0238] The system to which the communication device 1 in each embodiment is applicable is not limited to this, and any system may be used. For example, it can also be applied to industrial network systems in factories or plants that do not use 5G / local 5G, network systems inside automobiles and aircraft, and the like.

[0239] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, as well as in the invention described in the claims and its equivalent scope.

Description of Reference Numerals

[0240] 1…Communication device, 10…CPU, 10a…Driver, 20…Memory, 30…Data transfer device, 31…Host interface, 32…First interface section, 33…Descriptor reading section, 34…Descriptor buffer, 35…Transmission data reading section, 36…Second interface section, 37…DTC delay control section, 38…RTC measurement section, 39…Window control section, 40…Memory, 301…a2b descriptor read request generation section, 302…b2a descriptor read request generation section, 303…a2b descriptor buffer, 304…a2b data read request generation section, 305…First interface read request selection section, 306…First interface read processing section, 307…Read response distribution section, 308…b2a descriptor buffer, 309…Second interface write processing section, 310…Gate state confirmation section, 311…Second interface read processing section, 312…b2a data write request generation section, 313…a2b descriptor write request generation section, 314…b2a descriptor write request processing section, 315…First interface write request selection section, 316…First interface write processing section, 401…Transmission queue, 402…802.1Qbv processing section, 403…Communication processing section, 404…Received frame distribution processing section, 405…Received queue.

Claims

1. In a data transfer device that sequentially transfers data with a specified priority, issuing means for issuing a first request for transferring first data via a first interface; control means for stopping the issuance of a second request for transferring second data after the first data until a period required from the start of input of a response to the first request via the first interface until the input is completed has elapsed; A data transfer device comprising:

2. When the stop of the issuance of the second request is released, the issuing means issues the second or third request based on the priorities specified for the second and third data if it is possible to issue a third request for transferring third data after the second data. The data transfer device according to claim 1.

3. The data transfer device according to claim 2, wherein the first to third requests are requests for requesting the first to third data.

4. The data transfer device according to claim 2, wherein the first to third requests are requests for requesting first to third descriptors in which information regarding the first to third data is described.

5. The data transfer device according to claim 1, wherein the control means stops the issuance of the second request when the priority specified for the second data is lower than a predetermined priority.

6. Connected to a first memory via the first interface, The first data is input from the first memory via the first interface and output to a second memory different from the first memory via a second interface different from the first interface. The data transfer device according to claim 1.

7. The data transfer device according to claim 6, wherein the first data output to the second memory is transmitted via a network device for connecting to a network.

8. In a data transfer device that sequentially transfers data with a specified priority, first issuing means for issuing a first descriptor request for requesting a first descriptor in which information about first data is described; second issuing means for issuing a first data request for requesting the first data based on the first descriptor input by issuing the first descriptor request; first control means for setting a window value at a timing when a second descriptor request for requesting a second descriptor in which information about second data having a higher priority than the first data is described is issued, and decreasing the window value according to the elapse of clock cycles or time; comprising: The second issuing means issues the first data request based on a period required from the start to the completion of the input of the first data and the window value. Data transfer device.

9. When the first descriptor request is issued, the issuance of the second descriptor request is stopped until a period required from the start to the completion of the input of the first descriptor elapses, or when the first data request is issued, the issuance of the second data request for requesting the second data is stopped until a period required from the start to the completion of the input of the first data elapses. The data transfer device according to claim 8, further comprising second control means.

10. The first control means according to claim 8, wherein when the first data request is issued, subtracts a period required from the start to the completion of the input of the first data from the window value, and resumes the decrease of the window value after the period has elapsed.

11. A measuring means for measuring a period from when a third descriptor request issued before the first descriptor request is issued until the input of the third descriptor requested by the third descriptor request starts, or a period from when a third data request issued before the first data request is issued until the input of the third data requested by the third data request starts is further provided. The window value is determined based on the measurement result. The data transfer device according to claim 8.

12. It is connected to a first memory via a first interface. The first data is input from the first memory via the first interface and output to a second memory different from the first memory via a second interface different from the first interface. The data transfer device according to claim 11.

13. The data transfer device according to claim 12, wherein the first data output to the second memory is transmitted via a network device for connecting to a network.

14. The network device complies with IEEE802.1Qbu / 3br. The second issuing means issues the first data request based on the window value only when the first data is a Preemptable frame in IEEE802.1Qbu / 3br. The data transfer device according to claim 13.

15. It further includes a confirmation means. The second memory has a plurality of queues. The network device includes a processing means for controlling the transmission timing of the data based on gate control information in which the opening and closing of the gate of the queue in which the data is stored is set based on the priority specified for the data transmitted from the network device. The confirmation means confirms the opening / closing state of the gate of the queue in which the second data is stored during the period after the second data is output to the second memory, based on the gate control information, the measurement result, and the maximum value of the data length to be transferred. The window value is set based on the confirmation result. The data transfer device according to claim 13.

16. In a method executed by a data transfer device that sequentially transfers data with specified priorities, issuing a first request for transferring first data via a first interface; when the first request is issued, stopping the issuance of a second request for transferring second data that is after the first data until the period required from the start of the input of the response to the first request via the first interface until the input is completed has elapsed. A method comprising the steps of:

17. In a method executed by a data transfer device that sequentially transfers data with specified priorities, issuing a first descriptor request for requesting a first descriptor in which information about first data is described; issuing a first data request for requesting the first data based on the first descriptor input by issuing the first descriptor request; setting a window value at the timing when a second descriptor request for requesting a second descriptor in which information about second data having a higher priority than the first data is described is issued, and decreasing the window value according to the elapse of clock cycles or time; comprising: The step of issuing the first data request includes the step of issuing the first data request based on the period required from the start of the input of the first data until the input is completed and the window value. A method.

Images