FR2819668A1 - Digital word transfer across two series bus interconnecting bridge having memorised write request reception date and determining first future date write response/sending local system prior date. - Google Patents

Abstract

The communications process between a local system connects to a first series and a remote system across a bridge. There are steps of reception (E501,E503,E507,E513) of a write request from a remote determination distance (E509) , determining adaptation. The write request reception date in the bridge is memorized (E527) and the first future date (E529) determined corresponding to the latest sending of the write response satisfying a time condition. A write response is sent to the local system before the determined date is passed.

Description

<Desc / Clms Page number 1>

 The present invention relates generally to the transfer of data through an interconnection bridge of two serial buses.

 More particularly, the invention relates to a method of communication between a local system connected to a first serial bus, and a remote system connected to a second serial bus, through an interconnection bridge, said local system not being suitable for the exchange of information across the bridge interconnecting the two aforementioned buses.

 The invention relates in particular to communication between systems through a bridge defined according to the IEEE 1394 standard connecting two local serial buses as defined by the IEEE 1394 standard.

 The invention also relates to an apparatus suitable for implementing such a communication method.

 The IEEE 1394 standard (hereinafter sometimes referred to as "IEEE 1394") defines a serial bus technology intended to interconnect consumer electronics products and computer systems, such as for example digital televisions, personal computers, digital video recorders, digital camcorders, printers, fax machines, etc. IEEE 1394 (sometimes referred to as firewire) defines isochronous and asynchronous communication modes for data transfer, which makes it ideally suited for multimedia applications.

 IEEE 1394 allows a maximum cable length or distance of 4.5 meters. Therefore, intrinsically an IEEE 1394 serial bus can only be used to interconnect elements that are relatively

<Desc / Clms Page number 2>

 close to each other. Such a system for interconnecting elements which are close to each other is commonly designated by segment or cluster.

 Furthermore, the IEEE 1394 bus architecture limits the number of nodes (ie connected systems) on a given bus to 63. There are currently several solutions for expanding the capabilities of an IEEE 1394 bus as part of a wired infrastructure. A major solution, currently still under discussion within the IEEE p1394 subgroup. 1 (hereinafter referred to as "p1394. 1" or "IEEE p1394. 1"), already makes it possible to extend the high performance serial bus (High Performance Serial Bus-IEEE 1394-1995) beyond the local bus, by means of a particular device: the bridge. According to IEEE p1394. 1, this solution consists in creating a "bridge" (bridge) wired between two different segments (clusters) based on serial bus. The interconnection bridge as defined by the IEEE p1394 subgroup. 1, will be in the following description designated by "IEEE1394 bridge". Such a bridge will be described later in connection with FIG. 1.

devices"en anglais. Dans la suite de la description, le terme anglais"legacy", qui pourrait être traduit en français par"existant", sera repris dans le présent mémoire afin d'éviter tout contresens avec le sens donné à ce terme, en anglais, dans l'état de la technique. According to IEEE p1394. 1, two types of systems or nodes are defined with respect to the above-mentioned bridge. On the one hand, the systems which are adapted to the bridge (in English bridge aware devices), and on the other hand, those which are not adapted to such a bridge (in English non bridge aware devices), called "legacy

devices "in English. In the remainder of the description, the English term" legacy ", which could be translated into French as" existent ", will be used in this brief in order to avoid any misinterpretation with the meaning given to this term, in English, in the state of the art.

 According to IEEE p1394. 1, legacy systems can successfully operate in a bridge environment with certain restrictions. Indeed, according to p1394. 1, legacy systems are assumed to be only write-only requesters. As such, they are limited to the generation of remote write transactions. Thus, remote read and lock transactions are prohibited and therefore rejected.

 However, bridges offer only limited compatibility with remote write transactions issued by legacy systems. Indeed,

<Desc / Clms Page number 3>

 when a legacy system sends a remote write transaction request, the bridge-more precisely its input port (inbound porta /) - accepts the request and sends an automatic response to the legacy system (write transaction response), indicating that the write request ended successfully, even before this write request reached its destination. When the write request finally reaches the destination node, the latter sends a write transaction response which is filtered at the bridge level and not processed.

The purpose of this process is to prevent the split transaction timeout at the source node (the legacy system) from expiring before the response from the destination node is received at the source node. In other words, what is aimed at is compatibility with an apparently short delay time in the legacy system. Legacy systems are not designed to initiate remote transactions. When such a system sends a write transaction request, it activates a local timeout (split timeout) of at least 100 milliseconds (ms) duration, thereby defining the minimum time interval to respect before developing a new request. This time delay is well suited to a local transaction. For a remote transaction, the source node must take into account the delays introduced by the bridge. This is the reason why the bridge's inbound portal immediately sends a message to the local node indicating that the writing has been successful (write response OKpacket).

