System, method and device for data communication and storage medium

[Technical field to which the invention belongs] The present invention<u style="single">It has a source node that transmits the transmitted data and a destination node that receives the transmitted data.</u>Data communication system<u style="single">To</u>Seki<u style="single">To do</u>。

[0002] [Conventional Technology] Among personal computer peripheral devices, hard disks and printers are most frequently used, and these peripheral devices are typical digital interfaces for general-purpose interfaces for small computers (hereinafter referred to as Digital I). A connection is made between computers using SCSI, etc., which is / F), and data communication is performed.

[0003] Further, a recording / playback device such as a digital camera or a digital video camera is also one of peripheral devices as an input means to a personal computer (hereinafter, PC), and in recent years, still images and moving images taken by a digital camera or a video camera. The number of users is increasing as technology in the field of capturing images such as these on a PC, storing them on a hard disk, or editing them on a PC and then printing them in color with a printer is advancing.

[0004] When the captured image data is output from a PC to a printer or a hard disk, data communication is performed via the above SCSI or the like, and in such a case, the amount of data is large like the image data. In order to send information, these digital I / Fs need to have a high transfer data rate and are versatile.

[0005] AV devices such as digital VTRs, TVs, and tuners, personal computers (hereinafter referred to as PCs), and the like are connected to each other using an IEEE1394 serial bus (hereinafter referred to as 1394), and digital video is connected between them. Communication systems for transmitting and receiving signals, digital audio signals, etc. have been proposed. The system is known as the IEEE1394 Standard for High Performance Serial Bus standard.

[0006] In the above 1394 standard, asynchronous data transfer and synchronous data transfer are defined. Asynchronous data transfer provides a packet transfer protocol that sends a variable-length data packet to a specified address and returns a recognition packet (acknowledge packet). Further, in synchronous data transfer (hereinafter referred to as isochronous), a packet transfer protocol for transferring a variable length packet at a fixed time interval is provided.

[0007] In the asynchronous data transfer of the 1394 standard, when an arbitrary node cannot handle a packet due to a large number of processes, a response notifying that fact is returned in the return packet. A retry procedure is defined.

[0008] In the above retry procedure, a code for retrying may be added to an arbitrary return packet notifying that a request packet or a response packet has been received. The state transition diagram shown in FIG. 10 shows an example of the behavior when the receiving node in 1394 processes a packet received from another node.

[0009] When the node of FIG. 10 receives an Initialize or Reset control request from the node controller, it transitions from any state other than the ISR0 state to the ISR0 state. In the ISR0 state, the use of communication resources is permitted, and the node waits for receiving the first packet from another node. When an asynchronous (hereinafter referred to as asynchronous) packet is received in the ISR0 state, the node returns response data indicating reception with an appropriate value.

[0010] When the communication resource is not available, the node transitions from the ISR state to the ISR1 state. At this time, the node is said to be in a busy state. In this case, the node is in a state where it cannot accept the first packet from another node. When an asynchronous packet is received in the ISR1 state, the node returns the received response data of ack _busy_X. If the use of communication resources is permitted in the ISR1 state, the node transitions to the ISR0 state and is no longer in the busy state.

The state transition diagram shown in FIG. 11 shows an example of the behavior when the transmitting node in 1394 receives a busy after transmitting a main packet to another node. Further, when the node shown in FIG. 11 receives the transaction control packet of Initialize or Reset from the node controller, the node transitions from another state to the OSR0 state.

[0012] At this time, the node is ready to send a packet to another node. If the node receives a packet other than ack _busy_A, ack _busy_B, and ack _busy_X in the OSR0 state, the node sends the packet and does not need to retry. When the node receives the packets of ack _busy_A, ack _busy_B, and ack _busy_X in the OSR0 state, it recognizes that the receiving node is in the busy state. In this case, the node transitions to the OSR1 state because a retry is required.

[0013] In the OSR1 state, the node has a pending retry that must be resolved and must resolve the retry before sending any other packet. At this time, the node specifies the retry code in retry _X and performs a retry. In the OSR1 state, the pending retry packets that do not exceed the so-called retry limit, which is the upper limit of the number of retries by the node, are put into the so-called retry queue, which is the queue of retry packets. If not, the node remains in the OSR1 state.

[0014] In the OSR1 state, if the node does not exceed the above-mentioned retry limit and the retry packet is put in the above-mentioned retry queue, the node transitions from the OSR1 state to the OSR0 state.

[0015] Further, when the node receives a packet other than any of ack _busy_A, ack _busy_B, and ack _busy_X in the OSR1 state, the packet from the node has already been transmitted, and the OSR1 state transitions to the OSR0 state. To do.

[0016] Further, if the node exceeds the above-mentioned retry limit and makes a retry in the OSR1 state, this communication fails and the node transitions from the OSR1 state to the OSR0 state.

[0017] As described above, when the node that received the packet is busy and cannot receive the packet, the receiving node notifies the node that transmitted the packet that the receiving node is busy, and the transmitting node notifies the node that the packet is transmitted. Try to retry later. At the time of retry, the retry code is added to the packet and transmitted.

[0018] There are two types of retries, a single phase retry and a dual phase retry. The single phase retry is a relatively simple operation, and the retry is repeated until the reception is successful or the retry limit is exceeded. The above retry operation describes a single phase retry.

[0019] In the case of dual phase retry, the received packet is divided into groups A and B, and the retry operation is performed. In the case of dual phase retry, when the receiving node is busy, the receiving node responds by using an acknowledgment packet of ack _busy_A or ack _busy_B.

