JP2006129125A - Asynchronous packet communication method and asynchronous packet communication equipment - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an asynchronous packet communication method and asynchronous packet communication equipment reducing a system burden caused by a request and a retry request in asynchronous packet communication. <P>SOLUTION: At the time of retry transmission, the number of retry times is subjected to increment and then, retry transmission is performed (No in step S11 and step S14). However, when an Ack code is Ack_busy (Yes in step S11: error occurrence), retry interval update processing by arithmetic processing of T←T1+ΔT (for example, ΔT=T1 is possible. Naturally, limitation is not made to this) is performed (step S13) after waiting for a retry interval (T1), advancing to a step S14. The update retry interval (time) is increased in accordance with the number of error occurrence times. By performing such processing, the load of software by retry is reduced. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an asynchronous packet communication method and an asynchronous packet communication apparatus, and is used in, for example, IEEE 1394, which is a high-speed digital interface.

In IEEE 1394 or the like, asynchronous packets are transmitted in the link layer (see Patent Document 1 and Patent Document 2). The transaction layer is in charge of retry processing when a transmission error occurs, and the retry interval is fixed at an appropriate value.
JP 2000-151719 A JP-T-2004-516712

  By the way, depending on the state of the counterpart device with which it communicates, it may be possible to confirm normal reception of the communication partner after performing the same number of retransmissions each time. In this case, since the retransmission process is performed by software, the software load increases by the number of retries.

  In view of the above circumstances, an object of the present invention is to provide an asynchronous packet communication method and an asynchronous packet communication device that can reduce a system burden due to a request or a retry request in asynchronous packet communication.

  In order to solve the above-described problem, the asynchronous packet communication method of the present invention is characterized in that, in the method of performing asynchronous packet communication, the retry interval of a request when an error occurs is increased stepwise according to the number of error occurrences. To do. The asynchronous packet communication device according to the present invention is a device for performing packet communication asynchronously, wherein means for outputting a larger numerical value as the number of error occurrences is larger, and a retry interval of a request when an error occurs is stepped based on the numerical value. And a means for setting a long time. In such a configuration, the retry is not performed immediately and many times, and it is not a waiting for a fixed time, but the processing is to gradually increase the waiting time. It is possible to reduce the situation where the timing of acceptance is lost.

  The asynchronous packet communication method of the present invention is a method for performing asynchronous packet communication, wherein the request interval is increased as the number of nodes is increased. Further, the asynchronous packet communication device of the present invention is a device for performing packet communication asynchronously, a means for obtaining the number of nodes on the communication bus, a means for outputting a larger numerical value as the number of nodes increases, and a request interval. And a means for setting a long time based on a numerical value. With such a configuration, it is possible to avoid intensive requests from many connected devices all at once, reducing the system burden.

  In the above asynchronous packet communication method and apparatus, communication processing may be performed based on the IEEE 1394 standard.

  According to the present invention, there is an effect that it is possible to reduce a system load due to a request or a retry request in asynchronous packet communication.

  A digital broadcast receiver according to an embodiment of the present invention will be described below with reference to FIGS. In this embodiment, the present invention is applied to asynchronous packet communication based on IEEE 1394 and will be described on the assumption of a single-phase retry mode.

  First, FIG. 1 shows an example of a general hardware configuration that constitutes an IEEE 1394 module. The ROM 1 stores IEEE 1394 software. After the power is turned on, the IEEE 1394 software stored in the ROM 1 is expanded in the RAM 3 and the microcomputer (microcomputer) 2 executes the expanded IEEE 1394 software. The LINK chip 4 has a link function defined in IEEE Std 1394-1995. The PHY chip 5 is mounted with a physical layer defined by IEEE Std 1394-1995. In some cases, the LINK chip 4 and the PHY chip 5 are integrated into a single chip. By connecting a 1394 cable to the 1394 connector 6, the 1394 module is connected to the 1394 bus. The link layer of the IEEE 1394 software accesses the LINK chip 4 that is memory-mapped in the address space of the microcomputer, and transmits and receives asynchronous packets.

  FIG. 2 shows an example of an AV (audio / visual) IEEE 1394 protocol stack. The physical layer in this figure is handled by the PHY chip 5 equipped with the 1394 function. The link layer corresponds to the LINK chip 4 and the driver equipped with the 1394 function. The link driver constituting this link layer performs asynchronous packet transmission / reception unit, various state acquisition (node ID acquisition and the like) from the LINK chip 4, and event notification (bus reset occurrence notification and the like). In the transaction layer, request transmission and response reception, or association processing by transaction label of request reception and response transmission, and retransmission processing when a normal Ack packet cannot be received during packet transmission are performed.

  The serial bus management (SBM) layer implements Configuration-ROM that displays the GUID (VendorID and ChipID) and product name of the device itself, and responds if there is an inquiry from another device. The SBM layer includes an isochronous resource manager (IRM) and a bus manager (BM). The IRM performs channel management and bandwidth management of isochronous packets on the 1394 bus. The BM creates a topology map and a speed map at the time of bus reset, and responds to inquiries from other devices. An FCP (Function Control Protocol) layer performs processing such as AV command transmission and AV response reception standardized by IEC61883.

  In addition, for example, in the case of a television receiver with a built-in digital tuner that controls D-VHS, a module that uses an AV command requires a CMP layer, an AKE layer, a tape control layer, a tuner controlled layer, etc. above the FCP layer. Become. A CMP (Connection Management Procedures) layer performs connection management and obtains device information when a bus reset occurs. Mounting of PCR (Plug Control Register) is also performed in the CMP layer. In the AKE (Authentication and Key Exchange) layer, the copy-protected program content (TS: transport stream) is decrypted by performing authentication processing and key exchange of the counterpart device. In the tape control layer, AV commands for control or status acquisition specified in AV / C Tape Recorder / Player Subunit are implemented, remote control such as playback, fast forward, stop, tape counter acquisition, tape running status acquisition, Periodic monitoring using tape cassette information acquisition is performed. In the tuner controlled layer, AV / C Tuner Subunit necessary as a digital broadcast receiver is mounted.

  Each module layer constituting the AV protocol stack described above is realized by software, and each can perform independent and parallel processing. For this reason, different module layers may transmit and receive asynchronous packets at the same timing. In addition, other 1394 devices connected on the IEEE 1394 bus also transmit / receive asynchronous packets. It is expected that the more the IEEE 1394 devices connected on the IEEE 1394 bus, the more the timing at which asynchronous packet transmission / reception overlaps. If transmission of asynchronous packets overlaps and the counterpart device is already receiving asynchronous packets, the Ack code for the transmitted asynchronous packets is Ack_busy. The source transaction layer acquires an Ack code from the link layer, and performs retry processing a predetermined number of times in the case of Ack_busy. The maximum number of retries is a variable value defined as BUSY_TIMEOUTregister (0xFFFF, 0xF0000210) in IEEE Std 1394-1995.

  In the link layer, when performing asynchronous packet transmission, packet header information (transmission destination node ID, offset address, response code, transaction code, etc.) and packet data are set in a predetermined register, and then asynchronous packet transmission is performed. Since synchronization packets need to be transmitted at intervals as short as 125 μs per cycle, the software load would be very heavy if the driver was set every time. Therefore, normally only the header information of the synchronization packet is used with the LINK chip. Set up and process with hardware.

  In asynchronous packet transmission, every time retry transmission is performed, it is necessary to set the packet information to be transmitted in a register, which is a software burden. In this case, it is conceivable that the link layer and the transaction layer are integrated, the Ack code is determined while the packet information is stored in the register, and if Ack_busy, the retry transmission is immediately performed. However, when there are simultaneous transmission requests from a plurality of modules, the next transmission request is waited until the processing of the first transmission request is completed. On the other hand, if the Ack code is determined and the Ack_busy is detected and the retry transmission is simply performed for a while, the result notification to the module that issued the request later is delayed when there are multiple transmission requests.

  FIG. 3 shows a normal transaction example of an asynchronous packet. When a packet transmission request from the upper module comes to the transaction layer, an asynchronous packet transmission request (Request) is issued to the link layer. In the link layer, an asynchronous packet is transmitted to the communication partner (Request). When the link layer of the communication partner normally receives the asynchronous packet, it returns Ack_Complete (or Ack_Pending) to the transmission source (Response), and displays the received asynchronous packet on the receiving-side transaction layer (Indication). In the receiving-side transaction layer, packet reception indication (Indication) is given to the upper module according to the request content. On the other hand, when Ack_Complete (or Ack_Pending) is received at the link layer, the transmission side performs transmission confirmation (confirmation) of the asynchronous packet requested to be transmitted to the transmission side transaction layer. In the transaction layer, packet transmission confirmation (Confirmation) is performed to the upper module that is the packet transmission request source.

  FIG. 4 shows an example of an abnormal transaction of an asynchronous packet. When a packet transmission request from the upper module comes to the transaction layer, an asynchronous packet transmission request is issued to the link layer. In the link layer, an asynchronous packet is transmitted to the communication partner. However, when the link layer of the communication partner is communicating with, for example, another communication partner and the asynchronous packet of the other communication partner is being received, another asynchronous packet cannot be received. In this case, Ack_busyX is returned to the transmission source, and reception of asynchronous packets is not displayed on the reception-side transaction layer. When receiving the Ack_busyX, the transmission side link layer confirms transmission of the asynchronous packet to the transmission side transaction layer. If the transmission side transaction layer receives Ack_busyX and determines that the communication partner has not normally received the transmitted asynchronous packet, it issues a retry transmission request for the asynchronous packet to the link layer. When there is a retry transmission request, the link layer retransmits the asynchronous packet to the communication partner. When the link layer of the communication partner is still busy, Ack_busyX is returned to the transmission source. As described above, if the communication partner continues to be busy, the transmission source transaction layer repeatedly performs retry transmission, and when the maximum number of retries is exceeded, the transmission result of the retry over is returned to the transmission request source module. If necessary, the transmission request source module waits for a certain period and issues a transmission request to the transaction layer again.

  Next, a processing example when the present invention is applied to an asynchronous packet transmission unit of a transaction layer is shown in the flowchart of FIG. When the transaction layer receives an asynchronous packet transmission request from another module (step S1), the transaction layer initializes the number of retries (R) to 0, and sets a predetermined initial value for the retry interval (T1) (step S2). ). Next, an asynchronous packet transmission request is issued to the link layer (step S3), and an Ack code as a transmission result is acquired (step S4).

  When the Ack code is Ack_pending or Ack_complete (YES in step S5), it is returned to the transmission request source as normal transmission (step S6). When the Ack code is Ack_missing (YES in step S7), it is processed as Ack_missing (step S8). Ack_missing occurs when a transmission request is issued to a node ID that does not exist on the 1394 bus, or when an asynchronous packet is transmitted to a special node such as a bus analyzer. When an asynchronous packet is transmitted to a general 1394 device, Ack_missing cannot normally occur, but Ack_missing may occur when the link chip is in an abnormal state.

  If the Ack code is not one of Ack_pending, Ack_complete, and Ack_missing (NO in step S5, NO in step S7), the number of retries is checked (step S9). If the number of retries exceeds the maximum number of retries (YES in step S9), retry over occurs and processing is performed as abnormal transmission (step S10). If the number of retries has not reached the maximum number of retries (NO in step S9), retry transmission is performed after incrementing the number of retries (NO in step S11, step S14). However, when the Ack code is Ack_busy (YES in step S11: an error occurs), after waiting for the retry interval (T1), T ← T1 + ΔT (for example, ΔT = T1) can be set. Retry interval update processing is performed by calculation processing (not performed) (step S13), and the process proceeds to step S14. The update retry interval (time) increases according to the number of error occurrences. By performing such processing, the software load due to the retry can be reduced.

  That is, as described above, in the case of Ack_busy, if retry transmission is performed immediately, for example, it will be waited until the processing of other transmission requests that have already been performed, and the number of retries will increase unnecessarily, and the software load Will increase. On the other hand, simply waiting for a fixed time in the case of Ack_busy is likely to miss the timing at which the request is accepted. According to the present invention, since the retry is not performed immediately many times, and the waiting time is not increased for a fixed time, but the waiting time is increased stepwise, the number of retries is reduced (software It is possible to reduce the situation in which the timing at which the request is accepted is lost while reducing the load.

  By the way, in IEEE 1394, a bus reset occurs when the 1394 cable is connected or disconnected. The link driver that has determined that the LINK chip has entered an abnormal state generates a bus reset to restore the LINK chip to a normal state. A node ID is assigned to each node connected on the IEEE 1394 bus by the bus reset. When the IEEE 1394 device detects a bus reset, the IEEE 1394 device recognizes other IEEE 1394 devices connected to the IEEE 1394 bus.

  The IEEE 1394 device has a Configuration-ROM, in which device-specific information such as a GUID (VendorID and ChipID) and a product name described in text are described. Each IEEE 1394 device can obtain basic information of the counterpart IEEE 1394 device by reading a predetermined offset address described in the Configuration-ROM of the counterpart IEEE 1394 device. Further, in the case of an AV device, by issuing a subunit command, it is possible to acquire the subunit information mounted on the counterpart IEEE 1394 device. Immediately after the bus reset occurs, information on other IEEE 1394 devices to which each IEEE 1394 device is connected is acquired. In particular, when the number of nodes is large, the 1394 bus is likely to be congested because the other party's Configuration-ROM information is inquired and responded. Therefore, immediately after the bus reset, when the number of nodes is large, it is possible to acquire a normal response packet with a small number of retries by increasing the transmission retry interval of the device recognition asynchronous packet.

  FIG. 6 shows a flowchart when the present invention is applied to the device recognition unit. The device recognition unit operates by being driven by an event by a bus reset (step S21), performs initial setting of each parameter, and sets the counterpart node ID (I) to 0. Further, the node number information connected to the 1394 bus is acquired from the link layer, and the node number information is set to the node number (N). Also, the local node ID information is acquired from the link layer, and the local node ID information is set to the local node ID (M) (step S22).

  Next, in the conversion formula F (x), the number of nodes (N) is substituted for x, and the optimal transmission interval (T2) of asynchronous packets for device recognition is calculated (step S23). A conversion table may be employed instead of F (x). In the conversion table, for example, data obtained by the manufacturer through the bus reset test and accumulated through experience may be incorporated. In FIG. 7, the transmission interval (T2) is an interval until access to data “0404h” after access to data of a certain address, for example, “0400h”. Next, the counterpart node ID (I) is compared with the number of nodes (N) (step S24). If the counterpart node ID (I) is greater than the number of nodes (N), the process is terminated. If the counterpart node ID (I) is smaller than the number of nodes (N), the processing is continued. The partner node ID (I) and the own node ID (M) are compared (step S25). If they are equal, the partner node ID (I) is incremented (step S31), and the process returns to step 1.

  If the counterpart node ID (I) is not equal to the own node ID (M), it is determined whether the counterpart node ID (I) is active (step S26). Since there is active information of each node in the topology map possessed by the BM (bus manager), it can be determined by referring to the topology map. If the partner node ID (I) is not active, the partner node ID (I) is incremented (step S31), and the process returns to step 1. When the partner node ID (I) is active, the Node-I Configuration-ROM is sequentially read at intervals of T2 (step S27). Since there is no time limit for reading the Configuration-ROM after the bus reset in the standard, there is no problem even if it is slightly delayed as long as it is not extremely slow at the application level. However, if a bus reset occurs while a connection is established from the own node, it is necessary to perform a connection recovery process within a one-second time period called an “isochronous resource delay” after the bus reset occurs. Therefore, only the GUID information included in the Configuration-ROM must be pre-read if necessary.

  FIG. 7 shows a configuration example of the D-VHS Configuration-ROM (specific details are omitted). The Configuration-ROM includes an IEEE 1394 bus node, a corresponding upper protocol, GUID (company identifier VendorID and product identifier ChipID), textual descriptor indicating the company name, and textual indicating the model name. Descriptor and the like are described. The function of reading Configuration-ROM is implemented in the SBM (Serial Bus Management) layer of the AV protocol stack, and responds when an inquiry is received from the counterpart device. By reading the configuration-ROM of the counterpart device, it is possible to acquire the GUID, company name, model name, etc. of the counterpart device.

  When reading of the Configuration-ROM is normally completed (YES in step S28), unit information is acquired using the AV command of Node (I) (step S29). That is, unit information such as a subunit mounted on the counterpart device is obtained using the unit info / status command and the subunit info / status command. The obtained unit information is registered in the unit management table (step S30). If reading of the Configuration-ROM does not end normally (NO in step S28), or after registration in the unit management table after normal end, the partner node ID (I) is incremented (step S31). Return to.

  As described above, by performing processing according to the number of nodes, it is possible to avoid a state in which a normal response is obtained after many retries immediately after a bus reset, and it is possible to reduce software overhead due to retries. Specific examples of the above-described conversion formula F (x) include F (x) = 2x, or F (x) = T + 1.1x, where T is the initial value time. In short, the formula may be set so that the standby interval becomes longer as the number N of nodes increases. In the above example, the transmission interval T2 is variable by the conversion formula F (x). However, the retry transmission interval can be similarly variable by the conversion formula F (x).

It is the block diagram which showed the general hardware structural example which comprises the IEEE1394 module. It is explanatory drawing which showed an example of the protocol stack of AV (audio visual) system IEEE1394. It is explanatory drawing which showed the normal type | system | group transaction example of an asynchronous packet. It is explanatory drawing which showed the example of the abnormal system transaction of an asynchronous packet. It is a figure which shows embodiment of this invention, Comprising: It is the flowchart which showed the example of a process of the asynchronous packet transmission part of a transaction layer. It is a figure which shows embodiment of this invention, Comprising: It is the flowchart which showed the example of a process of the apparatus recognition part. It is explanatory drawing which showed the structural example of Configuration-ROM of D-VHS.

Explanation of symbols

1 ROM
2 Microcomputer 3 RAM
4 LINK chip 5 PHY chip 6 1394 connector

Claims (6)

An asynchronous packet communication method characterized in that, in an asynchronous packet communication method, a request retry interval when an error occurs is increased stepwise in accordance with the number of error occurrences. In an apparatus that performs asynchronous packet communication, the device includes means for outputting a larger numerical value as the number of error occurrences increases, and means for gradually setting a request retry interval when an error occurs based on the numerical value. An asynchronous packet communication device characterized by the above. In the asynchronous packet communication method, the request interval is increased as the number of nodes increases. In an apparatus for performing packet communication asynchronously, means for acquiring the number of nodes on the communication bus, means for outputting a larger numerical value as the number of nodes increases, and means for setting a request interval longer based on the numerical value, An asynchronous packet communication device comprising: 4. The asynchronous packet communication method according to claim 1, wherein communication processing is performed based on the IEEE 1394 standard. 5. The asynchronous packet communication apparatus according to claim 2, wherein communication processing is performed based on the IEEE 1394 standard.

Images