On the contrary, systems designed to be adapted to IEEE1394 bridges (bridge aware devices), define a remote timeout which takes into account the delays introduced by the bridges. The remote time delay is at least double the local time delay.

On the other hand, the remote timing is dependent on the path followed, and a special bridge management message determines the remote timing for each remote node.

<Desc / Clms Page number 4>

The process of remote writing by a legacy system through an IEEE1394 bridge, as defined above, has a number of drawbacks. Thus, when errors occur in the communication between the bridge and the remote node (recipient), these errors can only be detected at the application level of the source node or of the destination node. On the other hand, the fact that the local node (sender) immediately and automatically receives a response (write transaction response) meaning that the read transaction has gone smoothly, allows the local node to issue new write transactions , which can, in the case where the path between the bridge and the node is in a situation of congestion, cause an overload or overflow of capacity (butter overflow) in the bridge. This remote writing process therefore prohibits error management and the management of buffer overflow management in the bridge.

 The aim of the present invention is therefore to solve the aforementioned drawbacks linked to the process, as currently defined by IEEE p1394. 1, to perform a remote write transaction from a local legacy node to a remote node, across a bridge.

 To this end, the present invention relates, according to a first aspect, to a communication method between a local system connected to a first serial bus, and a remote system connected to a second serial bus, through a bridge interconnecting the two buses, the local system may not be suitable for exchanging information across the bridge. The method includes the prior steps of receiving a write request sent by the local system to the remote system and determining the type of the local system sending the write request. The method is remarkable in that, if the local system is determined not to be suitable for exchanging information across the bridge, it comprises the following steps: - memorization of the date of reception (Date-Reception) of the request writing in the bridge; - determination of a first future date (DateMax) defined in relation to said date of receipt (Date-Receipt), and corresponding to the date

<Desc / Clms Page number 5>

 the later one to send a write response to the local system, so as to satisfy a predetermined timeout condition for the local system; - sending a write response to the local system, at the latest when the first date (DateMax) has passed.

(DateMax) à partir de la réception de la requête d'écriture, pour l'envoi d'une réponse d'écriture au système local, on laisse un laps de temps plus important pour donner, par exemple, la possibilité au destinataire d'envoyer une réponse réelle. In this way, by determining a future time limit

(DateMax) from the receipt of the write request, for sending a write response to the local system, a longer period of time is left to give, for example, the recipient the possibility of send an actual response.

 In a preferred embodiment of the invention, the bridge and the buses conform to the 1 EEE p1394 standard. 1; and the local system, which is not suitable for the exchange of information across the bridge, is of the "legacy" type within the meaning of the IEEE p1394 standard. 1.

 The IEEE p1394 standard. 1 is in fact particularly suitable for implementing the invention.

 The interconnect bridge includes an input port connected to the first bus and an output port connected to the second bus. According to a preferred implementation of the invention, the step of sending a write response to the local system comprises the following steps: - verification that the first date (DateMax) has passed or not; - if so, sending a write response to the local system; - otherwise, determine a second future date (DateMax2) between the date of receipt (Date-Reception) of the write request and the first date (Date ~ Max), the second date being all the closer to the date receiving the request that the data flow between the input port and the output port of the bridge is weak; - sending a write response to the local system, at the latest when the second date (Date ~ Max2) has passed.

 By recalculating the latest future date (Datemax2) to which to send a response to the local system, according to the intensity of the traffic (data flow) between the input port and the output port of the bridge, this allows

<Desc / Clms Page number 6>

 "slave" the speed of sending the response to the local system as a function of this traffic, while respecting the time-out condition coded for the local system.

 In practical terms, the predetermined timeout condition for the local system (legacy) is defined by a local timeout value (DTV) predetermined for this system and determining the maximum time interval between the reception of the write request by the port of entry and sending a write response to the local system.

 According to a preferred embodiment of the invention, the first date (Date ~ Max) determined by the input port of the bridge, is obtained by the following equation: Date-evils = Date-Reception + DTV where DTV represents the predetermined local timeout value assigned to the local system, and Date-Receive is the date of receipt of the write request to the bridge.

On the other hand, the second date (Date ~ Max2) is obtained by the following equation: Date ~ Max2 = Date-evils + (k-1). DTV
Where k is a real number between 0 and 1, the value of which depends on the size of the data flow between the input port and the output port of the bridge.

 According to a preferred embodiment of the invention, the data flow between the input port and the output port of the bridge is measured by calculating the filling rate of a queue intended to temporarily store the packets data intended to be transferred from the input port to the bridge output port.

 The choice of this queue, as an indicator of the intensity of the packet traffic between the port of entry and the port of exit of the bridge, makes it possible to estimate this traffic in a faithful manner compared to reality.

 On the other hand, according to a particular embodiment characteristic, the number k is chosen equal to the filling rate of this queue.

 According to an alternative embodiment, the number k is chosen equal to a predetermined threshold value, when this is reached by the filling rate of the queue.