After that, when the transmitting node makes a retry, the transmitting node uses retry _A when it receives ack _busy_A immediately before, and uses retry _B when it receives ack _busy_B immediately before.

[0021] When the receiving node receives a retry of retry _A, ack _busy_B is assigned to packets from other nodes. When all retry _A retries are accepted, the receiving node accepts retry _B retries and assigns ack _busy_A to other received packets. The above processing is repeated, and the processing of the A group and the B group proceeds alternately.

[0022] Further, in the dual phase retry, it is determined whether all the retries of retry _A are completed by using the timeout. Transmitting nodes that use dual-phase retries must retry every four fairness intervals (as defined by the IEEE1394 standard) until the retry timeout expires.

The receiving node assumes that all retries of retry _A are transmitted while all four fairness intervals have elapsed, with all retries of retry _A not busy. A similar timeout applies to retry _B. Therefore, if the transmitting node fails to retry during the four fairness intervals, communication will fail.

[0024] If a transmitting node that implements only a single phase retry receives an acknowledgment code of ack _busy_X, ack _busy_A, or ack _busy_B, it must be retried using the retry code of retry _X. It has become like.

Further, the receiving node implementing the dual phase retry accepts the retry of retry _X when the retry phase when receiving the retry of retry _X is completed.

[0026] As described above, in the asynchronous communication of 1394, it is guaranteed that the communication is surely performed by the retry. Conventionally, a data transfer method using data transfer by write transaction using this asynchronous communication has been proposed.

[0027] [Problems to be Solved by the Invention] However, in the conventional data transfer method using the asynchronous write transaction, how long waits after ack _busy_X, ack _busy_A, ack _busy_B, etc. are returned. It is not specified what to do.

[0028] Therefore, when the transfer is performed by the combination of the receiving node having a slow processing speed and the transmitting node having a high processing speed, when the bus is congested, the retry of the high speed transmitting node occurs frequently and the processing described above. It is expected that the buffer of the slow receiving node will always be filled.

[0029] In this case, the transfer of ack _busy_X, ack _busy_A, and ack _busy_B from the receiving node will occur frequently, and the transmitting node will not be able to transmit the next packet, so-called deadlock will occur. There was a problem such as.

[0030] Further, in the case of the data transfer method using broadcast communication, there is a problem that retry is impossible and it is not guaranteed that communication is surely performed.

The present invention<u style="single">, Ba</u>The purpose is to prevent the occurrence of deadlocks by preventing the frequent occurrence of ack _busy_X, ack _busy_A, ack _busy_B, etc. even when the space is crowded.

[Means for Solving the Problems] The data communication system according to the present invention has a source node for transmitting transmitted data and a destination node for receiving the transmitted data, and the source node is When the transmitted data is not normally received, the destination node has a function of prohibiting the retransmission processing of the transmitted data until a predetermined time elapses.<u style="single">When the load state of the destination node is the first load state, the predetermined time is changed to the first time and the source node is notified, and the load state of the destination node is the first load state. In the case of a second load state that is larger than the load state,</u>The predetermined time<u style="single">Change to a second time that is longer than the first time</u>It is characterized by having a function of notifying the source node.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described with reference to FIG. In Figure 1, 10 is a computer, 12 is an arithmetic processor (MPU), 14 is a first 1394 interface, 16 is a first control unit such as a keyboard, 18 is a first decoder, 20 is a CRT display, etc. Display device, 22 is the hard disk, 24 is the first memory, the internal memory of the computer 10 according to the present invention, 26 is the internal computer interface such as the PCI bus.<u style="single">In</u>is there.

[0042] 28 is a VCR, 30 is an imaging optical system, 32 is an analog-to-digital (A / D) converter, 34 is a video processing unit, 36 is a compression / decompression circuit, 38 is a second memory, and 40. Is the third memory, 42 is the first data selector, 44 is the second 1394 interface, 46 is the first memory control circuit, 48 is the second memory control circuit, 50 is the system controller, 52 is the second. The operation unit, 54 is the finder, 56 is the D / A converter, and 58 is the recording unit.

[0043] Furthermore, 60 is a printer, 62 is a third 1394 interface, 64 is a second data selector, 66 is a third operation unit, 68 is a printer controller, 70 is a second decoder, and 72 is a second. 4 is the memory, 74 is the image processor, 76 is the driver, and 78 is the printer head.

[0044] The computer 10, the VCR 28, and the printer 60 form a node of the 1394 serial bus by the first to third 1394 interfaces 14, 44, 62, and the first to third 1394 interfaces. It is connected to each other via 14, 44, 62, and it is possible to send and receive data and control by commands.<u style="single">。</u>[0045] In the present embodiment, for example, the computer 10 operates as a controller for transmitting and receiving image signals on the 1394 serial bus. In the computer 10 according to the present embodiment, for example, the MPU 12 and the 1394 interface 14, the keyboard 16, the decoder 18, the CRT display 20, the hard disk 22, the internal memory 24, etc. are provided by the computer internal bus 26 such as the PCI bus. Each internal device is interconnected.

[0046] The MPU 12 executes the software recorded on the hard disk 22 and moves various data to the internal memory 24. The MPU 12 also performs arbitration operations for each device connected by the PCI bus 26.

The 1394 interface 14 receives the image signal transferred on the 1394 serial bus, and also transmits the image signal recorded on the hard disk 22 and the image signal stored in the internal memory 24.

[0048] Further, the 1394 interface 14 transmits command data to other devices connected on the 1394 serial bus. In addition, the 1394 interface 14 transfers the signal transferred on the 1394 serial bus to another 1394 node.

The operator causes the MPU 12 to execute the software recorded on the hard disk 22 through an operation unit such as the keyboard 16. Information such as the software is presented to the operator by a display device 20 such as a CRT display. The decoder 18 decodes the image signal received from the 1394 serial bus through the above software. The decoded image signal is also presented to the operator by a display device 20 such as a CRT display.

[0050] In the present embodiment, for example, the VCR 28 operates as an image signal input device. The luminance signal (Y) and color difference signal (C) of the image input from the imaging optical system 30 are each converted into digital data by the A / D converter 32. The digital data is multiplexed by the video processing unit 34. After that, the data amount of the image information is compressed by the compression / expansion circuit 36.

[0051] Generally, the compression processing circuit is provided independently of YC, but here, for the sake of simplification of the description, an example of compression processing in YC time division is shown. Next, a shuffling process is performed for the purpose of making the image data resistant to transmission path errors. The purpose of this process is to convert a burst error, which is a continuous code error, into a random error, which is a discrete error that is easy to correct or interpolate. In addition, if the purpose of equalizing the unevenness of the amount of information generated due to the density in the screen of the image is emphasized, if this processing step is brought before the compression processing, a variable length code such as run length can be obtained. It is convenient when used.

[0052] In response to this, data identification (ID) information for restoration of data shuffling is added. The ID added by this ID addition operation is used as auxiliary information at the time of decompression processing (information amount expansion processing) at the time of reproduction together with the mode information of the system recorded at the same time. Error correction (ECC) information is added to reduce errors during playback of these data.

[0053] Up to the addition of such a redundant signal is processed for each independent recording area corresponding to each information such as video and audio. As described above, the image signal to which the ID information and the ECC information are added is recorded by the recording unit 58 on a recording medium such as a magnetic tape, and is temporarily stored in the second memory 38 described later.

[0054] On the other hand, the image data multiplexed by the video processing unit 34 is digital-to-analog converted by the D / A converter 56 and observed by the operator with the electronic viewfinder 54. In addition, the operator transmits various operation information to the system controller 50 via the second operation unit 52, and the system controller 50 controls the entire VCR by the operation information.

Further, the image data multiplexed by the video processing unit 34 is output to the third memory 40 and temporarily stored. The operation of the second memory 38 and the third memory 40 described above is controlled by the system controller 50 via the first memory control circuit 46 and the second memory control circuit 48, respectively.

The first data selector 42 selects data from the second memory 38 and the third memory 40 described above and passes the data to the second 1394 interface 44, or the second 1394 interface. Select data from 44 and pass it to either the second memory 38 or the third memory 40. By the above operation, the compressed image data and the uncompressed image data can be selected and output by the operator from the second 1394 interface 44 in the VCR 28.

The second 1394 interface 44 receives command data for controlling the VCR 28 through the 1394 serial bus. The received command data is input to the system controller 50 through the first data selector 42.

【0058】<u style="single">Shi</u>The stem controller 50 creates response data for the above command data and sends the data to the 1394 serial bus through the first data selector 42 and the second 1394 interface 44.

[0059] In the present embodiment, for example, the printer 60 operates as an image print output device. The third 1394 interface 62 receives the image signal transferred on the 1394 serial bus and the command data for controlling the printer 60 through the 1394 serial bus. The third 1394 interface 62 also transmits response data to the command.

[0060] The received image data is input to the second decoder 70 through the second data selector 64. The second decoder 70 decodes the image data and outputs it to the image processing unit 74. The image processing unit 74 temporarily stores the decoded image data in the fourth memory 72.

On the other hand, the received command data is input to the printer controller 68 through the second data selector 64. The printer controller 68 performs various printing-related controls such as paper feed control by the driver 76 and position control of the printer head 78 based on the command data. Further, the printer controller 68 transmits the image data temporarily stored in the fourth memory 72 as print data to the printer head 78 to perform the printing operation.

[0062] As described above, the first to third 1394 interfaces 14, 44, and 62 according to the present embodiment each constitute a node of the 1394 serial bus. The first 1394 interface 14 operates as a control node or controller, the second 1394 interface 44 operates as a source node for image data, and the third 1394 interface 62 operates as a destination node.

[0063] The command packet or response packet according to the present embodiment is transmitted / received by, for example, an asynchronous packet. The Asynchronous packet is, for example, a data packet having 4 bytes (32 bits, hereinafter referred to as a quadlet) as a unit.

[0064] FIG. 2 is a diagram showing the structure of a general Asynchronous packet. In Figure 2, the first 16 bits are the destination _ID field, which indicates the node ID of the recipient. The next 6 bits field is the transaction label (tl) field, which is a tag unique to each transaction.

The next 2-bit field is the retry (rt) code, which specifies whether the packet attempts to retry. The field also specifies the retry protocol described above for the packet receiving node shown in FIG. Table 1 below shows an example of coding the above retry code.

[0066] [Table 1]<img file="JP4065466B2_D0001.tif" />[0067] If the node transmitting the packet does not support the optional dual phase retry described above, retry _X must be used for the value of the field.

The next 4-bit field is the transaction code (tcode). tcode specifies the format of the packet and the type of transaction it must execute. In this embodiment, for example, this value is 0001.₂Use the transaction of the data block write request.

[0069] The next 4-bit field is a priority (pri) field and specifies the priority. In this embodiment, since an asynchronous packet is used, the value of this field is 0000.₂Is.