<Desc / Clms Page number 7>

 According to another preferred embodiment of the invention, provision may be made to monitor in the bridge, the reception of a write response from the remote recipient system, and to transmit this write response immediately to the local system, before even if the first date (DateMax) has passed or before the second date (Date ~ Max2), when determined, has passed.

 Thus, the reception of an actual write response from the destination node, immediately triggers the transmission of this response to the local system.

 Correlatively, according to a second aspect, the present invention relates to a communication device implemented in a bridge, for communication between a local system connected to a first serial bus, and a remote system connected to a second serial bus, through the bridge interconnecting the two buses, the local system may not be suitable for exchanging information across the bridge. This device is remarkable in that it comprises means adapted to the implementation of a communication method as succinctly defined above.

 The invention also relates to an interconnection bridge comprising means suitable for implementing the communication method according to the invention.

 The present invention also relates to a computer program capable of implementing the communication method as briefly defined above, when the program is loaded and executed in a computer system incorporated in the interconnection bridge.

 The invention also relates to an information medium, such as for example, a floppy disk or a compact disc (CD) containing such a computer program.

 The advantages of this device, interconnection bridge, computer program, and of this information medium, are identical to those of the communication method as succinctly explained above.

 Other features and advantages of the invention will appear in the description below.

<Desc / Clms Page number 8>

 In the accompanying drawings, given by way of nonlimiting exemplary embodiments: FIG. 1 is a block diagram representing the architecture of an IEEE1394 bridge making it possible to interconnect two subnetworks each built around an IEEE1394 serial bus; - Figure 2 shows the format of the identifier of a node on an IEEE1394 serial bus; - Figure 3 shows the format of a data packet defining an asynchronous transaction according to the IEEE 1394 standard; - Figure 4 illustrates, according to the IEEE p1394 standard. 1, the process of processing by an IEEE1394 bridge a remote write request sent by a legacy system; - Figure 5 is a flowchart representing, in accordance with the invention, the process of processing an asynchronous packet (as shown in FIG. 3) received in an input port of an IEEE1394 bridge; - Figure 6 is a flowchart representing the process, according to the invention, of determining a date of sending by an input port of an IEEE1394 bridge of a write response to a legacy system.

 We will first describe, with reference to Figure 1, the architecture of an IEEE1394 bridge to interconnect two subnets each built around an IEEE1394 serial bus. The assembly: bridge (1) -subnets (2,3), constitutes a network designated here by IEEE1394 network.

 As shown in FIG. 1, an IEEE 1394 serial bus interconnection bridge 1, is used to interconnect two subnets 2 and 3 built respectively around an IEEE1394, 21 serial bus and an IEEE1394, 31 bus.

Subnet 1 includes a tEEE1394 system, "node 1" (20), connected to bus 21, while subnet 3 includes a tEEE1394 system, "node 2" (30), connected to bus 31. The bridge 1 allows interconnection between the 2 buses 21 and 31.

 Bridge 1 has two ports (porta4 input / output (I / O) 11 and 12. Each of ports 11 and 12 has functions for receiving, transmitting and managing data packets. These functions are

<Desc / Clms Page number 9>

 distributed in different functional layers: physical layer (111, 121), link layer (112, 122) and transaction layer (113, 123). These layers can consist of hardware (hardware) and / or software (software) elements. Each of the ports 11 and 12 also includes a port control unit (114, 124) gathering a series of control and status registers for the port considered as well as for the abovementioned functional layers.

 The bridge 1 also comprises a switching unit 13 (switching fabric) which can use a wired technology such as, for example, that defined by the IEEE 1394b standard; or a wireless technology such as, for example, that defined according to the standard known as "HiperLAN 2", or that defined by the IEEE 802 standard. 11a.

 The switching unit 13 is associated with queues (queues) 131,132 of FIFO type (first-in-first-out) to queue data packets of asynchronous or isochronous type. The switching unit thus allows the two I / O ports 11 and 12 to communicate.

 Bridge 1 further comprises a clock cycle unit 115 which makes it possible to define a method for distributing the clock to the 2 I / O ports 11 and 12. Bridge 1 also comprises a routing table 116 and a configuration memory 117 of ROM memory type (read only memory).

 Each port 11,12 of the bridge 1 is associated with an address which uniquely identifies it on the bus (21,31) to which it is connected. Each of the ports 11, 12 is designed to respond to different types of requests sent by IEEE1394 systems connected to the corresponding bus. These requests are, for example, read, write, and lock requests. For this purpose, each port (11,12) uses routing tables stored in the unit 116 to determine the transactions which must be transmitted, through the switching unit 13, to the other port of the bridge. The switching unit 13 is thus capable of transferring any transaction from one port to the other port of the bridge.

<Desc / Clms Page number 10>

Each node "1EEE1394", such as node 1 or node 2, is defined on the bus (21, 31) to which it is connected, by a node identifier "node / D" which includes a bus identifier (10 bits long), "bus ID", identifying the bus to which it is connected, and a physical identifier (6 bits of ong), "phy ~ ID", physically identifying the node on the bus. Figure 2 represents the format d such a node identifier on an IEEE1394 bus.

 In the context of the present invention, the exchange of asynchronous packets is considered over an IEEE1394 bridge. Indeed, an IEEE1394 node or system (21,31) can exchange asynchronous data packets, called transactions.

- un champ"Destination/D" (16 bits) contenant l'identificateur de noeud (node/D) identifiant le noeud destinataire de la transaction ; - un champ"tcode" (transaction code) définissant le type de la transaction (lecture, écriture...) ; - un champ "tl" (transaction label) destiné à recevoir une étiquette permettant d'identifier la transaction considérée parmi d'autres transactions. Figure 3 represents the format of a data packet defining an asynchronous transaction according to the IEEE 1394 standard. As we can see in this figure, the header of an asynchronous packet includes among others: - a "Source" field / D "(16 bits) containing the node identifier (node ~ ID) identifying the node sending the transaction;

- a "Destination / D" field (16 bits) containing the node identifier (node / D) identifying the node receiving the transaction; - a "tcode" field (transaction code) defining the type of transaction (read, write ...); - a "tl" field (transaction label) intended to receive a label making it possible to identify the transaction considered among other transactions.

 An IEEE1394 bridge ignores all transactions that take place between nodes with a local address on the same bus, but monitors and takes into account only remote transactions between two nodes or systems whose node identifiers (node-ID) indicate (field bu (s / D) a bus of different membership.

 According to the IEEE p1394 standard. 1, an IEEE1394 bridge is capable of knowing the state of each of the nodes connected to each of the local serial buses which it interconnects. For this purpose, a legacy device discovery process is executed in each port of the considered bridge, after each bus reset procedure. At

<Desc / Clms Page number 11>

 during this process, each port of the bridge retrieves, from each of the nodes connected to the local bus to which it is connected, a packet of node identification data (Self lD packet), allowing the port to know the identifier physical (phy ID) of the node, as well as its functionality. In particular, the considered port of the bridge reads and stores for each node a bus information block (BIB-bus information block) making it possible to identify its "legacy 'or adapted (bridge aware) character as defined above. The bus information block (BIB) is read in a ROM-type configuration memory present in each of the nodes connected to the local bus considered.The block BIB notably includes a bit "b" determining the character "/ egacy" of the node considered, when this bit takes the value "0".

 After having identified all legacy systems, the port (portal) considered must read the content of a register present in each of the identified legacy systems. This register, designated by "local timeout register" (STR-split timeout register) contains a default timeout value (DTV), applicable to the detection of local transaction errors (split transaction errors), c . -to-d. transactions made between two nodes attached to the same bus. When each of the I / O ports of the interconnect bridge has collected and stored locally (in its control unit) the local timeout value (split timeout value) for each node on the corresponding local bus, the data transfer to the across the bridge can be initiated and ports can then filter transactions originating from a legacy system.

 As mentioned above, the default local timeout value, stored in the STR register of each legacy system, is originally suitable for local transactions (on the same bus), and therefore it is relatively low (around 100 ms).

However, according to the standard! EEA p1394. 1 this local timeout value is also used for remote transactions across a bridge. More specifically, for a given legacy system having sent a remote transaction request, the default local timeout value (default timeout va / ue-DTV) defines the period of time within which

<Desc / Clms Page number 12>

la réponse à cette requête doit être reçue par le système legacy. Après cette période de temps, le noeud émetteur de la requête est sensé terminer la transaction, et peut, si nécessaire, envoyer une requête de"nouvel essai" (retry request).

the response to this request must be received by the legacy system. After this period of time, the node sending the request is supposed to complete the transaction, and can, if necessary, send a "retry request".

 The present invention relates to remote communication, through an IEEE1394 bridge, between a first legacy system connected to a first IEEE1394 bus and a second system connected to a second IEEE1394 bus. Thus in FIG. 1, it is considered, in the following description, that the node 20 connected to the bus 21 is a legacy type system, transmitting transaction requests to the node 30 connected to the bus 31, through the interconnection bridge 1. With the sense of communication thus defined, i.e. from node 2 to node 3, I / O port 11 of bridge 1 is called "inbound portal" and I / O port 12 is called "outbound portal" ).

 As mentioned above, each port on the bridge monitors the transactions that are sent on the local bus to which it is attached. Port 11 for example, filters the transaction requests which are sent on the local bus 21 by analyzing the "Source ~ ID" and "Destination ~ ID" fields present in the header of an asynchronous data packet (cf. FIG 3) transiting on the local bus 21. A transaction is then interpreted as a remote transaction if the Destination-in field does not correspond to the port considered.

 Figure 4 illustrates, according to the IEEE p1394 standard. 1, the process of processing by an IEEE1394 bridge a remote write request sent by a legacy system. As shown in FIG. 4, as soon as the legacy system 420 (legacy requester) sends a remote write request 401 to a remote node 435, it triggers the countdown of the timeout (defaulttimeout value) defined in its local timeout register (STR) .

When the write request 401 is received by the input port (inbound portal) 425, the latter immediately sends to the legacy requester a message 402 signifying "acknowledgment in progress" (acknowledgment pending). Then the input port 425 generates and sends, before the expiration of timer 409 (eg 100ms), to the legacy system a write response 403 (write transaction response)

<Desc / Clms Page number 13>

 "artificial" indicating that the request has ended successfully, although it has not yet been received by the destination node (435). The legacy system receiving this artificial write response, before the timeout expires, replies with a message 404 signifying "Acknowledgment complete" thus terminating the write transaction.

 The write request 401, for its part, is processed in the following manner by the bridge. The request is first transmitted to the output port (outbound portaf) 430, via the switching unit (FIG. 1,13). The output port 430 then transmits the request 401, via the bus to which it is connected, to the destination system 435. The latter then receives the request 401 after a delay time due to the transmission. The IEEE p1394 standard. 1 then provides two possibilities 410,411 for further processing.

 According to a first possibility (410), the destination node 435 replies to the output port (430) with a message 405 "Acknowledgment complete" signifying that the processing request has been received; the output port 435 then generates a write transaction response 407 which is then transmitted to the input port 425. The system being of legacy type, this write response is finally ignored by the input port.

 According to a second possibility 411, the recipient node, after receiving the write request, replies by sending a message 406 "acknowledgment in progress" (acknowlegment pending). After processing the write request, the destination node generates a write response 407 which it transmits (via the bus) to the output port. The latter receives the response and replies by sending a "complete acknowledgment" message 408 to the destination node.

Then, the output port 430 transfers the write response 407 to the input port 425 of the bridge that receives it. As in the first possibility, the input port 425 ignores the write response 407 transmitted to it by the output port.

In fact, in both cases, the input port 425 had already generated and sent to the requesting node 420, an "artificial" write response 403, before the timer, coded in the local timer register (STR) of the legacy system 420, is not expired.

<Desc / Clms Page number 14>

 It should be noted that the distinction between the input port / output port of the bridge is only made relative to the direction of transmission of the initial write transaction request.

 Each legacy or non-legacy type system, connected to a given bus, further includes a register, called "cycle time register-CTR" containing a time value making it possible to define a date common to all the nodes. present on the bus. This CTR register is clocked by a quartz-based hardware clock present in the device. In a preferred implementation, this clock has a frequency of 24.576 MHz. Periodically the time value contained in each CTR register is synchronized by a clock master system (clock master) present on the bus. In this way, each system present on the bus has the same time reference. Likewise, each of the bridge ports has a CTR register storing the current time value.

 In connection with FIG. 5, we will now describe the process according to the invention for processing an asynchronous packet (as shown in FIG. 3) received in an input port of an IEEE1394 bridge.

 The process of processing a packet begins with the reception of a packet (step E501) in the input port of the port, the packet coming from the IEEE1394 bus attached to the input port of the bridge. After reception of the packet, the header of the packet (cf. FIG. 3) is analyzed so as to determine the nature of the transaction which is the subject of the packet. Thus the transaction is of remote type, if the Destination-in field does not correspond to the input port. Furthermore, the nature of the transaction (request or response) is determined by analyzing the tcode field of the packet header. Finally by analyzing the Source-in field of the packet header, the type (legacy or not) of the packet sender node can be determined. The reception of packets in the input port, as well as the sending of packets, is ensured by reception / transmission means incorporated in the functional transaction layer 113 of the input port.

 Back to FIG. 5, in step E503, after analysis of the packet header, if the transaction is not a remote transaction, c. -to-d. speaking to

<Desc / Clms Page number 15>

 a node accessible via the second IEEE1394 bus attached to the output port of the bridge, it is determined (E505) if the destination is the input port itself. If so, the packet is transferred (E521) to the transaction layer (FIG.

1,113) from the port of entry for treatment. If this is not the case, it may be a packet routing error, the packet is then discarded (E519).

 Conversely, if the transaction object of the packet is a remote transaction (E503, branch YES), then depending on whether the transaction is of the "request" type or not (E507) different processing is applied. Thus, if the transaction is not a request but a response (E511, YES branch), the packet is transferred to the output port of the bridge to be routed (E517) to its destination. If the transaction is neither a request nor a response (E511, branch NO), then it is certainly an erroneous message and the packet is deleted (E519).

 If on the contrary the transaction is of request type (E507, YES), it is then determined whether the sending node of the packet is a legacy system or not. The bridge input port (unbound portal) has for this purpose a table located in its control unit (114), in which are stored the identifiers (node / D) of all legacy type nodes connected to the bus attached to the port of entry.

 If the sending node is not a legacy type system (E509, NO), the request is then transferred (E515) to the bridge's outbound portal to be routed to its recipient.

 If the sending node is a legacy system (E509, YES) then it is determined (E513) if the request is a write transaction request. If this is not the case, the packet (E523) is deleted because only write requests from legacy devices can be processed by the bridge.

 If, on the contrary, it is a write request (E513, YES), then we begin by transferring the request to the output port (E525) so that the request is forwarded to its recipient. Then, in step E527, in accordance with the invention, the determination and storage of the date of reception of the write request is carried out in the input port of the bridge. To this end, the

<Desc / Clms Page number 16>

 current date noted "Date ~ Current" is read in the CTR register of the port of entry, ie. the "cycle time register" containing the current time value common to all the nodes present on the bus. The CTR register is located in the port control unit (114). The current date "Date ~ Current" read which corresponds to the date of reception of the request is then memorized in a variable noted "Date ~ Reception". The determination and storage of the date of reception of the write request are carried out by suitable means, in practice software means (programs) whose code is stored in the control unit (114) of the port.

 Still at step E527, the default timeout value DTV is read, relating to the legacy node at the origin of the write request. As mentioned earlier, this DTV timer value is read from a memory location located in the input port control unit. This timeout value initially comes from the STR (split timeout register) register contained in the sending legacy system.

 In the next step (E529), in accordance with the invention, a future date noted "Date ~ Max" corresponding to the latest date to which to send to the local system is determined (ie -d. the legacy node sending the write request) a write response, so as to satisfy the predetermined time-out condition for the local system. The determination of the future date is, in practice, carried out by software means (ie programs), the code of which is stored in the control unit (114) of the port.

 In other words, according to the invention, the write response is sent to the local system, at the latest when the date "Date ~ Max" has passed. The predetermined timeout condition for the sending local system is defined by the predetermined local timeout value (DTV), initially stored in the system's STR register, determining the maximum time interval between receipt of the request.

<Desc / Clms Page number 17>

 write by the input port and send by the latter a write response to the local system.

"DateMax"est obtenue par l'équation suivante : Date-maux = Date-Réception + DTV (1)
A l'étape finale E531, L'en-tête du paquet, permettant d'identifier de manière unique la requête d'écriture, est stockée dans une file d'attente localisée dans l'unité de contrôle 114 du port d'entrée. Cette file d'attente est appelée ici"file d'attente legacy". En pratique il s'agit d'une file d'attente de type

FIFO (first in first out). La date"Date~Max"est également sauvegardée, associée avec l'en-tête de la requête, dans la file d'attente legacy. La file d'attente legacy mémorise ainsi temporairement un identificateur (en-tête du paquet associé à la date Date-maux correspondante) de chaque requête d'écriture distante en cours de traitement, dont l'émetteur est en dispositif legacy. According to the invention, the future date "DateMax" is obtained by adding to the date of reception (Date-Reception) obtained the time value DTV relating to the local system. So the future date

"DateMax" is obtained by the following equation: Date-evils = Date-Reception + DTV (1)
In the final step E531, the packet header, making it possible to uniquely identify the write request, is stored in a queue located in the control unit 114 of the input port. This queue is called here "legacy queue". In practice, this is a type queue

FIFO (first in first out). The date "Date ~ Max" is also saved, associated with the request header, in the legacy queue. The legacy queue thus temporarily stores an identifier (header of the packet associated with the corresponding date-bad date) of each remote write request being processed, the transmitter of which is in legacy device.

 The legacy queue is periodically tested by the control unit (114) of the input port, for example every time corresponding to 10% of the default local timeout value (DTR) of a system. legacy, so as to determine for each write request identified in the queue, the time (i.e. date) at which to send a write response to the node making the request d 'writing.

 Referring to Figure 6, we will now describe in detail, the process according to the invention for determining an optimal date of sending, by the input port of the bridge, of the write response to the legacy system. .

 This process begins with a test step E601, in which it is determined whether the legacy queue is empty or not. If this is the case (YES), we remain in the queue test state. Otherwise, if the queue is not empty, in the next step (E603), a write request is identified identified in the queue (by its header).

<Desc / Clms Page number 18>

Then, in step E605, we read the current date (Current Date) in the CTR register of the input port, and we read, in the queue, the date Date-evils associated with the head of the identified write request.

 In the following step (E607), it is verified that the date Date ~ Max determined for the identified write request has passed or not. For this purpose, the current date, read in the previous step, is compared to the Date ~ Max date. If the date Date-evils has passed, c. -to-d. if the current date is greater than or equal to Datetvtax, then a write response is sent (E609) to the local system sending the write request. In reality, two cases can occur: either a write response has already arrived from the destination node, in which case this response is sent to the local system; or no response has been received from the destination node, and in this case the input port itself generates a write response as if this response came from the destination node.

 Then, it is determined, in step E617, whether the write request being processed (current write request) is the last one in the queue. If this is the case, we return to step E601 to test the state of the queue. If not, we return to step E603 to select another write request identified in the legacy queue.

 Back to step E607, if the date Date-evils corresponding to the current writing request has not yet passed (current date less than Date ~ Max), then during the following steps, E611 and E613, a second future date is determined, denoted "Date ~ Max2", between the date of reception (Date-Reception) of the current writing request and the date Data ~ Max. As will be detailed below, this second date, Date ~ Max2, is all the closer to the date of receipt of the write request, as the data flow between the input port and the port of exit from the bridge is weak.

 To this end, in step E611, a coefficient k is first calculated (k real number between 0 and 1) whose value is a function of the importance of the data flow circulating between the input port and the bridge exit port. AT

<Desc / Clms Page number 19>

l'étape suivante, E613, on calcule la date Date~Max2, en appliquant l'équation suivante : Date~Max2 = Date-maux + (k-1). DTV (2) où DTV représente la valeur prédéterminée de temporisation locale affectée au système local.

the next step, E613, the date Date ~ Max2 is calculated, by applying the following equation: Date ~ Max2 = Date-evils + (k-1). DTV (2) where DTV represents the predetermined local timeout value assigned to the local system.

According to a preferred embodiment of the invention, the data flow between the input port and the output port of the bridge is measured by calculating the filling rate of a queue (distinct from the queue d 'legacy wait') whose function is to temporarily store the data packets intended to be transferred from the input port to the output port of the bridge.

In this embodiment, according to a first alternative embodiment, the value of the coefficient k is determined to be equal to the filling rate of the aforementioned queue, implemented between the input port and the output port of the bridge.

According to a second alternative embodiment, the value of the coefficient k is determined to be equal to a predetermined threshold value, when the latter is reached by the filling rate of the queue. For example, if the filling rate of the queue is measured as being greater than 0.5, (threshold value chosen) then the value of the coefficient k is equal to this threshold value: 0, 5. In the case otherwise, i.e. if the filling rate is less than 0.5, then the value of k is set to zero.

Back to FIG. 6, once the second date, DateMax2 has been calculated (step E613), in the next step, E615, it is determined whether the date Date ~ Max2 has passed or not. For this, we compare Date ~ Max2 with the current date (from the CTR register). If the current date (Current Date) is greater than or equal to the date Date ~ Max2, then this means that it has just passed, in this case we go again to step E609 to send a write response to the local system. As before, two cases can occur: either a write response has already arrived from the destination node, in which case this response is sent to the local system; either no response has been received from the destination node, and in this case the input port itself generates a write response as if this

<Desc / Clms Page number 20>

 response came from the recipient node. In this way, a write response is sent to the local system, at the latest when the second date DateMax2 has passed.

 If on the contrary, the date Date ~ Max2 has not yet passed (Current Date less than DateMax2), then we do not yet send a write response, and we go to step E617 to determine if the request write in progress (current write request) is the last in the queue, as explained above.

 According to another preferred embodiment, a write response from the destination node is monitored in the bridge for the arrival in the output port. As soon as the arrival of this response is detected, even before the first date (Date ~ Max) has passed or before the second date (Date ~ Max2), when it is determined, has passed, the response of write is immediately transmitted to the local system issuing the initial write request.

 Of course, many modifications can be made to the embodiments of the invention described above without departing from the scope of the invention. In particular, although the embodiments described here apply to the IEEE 1394 standard, the invention generally applies to any other standard of serial bus and bus interconnection bridge, including the mode of communication of information is similar to that described in the context of the IEEE 1394 standard.

Claims (15)

 the request to write to the bridge; - determination (E529) of a first future date (DateMax) defined with respect to said reception date (Date-Reception), and corresponding to the latest date on which to send a write response to said local system, satisfying a predetermined timeout condition for said local system; - sending a write response to said local system, at the latest when said first date (Date ~ Max) has passed.

 CLAIMS 1. Communication method between a local system (20) connected to a first serial bus (21), and a remote system (30) connected to a second serial bus (31), through an interconnecting bridge (1) said buses, said local system (20) possibly not being suitable for exchanging information across said bridge, the method comprising the prior steps of receiving (E501, E503, E507, E513) of a write request sent by said local system intended for said remote system and for determining (E509) the type of said local system sending the write request, the method being characterized in that, if the local system is determined as not being suitable for the exchange of information through said bridge, it comprises the following stages: - memorization (E527) of the date of reception (Date ~ Reception)  2. Method according to claim 1, characterized in that said bridge and said buses conform to the IEEE p1394 standard. 1 and said local system, which is not suitable for exchanging information through said bridge, is of the "legacy" type within the meaning of the IEEE p1394 standard. 1.  3. The method of claim 1 or 2, wherein said bridge comprises an input port connected to said first bus and an output port <Desc / Clms Page number 22>  connected to said second bus, characterized in that the step of sending a write response to said local system comprises the following steps: - checking (E607) that said first date (Datetvtax) has passed or not; - if this is the case, sending (E609) a write response to the local system; - otherwise, determine (E611, E613) a second future date (Date ~ Max2) between said date of receipt (Date-Reception) of the writing request and said first date (Date ~ Max), said second date being d 'the closer the said date of receipt of the request that the data flow between the input port and the output port of the bridge is weak; - sending (E617, E609) of a write response to said local system, at the latest when said second date (Date ~ Max2) has passed.  4. Method according to any one of claims 1 to 3, characterized in that if a write response is received in the bridge from said remote system, before said first date (DateMax) has passed or before said second date (Date ~ Max2), when it is determined or passed, the write response is immediately transmitted to the local system.  5. Method according to any one of claims 1 to 4, characterized in that said predetermined timeout condition for said local system is defined by a predetermined local timeout value (DTV) determining the maximum time interval between the reception of the write request by the input port and the sending by the latter of a write response to the local system.  6. Method according to claim 5, characterized in that said first date (DateMax) is obtained by the following equation: Date ~ Max = Date-Reception + DTV where: <Desc / Clms Page number 23>

DTV represents the predetermined local timeout value assigned to the local system, and Date-Receive is the date of receipt of the write request to the bridge. 7. Method according to claim 6, characterized in that said second date (DateMax2) is obtained by the following equation: Date ~ Max2 = Date-maux + (k-1). DTV where: DTV represents the predetermined local timeout value assigned to the local system, and k is a real number between 0 and 1, the value of which depends on the amount of data flow between the input port and the output port of the bridge.  8. Method according to any one of claims 3 to 7, characterized in that the data flow between the input port and the output port of the bridge is measured by calculating the filling rate of a queue of standby intended to temporarily store the data packets intended to be transferred from the input port to the output port of the bridge.  9. Method according to claim 8, characterized in that the number k is equal to the filling rate of said queue.  10. Method according to claim 8, characterized in that the number k is equal to a predetermined threshold value, when this is reached by the filling rate of said queue.  11. Communication device implemented in a bridge, for communication between a local system (20) connected to a first serial bus (21), and a remote system (30) connected to a second serial bus (31), at across said bridge (1) interconnecting said buses, said local system (20) possibly not <Desc / Clms Page number 24>  (Date ~ Receipt) of the write request in the bridge; means for determining (113) a first future date (DateMax), defined as being the latest date on which to send a write response to said local system, so as to satisfy a predetermined timeout condition for said system local; - Means for sending (113) a write response to said local system, at the latest when said first date (Datetvtax) has passed.

 not be suitable for exchanging information across the bridge, said device being characterized in that it comprises: - means for receiving (113) a write request sent by said local system intended for said remote system and for determining (113) the type of said local system sending the write request; - means for memorizing (114) the date of receipt  12. Device according to claim 11, characterized in that said bridge and said buses conform to the IEEE p1394 standard. 1 and said local system, which is not suitable for exchanging information through said bridge, is of the "legacy" type within the meaning of the IEEE p1394 standard. 1.  13. Device according to claim 11 or 12, characterized in that it comprises means suitable for the implementation of a method as claimed in claims 3 to 10.  14. IEEE 1394 serial bus interconnection bridge, characterized in that it comprises a device in accordance with any one of claims 11 to 13.  15. IEEE 1394 serial bus interconnection bridge, characterized in that it includes means suitable for implementing a communication method according to any one of claims 1 to 10.