The next 16 bits are the source_ID field, which indicates the sending node ID. The next 48 bits are packet type specific information, which is a field in which information specific to the type of the Asynchronous packet is stored.

[0071] In the case of a so-called request packet such as a data block write request, read request, lock request, etc. as in the present embodiment, this field is a destination _offset field, which is the lower 48 of the receiving node address of the packet. bits are specified by this field.

[0072] Further, in the case of a response packet for a write, read, and lock request, the field is divided into a rcode field of the upper 4 bits and a reserved field of the lower 44 bits. The code of the response to the above request is stored in the rcode field. Also, in the reserved field, for example, 00000000000₁₆The value of is packed.

The next 32 bits are packet type specific quadlet data, which is a field in which data specific to the Asynchronous packet type is stored. The field may not exist depending on the type of packet.

[0074] For example, this field does not exist for packets without a data payload. Further, in the case of a packet having a data quadlet payload, the field is a quadlet _data field, and 32 bits of data are stored.

[0075] Further, in the case of a packet having a data block, the field is divided into a data_length field of the upper 16 bits and an extended_tcode field of the lower 16 bits. In the above data_length field, the data length of the data block described later is stored.

[0076] The data length stored in the data_length field is indicated, for example, in units of bytes (8 bits). The extended_tcode field has meaning only in the case of a lock request or lock response packet, and in the case of a packet other than the lock request or lock response, as in the case of the write request packet used in the present embodiment. For example, 0000₁₆The value of is stored.

The next 32 bits are the header_CRC field. The area from the destination _ID field to the packet type specific quadlet data described above is referred to as a packet header, and the header_CRC field is used for error detection of the packet header.

Next, the field that follows is a data block. A data block consists of a data block quadlets and a data_CRC field.

[0079] A data block quadlet is sometimes referred to as a data block payload or a data field. The data block quadlet is present in every data block packet and usually stores variable length data. When variable length data is stored, the data_length field described above indicates the data length of the data block quadlet.

[0080] In the present embodiment, the bit of the data quadlet block that is less than a multiple of the quadlet is filled with a value of 0. In other words, if the data length stored in the data_length field is indicated in bytes (8 bits) and the value of the data_length field is not a multiple of 4, the data quadlet block will fill the quadlet. 00₁₆Filled with data of the value of.

[0081] The next 32-bit field is a data_CRC field, which is used for error detection of the above data block quadlet, like the header_CRC field described above.

[0082] The receiving node that receives the packet as described above returns a response by means of an acknowledge packet. Since the acknowledge packet is exactly 1 byte (8 bits) in length, it can be easily distinguished from other packets. The acknowledgment packet is also referred to as an ack packet, an ack packet, or the like. FIG. 3 is a diagram showing the structure of the acknowledge packet.

[0083] The first 4 bits of the acknowledgment packet are the ack _code field. The field transfers codes such as ack _busy_A, ack _busy_B, and ack _busy_X described above. An example of coding the ack _code field is shown in Table 2.

[0084] [Table 2]<img file="JP4065466B2_D0002.tif" />The next 4-bit field is the ack _parity field, which stores the parity check bits of the acknowledgment packet. For example, in this embodiment, the one's complement of the value of ack _code is stored. The field is used for error detection of acknowledge packets.

[0086] The state transition diagram shown in FIG. 4 shows an example of the behavior when a transmitting node in the present embodiment, which implements only a single phase retry, receives a busy after transmitting a packet to another node. ing.

[0087] When the node shown in FIG. 4 receives the transaction control packet of Initialize or Reset from the node controller, the node transitions from another state to the OSR0 state. At this time, the node is ready to send a packet to another node. If the node receives a packet other than ack _busy_A, ack _busy_B, and ack _busy_X in the OSR0 state, the node sends the packet and does not need to retry.

[0088] When the node receives the packets of ack _busy_A, ack _busy_B, and ack _busy_X in the OSR0 state, the receiving node is in the busy state.<u style="single">And</u>recognize. In this case, Litra<u style="single">Lee's</u>The node transitions to the OSR1 state as the need arises.

[0089] In the OSR1 state, the node has a pending retry that must be resolved and must resolve the retry before sending any other packet. At this time, the node specifies the retry code in retry _X and performs a retry.

[0090] In the OSR1 state, a so-called retry packet that does not exceed the so-called retry limit, which is the upper limit of the number of retries by the node, and is pending, is a queue of retry packets, so-called retry. If not queued, the node remains in the OSR1 state.

Further, in the OSR1 state, the minimum retry period is set. In the OSR1 state, the above minimum retry lap<u style="single">Period</u>Until it elapses, it does not transition to the OSR0 state.<u style="single">。</u>[0092] In the OSR1 state, if the node does not exceed the above-mentioned retry limit and the retry packet is put in the above-mentioned retry queue, the node transitions from the OSR1 state to the OSR0 state. If the node receives a packet other than ack _busy_A, ack _busy_B, or ack _busy_X in the OSR1 state, the packet from the node has already been transmitted, and the OSR1 state transitions to the OSR0 state.<u style="single">。</u>Further, if the node exceeds the above-mentioned retry limit and makes a retry in the OSR1 state, this communication fails and the node transitions from the OSR1 state to the OSR0 state.

[0094] The state transition diagram of FIG. 5 shows an example of the behavior when a transmitting node in the present embodiment, which implements an optional dual phase retry, receives a busy after transmitting a packet to another node. ing.

[0095] When the node shown in FIG. 5 receives the transaction control packet of Initialize or Reset from the node controller, the node transitions from another state to the ODR0 state. At this time, the node is ready to send a packet to another node, sets the above retry code to retry _1, and waits. In the case of the ODR0 state, if the node receives an acknowledgment packet other than ack _busy_A, ack _busy_B, and ack _busy_X after transmitting the packet, the packet has already been transmitted and the node does not need to respond.

[0096] In the ODR0 state, when an acknowledgment packet of ack _busy_A or ack _busy_B is received, the receiving node is a dual phase retry node and is in a busy state. At this time, the node retries the packet as a dual phase retry.

[0097] In the ODR0 state, when ack _busy_A is received, the retry phase A occurs, and the node transitions to the ODR1 state. Also, when ack _busy_B is received in the ODR0 state, it is in the retry phase B, and the node transitions to the ODR2 state.

[0098] In the ODR0 state, when an acknowledgment packet of ack _busy_X is received, the receiving node is a single phase retry node and is in a busy state. At this time, the node retries the packet as a single phase retry. When ack _busy_X is received in the ODR0 state, the node transitions to the ODR3 state.

[0099] In the ODR1 state, the node is in retry phase A and has a pending retry that must be resolved. In the ODR1 state, the minimum retry period is set. In the ODR1 state, the ODR1 state remains without retrying until the minimum retry cycle elapses.

[0100] In the ODR1 state, the node sets the retry code to retry _A and performs a retry. When the node receives an acknowledgment packet in the ODR1 state, if the acknowledge code is ack _busy_A and the above-mentioned four fairness interval timeout periods have not passed, the node remains in the ODR1 state. Repeat the retry.

[0101] If an acknowledgment packet containing an acknowledgment code other than ack _busy_A or ack _busy_B is received in the ODR1 state, the packet has already been transmitted and the node transitions to the ODR0 state. Further, when the above-mentioned timeout period has elapsed, the node has failed in transmission and also transitions to the ODR0 state.

[0102] In the ODR2 state, the node is in retry phase B and has a pending retry that must be resolved. In the ODR2 state, the minimum retry period is set. In the ODR2 state, the ODR2 state remains without retrying until the minimum retry cycle elapses.

[0103] In the ODR2 state, the node sets the retry code to retry _B and retries. When the node receives an acknowledgment packet in the ODR2 state, if the acknowledge code is ack _busy_B and the above-mentioned four fairness interval timeout periods have not passed, the node remains in the ODR1 state. Repeat the retry.

[0104] When an acknowledgment packet containing an acknowledgment code other than ack _busy_A or ack _busy_B is received in the ODR2 state, the packet has already been transmitted and the node transitions to the ODR0 state. Further, when the above-mentioned timeout period has elapsed, the node has failed in transmission and also transitions to the ODR0 state.

[0105] In the ODR3 state, the node performs a single phase retry. In the ODR3 state, the minimum retry period is set. In the ODR3 state, the ODR3 state remains without retrying until the minimum retry cycle elapses. In the ODR3 state, the node sets the retry code to retry _ and retries.

[0106] When the node receives an acknowledgment packet in the ODR3 state, if the acknowledge code is ack _busy_ and the retry limit described above is not exceeded, the node stays in the ODR3 state and retries. repeat.

[0107] When an acknowledgment packet including an acknowledgment code other than ack _busy_X is received in the ODR3 state, the packet has already been transmitted, and the node transitions to the ODR0 state. Further, when the above-mentioned retry limit is exceeded, the node has failed in transmission and also transitions to the ODR0 state.

[0108] By configuring the configuration to have a predetermined retry period as described above, the transmitting node of the present embodiment guarantees that communication is surely performed, and even when the bus is congested, the receiving node is used. It is possible to prevent the frequent occurrence of busy states and prevent the occurrence of deadlock. Further, by using the transmission node as the source node of the present embodiment and performing a write transaction by the node, a communication system capable of preventing the occurrence of deadlock can be configured.

[0109] The communication procedure of the object data using the broadcast communication method will be described with reference to FIG. The controller is the source node selected by the user and the destination.<u style="single">Nno</u>Negotiate to make a connection with the device. Packets for making connections are used for negotiation. The packet is, for example, asynchronous broadcas.<u style="single">Topa</u>Connection I, which is a packet and indicates the connection number in the payload in the packet.<u style="single">D</u><u style="single">But</u>It has been written. Each node identifies the connection by the above connection ID.

[0110] The source node that receives the above negotiation packet from the controller waits for the transmission command packet from the controller. On the other hand, the destination node that has received the negotiation packet waits for the asynchronous broadcast packet of the inquiry from the source node.

[0111] The asynchronous broadcast packet of the inquiry asks the destination node whether the source node is ready to receive. The source node and the destination node do not send an acknowledge packet to the control node because the negotiation packet is a broadcast packet.

[0112] After the above-mentioned negotiation is completed, the controller sends a command packet for data transmission to the source node. Since the command packet is a broadcast packet, the source node does not send an acknowledge packet to the control node.

[0113] The source node that receives the above command packet transmits an asynchronous broadcast packet of the inquiry to the destination node. The above-mentioned connection ID is written in the inquiry packet. Since the inquiry packet is a broadcast packet, the destination node does not send an acknowledge packet to the source node.

Upon receiving the inquiry packet, the destination node collates the connection ID written in the inquiry packet with the connection ID by the negotiation described above, and the inquiry packet is from the source node of the same connection. Determine if it is a packet.

[0115] When the inquiry packet has the same connection, the destination node sends an accepted response packet in which the same connection ID as the inquiry packet and the capacity of the buffer for data reception are written by asynchronous broadcast. Since the response packet is a broadcast packet, the source node does not send an acknowledge packet to the destination node.

[0116] At the time of data transfer, the source node performs a write transaction with respect to the node offset of the destination node instructed by the controller. The write transaction is performed using Asynchronous broadcast packets. In the present embodiment, the destination node sends an acknowledge packet shown in FIG. 3 to the source node for each of the above write transactions, and when the destination node is in the busy state, the source node retries. It is designed to guarantee the reliability of data transfer. At that time, the source node prevents the occurrence of the above-mentioned deadlock by performing the retry operation shown in FIG. 4 or FIG.

[0117] The source node transmits data by segmenting object data (for example, still image, moving image, text, etc.) to be transmitted. The divided data is called segment data. The segment data is transmitted in one broadcast transaction. The amount of data in the segment data is determined, for example, by the capacity of the FIFO memory (not shown) of the node that receives the data.

[0118] The source node transmits the segment data using an asynchronous broadcast packet. An asynchronous broadcast packet containing one segment data is called a segment packet.

[0119] In the segment packet, the above-mentioned connection ID and the sequence number indicating the order of the above-mentioned segment data are written. The destination node that received the packet collates the connection ID written in the segment packet with the connection ID notified in advance by the controller.

[0120] When the connection ID written in the segment packet matches the connection ID notified in advance by the controller, the destination node receives the packet and receives the same connection ID and reception as the packet. A response packet (not shown) in which the sequence number in the data is written is transmitted by using asynchronous broadcast.

[0121] The source node identifies a packet to its own node by the connection ID of the received packet. The above-mentioned response operation occurs when one segment data is exchanged.

[0122] As described above, the inquiry packet is transmitted from the source node to the destination node prior to data transfer. The destination node notifies the buffer size of the buffer that the destination node itself has by using the response packet for the inquiry.

[0123] In the above-described example, the response packet is transmitted in association with the transmission of the segment data once, but after the above-mentioned buffer of the destination node is filled with the segment data, the destination node May be configured to send a response packet. In this configuration, the number of response operations performed by the destination node can be reduced, which has the effect of simplifying the destination node.

[0124] The destination node of the present embodiment compares the sequence number of the segment packet received in the i-th order with the sequence number of the segment packet received in the (i + 1) th th, and makes data inconsistency. Monitor. When an inconsistency is detected in the sequence number, the destination node can request segment data from the source node again by sending a response packet indicating a retransmission request. Further, in the response packet indicating the retransmission request, the sequence number in which the retransmission request has occurred can be specified.

On the other hand, the source node waits for a response from the destination node after transmitting the segment packet. As described above, the destination node transmits a response packet in which the connection ID and the sequence number are written as an asynchronous broadcast packet.

[0126] The connection ID is written in the response packet transmitted by the broadcast packet. If this value matches the connection ID indicating the connection with the target destination node, the packet is a response packet. Upon receiving the response packet, the source node increments the sequence number and similarly sends the next segment packet. By repeating the above procedure, the source node transfers data.

[0127] The time for the source node to wait for a response from the destination node is predetermined, and this cycle is referred to as a response cycle. After sending the i-th segment packet, if the response cannot be received even after the response cycle is exceeded, the source node retransmits the same segment packet as the i-th segment packet above.

[0128] Further, when receiving the retransmission request response from the destination node as described above, the source node transmits the segment packet of the sequence number specified in the response packet. In the present embodiment, the above procedure has an effect that the data transfer can be easily restored even when the data transfer is interrupted due to the occurrence of a bus reset or some error.

[0129] When the data transfer is completed by transmitting all the segment packets, the source node sends a broadcast packet indicating the segment end. The controller that receives this packet releases the connection ID and the data transfer ends.

[0130] In the present embodiment, the controller that has received the segment end explicitly releases the connection ID. However, since the packet indicating the segment end is a broadcast packet, the destination node can detect the end of the data transfer by the segment end packet. Therefore, the destination node may perform the connection ID and release.

[0131] In order to reliably transfer data, it is desirable that the data transfer be resumed promptly even if the data transfer is interrupted due to the occurrence of a bus reset or some error. As described above, in the present embodiment, the problem is solved by providing a procedure for requesting retransmission.

[0132] For example, when the data transfer is interrupted when the sequence number is i, each node first reconstructs the bus according to the procedure defined by the standard. After the bus reconstruction is completed, the destination node sends a retransmission request packet in which the destination _offset, the connection ID, and the sequence number i are written as a broadcast packet.

[0133] If the data transfer can be resumed, the source node returns an accepted response. After that, the source node collates the connection ID of the received packet, and sequentially transmits the data after the requested sequence number, that is, the data of the data string starting with the sequence number (i + 1) in the broadcast packet.

[0134] According to the above procedure, the source node, the destination node, and the controller node can easily and surely restart the subsequent data transfer even if the data transfer is interrupted without considering the node ID. Can be done. Further, as described above, the present embodiment has an effect that the control procedure of the controller can be simplified even when the data transfer is interrupted.

[0135] In the present embodiment, it is described that the acknowledge packet is not sent and the retry is not performed for the negotiation packet, the command packet, the inquiry packet, and the response packet. However, it goes without saying that the acknowledge packet may be sent and the retry may be performed.

Next, the above-mentioned Asynchronous broadcast packet will be described with reference to FIG. 7. The Asynchronous broadcast packet according to the present embodiment is, for example, a data packet having 4 bytes (32 bits, hereinafter referred to as a quadlet) as a unit.

[0137] In an Asynchronous packet, the first 16 bits are the destination _ID field, which indicates the node ID of the recipient. When broadcasting as in this embodiment, the value of this field is FFFF.₁₆Is. The next 6 bits field is the transaction label (tl) field, which is a tag unique to each transaction. The next 2 bits field is the retry (rt) code, which specifies whether the packet will attempt to retry.

The next 4-bit field is the transaction code (tcode). tcode specifies the format of the packet and the type of transaction it must execute. In this embodiment, for example, this value is 0001.₂ Use the transaction of the data block write request. The next 4-bit field is the priority (pri) field, which specifies the priority. In this embodiment, since an asynchronous packet is used, the value of this field is 0000.₂ Is.

The next 16 bits are the source_ID field, which indicates the sending node ID. The next 48 bits are the destination _offset field, which specifies the lower 48 bits of the packet's destination node address. In the present embodiment, for example, the value of the destination _offset is determined by the value of the connection_ID field described later.

The next 16 bits are the data_length field, which indicates the length of the data field, which will be described later, in bytes. The next 16 bits are the extended_tcode field, which is 0000 in the write request transaction of the data block used in this embodiment.₁₆Is.

[0141] The next 32 bits are the header_CRC field, and the above-mentioned destination _ID field to extended_tcode field is referred to as a packet header and is used for error detection of the packet header.

[0142] The next 16 bits are the connection ID (connection _ID) field described above, and the connection is identified by the data. With the connection ID, it is possible to establish a connection of (2 to the 16th power) × (number of nodes). Therefore, in the present embodiment, the number of connections can be increased until the total amount of bandwidth used by each connection reaches the capacity of the bus.

[0143] The next 8 bits are a protocol type (protocol _type) field, and indicate a procedure for exchanging data using the header information. The transfer procedure of this embodiment includes, for example, 01.₁₆The value of is used. The next 8 bits are the control flags (control_flags) field, where control data is written. The most significant bit of the control flag field is, for example, a resend request (resend _request) flag, and when the value of this bit is 1, it indicates that a data retransmission request has occurred.

The next 16 bits are the sequence number field. As described above, a continuous value is used for the sequence number field for data packets sent and received with a specific connection ID. The destination node monitors the continuity of significant data by the sequence number field, and if a discrepancy occurs, makes a retransmission request to the source node.

The next 16 bits are the confirmation number field. This field is meaningful only when the value of the above-mentioned retransmission request flag is 1. When the value of the retransmission request flag described above is 1, this field indicates the sequence number of the start packet in which the retransmission request is occurring.

The next 16 bits are the buffer size (buffer _size) field. This field contains the buffer size of the destination node. The next 16 bits are reserved fields, reserved for the future.

The next field is a variable length data field, which is referred to as the packet payload. In this embodiment, if the data field is not a multiple of the quadlet, the bits less than the quadlet are padded with zeros.

The next 32-bit field is the data_CRC field, which, like the header_CRC field described above, is used to detect an error between the header information described above and the data field. Needless to say, the data_CRC field may be attached only to the data field.

[0149] The node that receives the packet as described above returns a response by the above-mentioned acknowledge packet shown in FIG. Further, the node that has received the packet as described above may return a response by using the acknowledge packet as shown in FIG.

[0150] In the acknowledgment packet shown in FIG. 8, the first 4 bits of the acknowledge packet are the ack _code fields. The field transfers codes such as ack _busy_A, ack _busy_B, and ack _busy_X described above. The coding of the ack _code field is the same as that of the acknowledgment packet shown in FIG. 3 above. The next 4 bits field is the ack _parity field, which stores the parity check bits of the acknowledge packet. For example, in this embodiment, the one's complement of the value of ack _code is stored. The field is used for error detection in the ack _code field.

The next 8-bit field is the min _retry _period field. In the field, the value of the minimum retry cycle described above is stored, for example, in units of 1 millisecond. For example, the value of the field is 01₁₆At that time, the node that received the acknowledge packet operates so as not to return a retry during the period of the minimum retry cycle by setting the above-mentioned minimum retry cycle to 1 millisecond. Of course, it goes without saying that other time units other than 1 millisecond can be used as the unit for setting the min_retry _period field above.<u style="single">I.</u>[0152] Further, the node that sets the field and returns the acknowledge packet monitors the load state of its own node, increases the value of the above-mentioned minimum retry period when the load is large, and increases the above-mentioned minimum retry period when the load is small. Set the period value small.

The load state of a node includes the number of retries made to the node, the number of packets transmitted to the node, the occupied state of the buffer of the node, and the node. It is possible to use various indicators such as the number of connections. Of course, the index for detecting the load state of the node is not limited to the above, and it goes without saying that it is sufficient if the load state can be detected.

[0154] Further, the value of the above min _retry _period field is set to 00.₁₆It is also possible to use the setting of in a special meaning. For example, the value of the min _retry _period field is 00₁₆At, set the minimum retry cycle to 100 ms as the default.

[0155] Of course, as a default, the minimum retry cycle is not limited to 100 milliseconds, and it goes without saying that it may be set to another value. Also, in another embodiment, the value of the min _retry _period field is 00.₁₆At this time, the node that returns the retry may be set to return the retry as soon as possible, so-called immediate retry.

[0156] FIG. 9 is a diagram showing an operation for setting the minimum retry period described above. FIG. 9 (a) shows an operation flow showing packet transfer between the source node that makes a write request and the destination node that returns an acknowledge packet in response to the request, and FIG. 9 (b) shows the above-mentioned destination. It is a graph which shows the time change of the load state of a nation node. In Fig. 9 (b), the load state of the destination node is shown from left to right, and the passage of time is shown from top to bottom.

[0157] In FIG. 9, when the source node makes a first write request (write request # 1) (t).₁In), the load on the destination node is relatively small (L).₁) And busy state. The destination node, for example, sets the value of min _retry _period above to 32.₁₆Set to and returns an acknowledgment packet of ack _busy_X.

The source node sets the minimum retry period to 50 milliseconds from the above min _retry _period value of the acknowledge packet. The source node does not retry during the minimum retry cycle, but at least after 50 milliseconds (retry # 1). In FIG. 9, the retry is successful and the write transaction is completed.

Next, when the source node makes a second write request (write request # 2) (t).₂In), the load on the destination node is relatively large (L).₂) And busy state. The destination node, for example, sets the value of min _retry _period above to B4.₁₆Set to and returns an acknowledgment packet of ack _busy_X.

The source node sets the minimum retry period to 180 milliseconds from the above min _retry _period value of the acknowledge packet. The source node does not retry for the duration of the minimum retry cycle, but does retry after at least 180 ms (retry # 2).

[0161] By operating as described above, in the present embodiment, the node that sends the acknowledge packet guarantees that the communication is surely performed by dynamically setting the minimum retry cycle, and the bus Even when it is crowded, it has the effect of preventing the frequent occurrence of busy states and providing a communication system capable of preventing the occurrence of deadlock. Further, by operating as described above, in the present embodiment, the minimum retry cycle can be dynamically set, so that communication resources can be appropriately allocated, and the node performing the retry does not occupy the communication path, so that the communication efficiency Has the effect of improving.

(Other Embodiments of the present invention) The present invention is applied to a device including one device even if it is applied to a system composed of a plurality of devices (for example, a host computer, an interface device, a reader, a printer, etc.). You may.

[0163] Further, in order to realize the function of the above-described embodiment for a computer connected to the various devices or a computer in the system so as to operate various devices so as to realize the function of the above-described embodiment. The present invention also includes those carried out by supplying the program code of the software of the above and operating the above-mentioned various devices according to the program stored in the computer (CPU or MPU) of the system or the device.

[0164] Further, in this case, the program code itself of the software realizes the function of the above-described embodiment, and the program code itself and the means for supplying the program code to the computer, for example, such a program code. The storage medium containing the above constitutes the present invention. As a storage medium for storing such a program code, for example, a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a magnetic tape, a non-volatile memory card, a ROM, or the like can be used.

[0165] Further, by executing the program code supplied by the computer, not only the functions of the above-described embodiments are realized, but also the OS (operating system) or other operating system in which the program code is running in the computer is realized. Needless to say, such a program code is included in the embodiment of the present invention even when the functions of the above-described embodiment are jointly realized by application software and the like.

[0166] Further, after the supplied program code is stored in the memory provided in the function expansion board of the computer or the function expansion unit connected to the computer, the function expansion board or the function expansion unit is based on the instruction of the program code. Needless to say, it is also included in the present invention when the CPU or the like provided in the above performs a part or all of the actual processing and the function of the above-described embodiment is realized by the processing.

[Effect of the Invention]<u style="single">Book</u>For invention<u style="single">According to, Ba</u>Even when the space is crowded, it is possible to prevent the frequent occurrence of busy conditions and cause deadlock.<u style="single">Prevent</u>Can be

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a block diagram showing a configuration of a data communication system according to an embodiment of the present invention.

FIG. 2 is a diagram showing a general structure of an asynchronous packet used in the embodiment of the present invention.

FIG. 3 is a diagram showing a structure of an acknowledge packet used in the embodiment of the present invention.

FIG. 4 is a state transition diagram showing an example of the operation of a transmitting node in a single phase retry according to the embodiment of the present invention.

FIG. 5 is a state transition diagram showing an example of the operation of the transmitting node in the dual phase retry according to the embodiment of the present invention.

FIG. 6 is a diagram showing a diagram of a data transfer procedure using broadcast communication according to the embodiment of the present invention.

FIG. 7 is a diagram showing a structure of a data packet used for broadcast communication according to the embodiment of the present invention.

FIG. 8 is a diagram showing a structure of an acknowledge packet for setting the minimum retry period used in the embodiment of the present invention.

FIG. 9 is a diagram showing a diagram of an operation for setting a minimum retry period according to an embodiment of the present invention.

FIG. 10 is a state transition diagram showing the operation of a conventional packet receiving node.

FIG. 11 is a state transition diagram showing the operation of a conventional packet transmission node.

[Code description] 10 computer12 Arithmetic processing device (MPU) 14 First 1394 interface 16 First operation unit such as keyboard 18 First decoder 20 Display device such as CRT display 22 Hard disk 24 First memory 26 PCI bus, etc. Computer internal bus 28 VCR30 Imaging optical system 32 A / D converter 34 Video processing unit 36 Compression / decompression circuit 38 Second memory 40 Third memory 42 First data selector 44 Second 1394 interface 46 First memory Control circuit 48 Second memory control circuit 50 System controller 52 Second operation unit 54 Electronic viewfinder 56 D / A converter 58 Recording unit 60 Printer 62 Third 1394 interface 64 Second data selector 66 Third operation Part 68 Printer controller 70 Second decoder 72 Fourth memory 74 Image processing part 76 Driver 78 Printer head