FR2819668A1

FR2819668A1 - Procede et dispositif de communication entre un noeud local connecte a un premier bus serie ieee 1394 et un noeud distant connecte a un second bus serie ieee 1394 au travers d'un pont d'interconnexion de bus

Info

Publication number: FR2819668A1
Application number: FR0100677A
Authority: FR
Inventors: Mohamed Braneci; Pascal Rousseau; Patrice Nezou
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2001-01-18
Filing date: 2001-01-18
Publication date: 2002-07-19
Anticipated expiration: 2021-01-18
Also published as: FR2819668B1

Abstract

Un procédé de communication entre un système local (20) connecté à un premier bus série (21), et un système distant (30) connecté à un second bus série (31), au travers d'un pont (1) interconnectant lesdits bus, le système local (20) pouvant être non adapté à l'échange d'informations au travers du pont, le procédé comportant les étapes préalables de réception (E501, E503, E507, E513) d'une requête d'écriture émise par le système local à destination du système distant et de détermination (E509) du type du système local émetteur de la requête d'écriture, le procédé étant remarquable en ce que, si le système local est déterminé comme étant non adapté à l'échange d'informations au travers du pont, il comporte les étapes suivantes de : mémorisation (E527) de la date de réception (Date_Réception) de la requête d'écriture dans le pont; détermination (E529) d'une première date future (Date_Max) définie par rapport à la date de réception, et correspondant à la date la plus tardive à laquelle envoyer au système local une réponse d'écriture, de manière à satisfaire une condition de temporisation prédéterminée pour le système local; envoi d'une réponse d'écriture au système local, au plus tard lorsque la première date (Date_Max) est passée. L'invention concerne également un dispositif apte à mettre en oeuvre le procédé précité. L'invention est particulièrement adaptée à son utilisation dans le cadre du standard IEEE 1394.

Description

La présente invention concerne de manière générale le transfert de données au travers d'un pont d'interconnexion de deux bus séries.

Plus particulièrement, l'invention concerne un procédé de communication entre un système local connecté à un premier bus série, et un système distant connecté à un second bus série, au travers d'un pont d'interconnexion, ledit système local étant non adapté à l'échange d'informations au travers du pont interconnectant les deux bus précités.

L'invention concerne en particulier la communication entre des systèmes au travers d'un pont défini selon le standard IEEE 1394 reliant deux bus série locaux tels que définis par le standard IEEE 1394.

L'invention concerne également un appareil adapté à la mise en oeuvre d'un tel procédé de communication.

Le standard IEEE 1394 (ci-après parfois désigné par"IEEE 1394") définit une technologie de bus série destiné à interconnecter des produits d'électronique grand public et des systèmes informatiques, tels que par exemple des télévisions numériques, des ordinateurs personnels, des magnétoscopes numériques, des caméscopes numériques, des imprimantes, des télécopieurs, etc. IEEE 1394 (parfois désigné par firewire) définit des modes de communication isochrone et asynchrone pour le transfert de données, ce qui le rend idéalement adapté aux applications multimédia.

IEEE 1394 autorise une longueur ou distance maximum câblée de 4,5 mètres. Par conséquent, intrinsèquement un bus série IEEE 1394 peut seulement être utilisé pour interconnecter des éléments qui sont relativement

proches les uns des autres. Un tel système pour interconnecter des éléments qui sont proches les uns des autres est couramment désigné par segment ou grappe (en anglais cluster).

Par ailleurs, l'architecture de bus IEEE 1394 limite à 63 le nombre de noeuds (c. -à-d. systèmes connectés) sur un bus donné. Il existe actuellement plusieurs solutions pour étendre les capacités d'un bus IEEE 1394 dans le cadre d'une infrastructure câblée. Une solution majeure, actuellement toujours en cours de discussion au sein du sous-groupe IEEE p1394. 1 (ci-après désigné par"p1394. 1" ou"IEEE p1394. 1"), permet déjà d'étendre le bus série haute performance (High Performance Serial Bus-IEEE 1394-1995) au delà du bus local, au moyen d'un dispositif particulier : le pont. Selon IEEE p1394. 1, cette solution consiste à créer un"pont" (bridge) câblé entre deux segments (grappes) différents à base de bus série. Le pont d'interconnexion tel que défini par le sous-groupe IEEE p1394. 1, sera dans la suite de la description désigné par"pont IEEE1394". Un tel pont sera décrit plus loin en liaison avec la FIG. 1.

Selon IEEE p1394. 1, deux types de systèmes ou noeuds sont définis par rapport au pont précité. D'une part, les systèmes qui sont adaptés au pont (en anglais bridge aware devices), et d'autre part, ceux qui ne sont pas adaptés à un tel pont (en anglais non bridge aware devices), appelés"legacy

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.

Selon IEEE p1394. 1, les systèmes legacy peuvent réussir à fonctionner dans un environnement de pont avec cependant certaines restrictions. En effet, selon p1394. 1, les systèmes legacy sont supposés n'être seulement que des demandeurs en lecture (write-only requesters). A ce titre, ils sont limités à la génération de transactions d'écriture à distance (remote write transactions). Ainsi, les transactions de lecture ou de verrouillage à distance (remote read and lock transactions) sont interdites et donc rejetées.

Cependant, les ponts n'offrent qu'une compatibilité limitée avec les transactions d'écriture à distance émises par des systèmes legacy. En effet,

lorsqu'un système legacy envoie une requête d'écriture à distance (remote write transaction request), le pont-plus exactement son port d'entrée (inbound porta/)-accepte la requête et renvoie au système legacy une réponse automatique (write transaction response), indiquant que la requête d'écriture s'est terminée de manière réussie, avant même que cette requête d'écriture ne soit parvenue à sa destination. Lorsque la requête d'écriture atteint finalement le noeud destinataire, celui-ci renvoie une réponse d'écriture (write transaction response) qui est filtrée au niveau du pont et non traitée.

La finalité de ce processus est d'éviter que la durée de temporisation de transaction (split transaction timeout) au noeud source (le système legacy) ne soit expirée avant que la réponse issue du noeud de destination ne soit reçue dans le noeud source. En d'autres termes, ce qui est visé, c'est la compatibilité avec une durée de temporisation apparemment courte au niveau du système legacy. En effet, les systèmes legacy ne sont pas conçus pour initier des transactions à distance. Lorsqu'un tel système envoie une requête de transaction d'écriture (write transaction request), il active une temporisation locale (split timeout) dont la durée est de 100 millisecondes (ms) au minimum, définissant ainsi l'intervalle de temps minimum à respecter avant d'élaborer une nouvelle requête. Cette temporisation est bien adaptée à une transaction locale. Pour une transaction à distance, le noeud source doit prendre en compte les retards introduits par le pont. C'est la raison pour laquelle le port d'entrée (inbound portal) du pont renvoie immédiatement au noeud local un message indiquant que l'écriture s'est bien déroulée (write response OKpacket).

Au contraire, les systèmes conçus pour être adaptés aux ponts IEEE1394 (bridge aware devices), définissent une temporisation à distance (remote timeout) qui prend en compte les retards introduits par les ponts. La temporisation à distance est au moins le double de la temporisation locale.

D'autre part, la temporisation à distance est dépendante du chemin suivi, et un message spécial de gestion du pont détermine la temporisation distante pour chaque noeud distant.

Le processus d'écriture à distance par un système legacy au travers d'un pont IEEE1394, tel que défini supra, présente un certain nombre d'inconvénients. Ainsi, lorsque des erreurs interviennent dans la communication entre le pont et le noeud distant (destinataire), ces erreurs ne pourront être détectées qu'au niveau application du noeud source ou bien du noeud de destination. D'autre part, le fait que le noeud local (émetteur) reçoive immédiatement et automatiquement une réponse (write transaction response) signifiant que la transaction de lecture s'est bien déroulée, permet au noeud local d'émettre de nouvelles transactions d'écriture, ce qui peut, dans le cas où le chemin entre le pont et le noeud se trouve dans une situation de congestion, provoquer une surcharge ou dépassement de capacité (butter overflow) dans le pont. Ce processus d'écriture à distance interdit donc la gestion d'erreurs (error management) et la gestion du débordement de tampon (buffer overflow management) dans le pont.

Le but de la présente invention est par conséquent de résoudre les inconvénients précités liés au processus, tel que défini présentement par IEEE p1394. 1, pour effectuer une transaction d'écriture à distance depuis un noeud local legacy vers un noeud distant, au travers d'un pont.

A cet effet la présente invention concerne, selon un premier aspect, un procédé de communication entre un système local connecté à un premier bus série, et un système distant connecté à un second bus série, au travers d'un pont interconnectant les deux bus, le système local pouvant ne pas être adapté pour échanger des informations au travers du pont. Le procédé comporte les étapes préalables de réception d'une requête d'écriture émise par le système local à destination du système distant et de détermination du type du système local émetteur de la requête d'écriture. Le procédé est remarquable en ce que, si le système local est déterminé comme n'étant pas adapté pour échanger des informations au travers du pont, il comporte les étapes suivantes : - mémorisation de la date de réception (Date-Réception) de la requête d'écriture dans le pont ; - détermination d'une première date future (DateMax) définie par rapport à ladite date de réception (Date-Réception), et correspondant à la date

la plus tardive à laquelle envoyer au système local une réponse d'écriture, de manière à satisfaire une condition de temporisation prédéterminée pour le système local ; - envoi d'une réponse d'écriture au système local, au plus tard lorsque la première date (DateMax) est passée.

De cette façon, en déterminant une limite temporelle future

(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.

Dans un mode préféré de réalisation de l'invention, le pont et les bus sont conformes au standard 1 EEE p1394. 1 ; et le système local, qui n'est pas adapté à l'échange d'informations au travers du pont, est de type"legacy" au sens du standard IEEE p1394. 1.

Le standard IEEE p1394. 1 est en effet particulièrement adapté pour la mise en oeuvre de l'invention.

Le pont d'interconnexion comprend un port d'entrée connecté au premier bus et un port de sortie connecté au second bus. Selon une implémentation préférée de l'invention, l'étape d'envoi d'une réponse d'écriture au système local comporte les étapes suivantes : - vérification que la première date (DateMax) est passée ou non ; - si c'est le cas, envoi d'une réponse d'écriture au système local ; - sinon, déterminer une seconde date future (DateMax2) comprise entre la date de réception (Date-Réception) de la requête d'écriture et la première date (Date~Max), la seconde date étant d'autant plus proche de la date de réception de la requête que le flux de données entre le port d'entrée et le port de sortie du pont est faible ; - envoi d'une réponse d'écriture au système local, au plus tard lorsque la seconde date (Date~Max2) est passée.

En recalculant la date future (Datemax2) la plus tardive à laquelle envoyer une réponse au système local, en fonction de l'intensité du trafic (flux de données) entre le port d'entrée et le port de sortie du pont, cela permet

"d'asservir"la rapidité d'envoi de la réponse au système local en fonction de ce trafic, tout en respectant la condition de temporisation codée pour le système local.

De manière pratique, la condition de temporisation prédéterminée pour le système local (legacy) est définie par une valeur de temporisation locale (DTV) prédéterminée pour ce système et déterminant l'intervalle de temps maximal entre la réception de la requête d'écriture par le port d'entrée et l'envoi par celui-ci d'une réponse d'écriture au système local.

Selon un mode de réalisation préféré de l'invention, la première date (Date~Max) déterminée par le port d'entrée du pont, est obtenue par l'équation suivante : Date-maux = Date-Réception + DTV où DTV représente la valeur prédéterminée de temporisation locale affectée au système local, et Date-Réception est la date de réception de la requête d'écriture dans le pont.

D'autre part, la seconde date (Date~Max2) est obtenue par l'équation suivante : Date~Max2 = Date-maux + (k-1). DTV
Où k est un nombre réel compris entre 0 et 1, dont la valeur est fonction de l'importance du flux de données entre le port d'entrée et le port de sortie du pont.

Selon un mode de réalisation préféré de l'invention, le flux de données entre le port d'entrée et le port de sortie du pont est mesuré par le calcul du taux de remplissage d'une file d'attente destinée à stocker temporairement les paquets de données destinés à être transférés du port d'entrée vers le port de sortie du pont.

Le choix de cette file d'attente, comme indicateur de l'intensité du trafic de paquets entre le port d'entrée et le port de sortie du pont, permet d'estimer ce trafic de manière fidèle par rapport à la réalité.

D'autre part, selon une caractéristique particulière de réalisation, le nombre k est choisi égal au taux de remplissage de cette file d'attente.

Selon une variante de réalisation, le nombre k est choisi égal à une valeur de seuil prédéterminée, lorsque celle-ci est atteinte par le taux de remplissage de la file d'attente.

Selon un autre mode de réalisation préféré de l'invention, on pourra prévoir de surveiller dans le pont, la réception d'une réponse d'écriture en provenance du système destinataire distant, et transmettre cette réponse d'écriture immédiatement au système local, avant même que la première date (DateMax) soit passée ou bien avant que la seconde date (Date~Max2), lorsqu'elle est déterminée, soit passée.

Ainsi, la réception d'une réponse d'écriture réelle en provenance du noeud destinataire, déclenche immédiatement la transmission de cette réponse au système local.

Corrélativement, selon un deuxième aspect, la présente invention concerne un dispositif de communication mis en oeuvre dans un pont, pour la communication entre un système local connecté à un premier bus série, et un système distant connecté à un second bus série, au travers du pont interconnectant les deux bus, le système local pouvant ne pas être adapté pour échanger des informations au travers du pont. Ce dispositif est remarquable en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé de communication tel que succinctement défini supra.

L'invention vise également un pont d'interconnexion comportant des moyens adaptés à la mise en oeuvre du procédé de communication selon l'invention.

La présente invention concerne encore un programme d'ordinateur apte à mettre en oeuvre le procédé de communication tel que brièvement défini plus haut, lorsque le programme est chargé et exécuté dans un système d'ordinateur incorporé au pont d'interconnexion.

L'invention vise aussi un support d'informations, tel que par exemple, une disquette ou un compact disque (CD) contenant un tel programme d'ordinateur.

Les avantages de ce dispositif, pont d'interconnexion, programme d'ordinateur, et de ce support d'informations, sont identiques à ceux du procédé de communication tels que succinctement exposés supra.

D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après.

Aux dessins annexés, donnés à titre d'exemples de réalisation non limitatifs : -la Figure 1 est un diagramme blocs représentant l'architecture d'un pont IEEE1394 permettant d'interconnecter deux sous-réseaux bâtis chacun autour d'un bus série IEEE1394 ; - la Figure 2 représente le format de l'identificateur d'un noeud sur un bus série IEEE1394 ; - la Figure 3 représente le format d'un paquet de données définissant une transaction asynchrone selon le standard IEEE 1394 ; - la Figure 4 illustre, selon le standard IEEE p1394. 1, le processus de traitement par un pont IEEE1394 d'une requête d'écriture distante émise par un système legacy ; - la Figure 5 est un organigramme représentant, en conformité avec l'invention, le processus de traitement d'un paquet asynchrone (tel que représenté à la FIG. 3) reçu dans un port d'entrée d'un pont IEEE1394 ; - la Figure 6 est un organigramme représentant le processus, selon l'invention, de détermination d'une date d'envoi par un port d'entrée d'un pont IEEE1394 d'une réponse d'écriture à un système legacy.

On va d'abord décrire, en référence à la Figure 1, l'architecture d'un pont IEEE1394 permettant d'interconnecter deux sous-réseaux bâtis chacun autour d'un bus série IEEE1394. L'ensemble : pont (1)-sous-réseaux (2,3), constitue un réseau désigné ici par réseau IEEE1394.

Comme représenté à la FIG. 1, un pont 1 d'interconnexion de bus série IEEE 1394, est utilisé pour interconnecter deux sous-réseaux 2 et 3 bâtis respectivement autour d'un bus série IEEE1394, 21, et d'un bus IEEE1394, 31.

Le sous-réseau 1 comporte un système tEEE1394,"noeud 1" (20), connecté au bus 21, alors que le sous-réseau 3 comporte un système tEEE1394,"noeud 2" (30), connecté au bus 31. Le pont 1 permet l'interconnexion entre les 2 bus 21 et 31.

Le pont 1 comporte deux ports (porta4 entrée/sortie (E/S) 11 et 12. Chacun des ports 11 et 12 comporte des fonctionnalités de réception, de transmission et de gestion des paquets de données. Ces fonctionnalités sont

réparties dans différentes couches fonctionnelles : couche physique (111, 121), couche de liaison (112, 122) et couche de transaction (113, 123). Ces couches peuvent être constituées d'éléments matériel (hardware) et/ou logiciel (software). Chacun des ports 11 et 12 comporte également une unité de contrôle de port (114,124) rassemblant une série de registres de contrôle et d'état pour le port considéré ainsi que pour les couches fonctionnelles précitées.

Le pont 1 comporte également une unité de commutation 13 (switching fabric) pouvant utiliser une technologie câblée (wired technology) telle que, par exemple, celle définie par le standard IEEE 1394b ; ou une technologie sans fil (wireless technology) telle que, par exemple, celle définie selon le standard connu sous"HiperLAN 2", ou celle définie par le standard IEEE 802. 11a.

L'unité de commutation 13 est associée à des files d'attente (queues) 131,132 de type FIFO (first-in-first-out) pour mettre en file d'attente des paquets de données de type asynchrones ou isochrones. L'unité de commutation permet ainsi aux deux ports E/S 11 et 12 de communiquer.

Le pont 1 comporte en outre une unité de cycle d'horloge (clock cycle) 115 qui permet de définir une méthode pour distribuer l'horloge aux 2 ports E/S 11 et 12. Le pont 1 comporte également une table de routage 116 et une mémoire de configuration 117 de type mémoire ROM (read only memory).

A chaque port 11,12 du pont 1, il est associé une adresse qui l'identifie de manière unique sur le bus (21,31) auquel il est connecté. Chacun des ports 11,12 est conçu pour répondre à différents types de requêtes émises par des systèmes IEEE1394 connectés au bus correspondant. Ces requêtes sont par exemple des requêtes de lecture, d'écriture, et de verrouillage (read, write, lock requests). A cet effet, chaque port (11,12) utilise des tables de routages mémorisées dans l'unité 116 pour déterminer les transactions qui doivent être transmises, au travers de l'unité de commutation 13, à l'autre port du pont. L'unité de commutation 13 est ainsi capable de transférer n'importe quelle transaction depuis un port vers l'autre port du pont.

Chaque noeud'1EEE1394", tel que le noeud 1 ou le noeud 2, est défini sur le bus (21, 31) auquel il est connecté, par un identificateur de noeud "node/D"qui inclut un identificateur de bus (10 bits de long),"bus ID", identifiant le bus sur lequel il est connecté, et un identificateur physique (6 bits de ong), "phy~ID", identifiant physiquement le noeud sur le bus. La Figure 2 représente le format d'un tel identificateur de noeud sur un bus IEEE1394.

Dans le cadre de la présente invention, on considère l'échange de paquets asynchrones au travers d'un pont IEEE1394. En effet, un noeud ou système IEEE1394 (21,31) peut échanger des paquets de données asynchrones, appelés transactions.

La Figure 3 représente le format d'un paquet de données définissant une transaction asynchrone selon le standard IEEE 1394. Comme on peut le voir sur cette figure, l'en-tête d'un paquet asynchrone inclus entre autres : - un champ"Source/D" (16 bits) contenant l'identificateur de noeud (node~ID) identifiant le noeud émetteur de la transaction ;

- 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.

Un pont IEEE1394 ignore toutes les transactions qui s'opèrent entre noeuds ayant une adresse locale sur un même bus, mais surveille et ne prend en compte que les transactions à distance entre deux noeuds ou systèmes dont les identificateurs de noeuds (node-ID) indiquent (champ bu(s/D) un bus d'appartenance différent.

Selon le standard IEEE p1394. 1, un pont IEEE1394 est capable de connaître l'état de chacun des noeuds connectés sur chacun des bus série locaux qu'il interconnecte. Dans ce but, un processus de découverte de systèmes legacy (legacy device discovery) est exécuté dans chaque port du pont considéré, après chaque procédure de réinitialisation (reset) de bus. Au

cours de ce processus, chaque port du pont récupère, de la part de chacun des noeuds connectés au bus local auquel il est connecté, un paquet de données d'identification du noeud (Self lD packet), permettant au port de connaître l'identificateur physique (phy ID) du noeud, ainsi que ses fonctionnalités. En particulier, le port considéré du pont lit et mémorise pour chaque noeud un bloc d'information de bus (BIB-bus information block) permettant d'en identifier le caractère"legacy'ou adapté (bridge aware) tel que défini plus haut. Le bloc d'information de bus (BIB) est lu dans une mémoire de configuration de type ROM présente dans chacun des noeuds connectés au bus local considéré. Le bloc BIB comporte notamment un bit"b"déterminant le caractère"/egacy"du noeud considéré, lorsque ce bit prend la valeur"0".

Après avoir identifié tous les systèmes de type legacy, le port (portal) considéré doit lire le contenu d'un registre présent dans chacun des systèmes legacy identifiés. Ce registre, désigné par"registre de temporisation locale" (STR-split timeout register) contient une valeur de temporisation par défaut (default timeout value-DTV), applicable à la détection d'erreurs de transactions locales (split transaction errors), c. -à-d. des transactions effectuées entre deux noeuds attachés au même bus. Lorsque chacun des ports d'E/S du pont d'interconnexion a recueilli et mémorisé localement (dans son unité de contrôle) la valeur de temporisation locale (split timeout value) pour chaque noeud sur le bus local correspondant, le transfert de données au travers du pont peut être initié et les ports peuvent alors filtrer les transactions ayant pour origine un système legacy.

Comme mentionné plus haut, la valeur de temporisation locale par défaut (default timeout value), mémorisée dans le registre STR de chaque système legacy, est à l'origine adaptée aux transactions locales (sur le même bus), et, de ce fait, elle est relativement faible (de l'ordre de 100 ms).

Cependant, selon le standard ! EEE p1394. 1 cette valeur de temporisation locale est également utilisée pour les transactions à distance au travers d'un pont. Plus précisément, pour un système legacy donné ayant envoyé une requête de transaction à distance, la valeur de temporisation locale par défaut (default timeout va/ue-DTV) définit la période de temps à l'intérieur de laquelle

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).

La présente invention concerne la communication à distance, au travers d'un pont IEEE1394, entre un premier système legacy connecté à un premier bus IEEE1394 et un second système connecté à un second bus IEEE1394. Ainsi dans la FIG. 1, on considère, dans la suite de la description, que le noeud 20 connecté au bus 21 est un système de type legacy, émettant des requêtes de transaction vers le noeud 30 connecté au bus 31, au travers du pont d'interconnexion 1. Avec le sens de la communication ainsi défini, c.-à-d. du noeud 2 vers le noeud 3, le port d'E/S 11 du pont 1 est appelé"port d'entrée" (inbound portal) et le port d'E/S 12 est appelé"port de sortie" (outbound portal).

Comme mentionné plus haut, chaque port du pont surveille les transactions qui sont émises sur le bus local auquel il est rattaché. Le port 11 par exemple, filtre les requêtes de transaction qui sont émises sur le bus local 21 en analysant les champs "Source~ID" et "Destination~ID" présents dans l'en-tête d'un paquet de données asynchrone (cf. FIG. 3) transitant sur le bus local 21. Une transaction est alors interprétée comme une transaction à distance (remote transaction) si le champ Destination-in ne correspond pas au port considéré.

La Figure 4 illustre, selon le standard IEEE p1394. 1, le processus de traitement par un pont IEEE1394 d'une requête d'écriture distante émise par un système legacy. Comme représenté à la FIG. 4, dès que le système legacy 420 (demandeur legacy) envoie une requête d'écriture distante 401 à destination d'un noeud distant 435, il déclenche le décompte de la temporisation (defaulttimeout value) définie dans son registre de temporisation locale (STR).

Lorsque la requête d'écriture 401 est reçue par le port d'entrée (inbound portal) 425, celui-ci envoie aussitôt au demandeur legacy un message 402 signifiant "acquittement en cours" (acknowledgment pending). Puis le port d'entrée 425 génère et envoie, avant l'expiration de la temporisation 409 (par ex. 100ms), au système legacy une réponse d'écriture 403 (write transaction response)

"artificielle"indiquant que la requête s'est terminée de manière réussie, alors qu'elle n'a pas encore été reçue par le noeud destinataire (435). Le système legacy recevant cette réponse d'écriture artificielle, avant l'expiration de la temporisation, réplique par un message 404 signifiant"acquittement complet" (Acknowledgment complete) terminant ainsi la transaction d'écriture.

La requête d'écriture 401, quant à elle, est traitée de la façon suivante par le pont. La requête est d'abord transmise au port de sortie (outbound portaf) 430, via l'unité de commutation (FIG. 1,13). Le port de sortie 430 transmet alors la requête 401, via le bus auquel il est connecté, au système destinataire 435. Ce dernier reçoit alors la requête 401 après un temps de retard dû à la transmission. Le standard IEEE p1394. 1 prévoit alors deux possibilités 410,411 pour la suite du traitement.

Selon une première possibilité (410), le noeud destinataire 435 réplique au port de sortie (430) par un message 405"acquittement complet" (Acknowledgment complete) signifiant que la requête de traitement a été bien reçue ; le port de sortie 435 génère alors une réponse de transaction d'écriture 407 qui est ensuite transmise au port d'entrée 425. Le système étant de type legacy, cette réponse d'écriture est finalement ignorée par le port d'entrée.

Selon une seconde possibilité 411, le noeud destinataire, après réception de la requête d'écriture, réplique par l'envoi d'un message 406 "acquittement en cours" (acknowlegment pending). Après avoir traité la requête d'écriture, le noeud destinataire génère une réponse d'écriture 407 qu'il transmet (via le bus) au port de sortie. Ce dernier reçoit la réponse et réplique par l'envoi d'un message"acquittement complet"408 au noeud destinataire.

Puis, le port de sortie 430 transfère la réponse d'écriture 407 au port d'entrée 425 du pont qui la reçoit. Comme selon la première possibilité, le port d'entrée 425 ignore la réponse d'écriture 407 qui lui a été transmise par le port de sortie.

En effet, dans les deux cas, le port d'entrée 425 avait déjà généré et envoyé au noeud demandeur 420, une réponse d'écriture"artificielle"403, avant que la temporisation, codée dans le registre de temporisation locale (STR) du système legacy 420, ne soit expirée.

Il est à noter que la distinction port d'entrée/port de sortie du pont n'est faite que relativement au sens de transmission de la requête de transaction d'écriture initiale.

Chaque système de type legacy ou non, connecté à un bus donné, comporte en outre un registre, dit"registre de temps de cycle" (cycle time register-CTR) contenant une valeur de temps permettant de définir une date commune à tous les noeuds présents sur le bus. Ce registre CTR est cadencé par une horloge matérielle à base de quartz présente dans le dispositif. Dans une implémentation préférée, cette horloge possède une fréquence de 24,576 MHz. Périodiquement la valeur de temps contenue dans chaque registre CTR est synchronisée par un système maître d'horloge (clock master) présent sur le bus. De cette façon, chaque système présent sur le bus possède la même référence de temps. De même, chacun des ports du pont possède un registre CTR mémorisant la valeur de temps courante.

En liaison avec la Figure 5, on va maintenant décrire le processus selon l'invention de traitement d'un paquet asynchrone (tel que représenté à la FIG. 3) reçu dans un port d'entrée d'un pont IEEE1394.

Le processus de traitement d'un paquet commence par la réception d'un paquet (étape E501) dans le port d'entrée du port, le paquet provenant du bus IEEE1394 attaché au port d'entrée du pont. Après réception du paquet, l'en-tête du paquet (cf. FIG. 3) est analysé de manière à déterminer la nature de la transaction objet du paquet. Ainsi la transaction est de type distante, si le champ Destination-in ne correspond pas au port d'entrée. Par ailleurs, la nature de la transaction (requête ou réponse) est déterminée par l'analyse du champ tcode de l'en-tête du paquet. Enfin par l'analyse du champ Source-in de l'en-tête du paquet, le type (legacy ou non) du noeud émetteur du paquet peut être déterminé. La réception des paquets dans le port d'entrée, de même que l'envoi de paquets, est assurée par des moyens de réception/émission incorporés dans la couche fonctionnelle de transaction 113 du port d'entrée.

De retour à la FIG. 5, à l'étape E503, après analyse de l'en-tête du paquet, si la transaction n'est pas une transaction distante, c. -à-d. s'adressant à

un noeud accessible via le second bus IEEE1394 attaché au port de sortie du pont, on détermine (E505) si la destination est le port d'entrée lui-même. Si c'est le cas, le paquet est transféré (E521) vers la couche de transaction (FIG.

1,113) du port d'entrée pour y être traité. Si ce n'est pas le cas, il peut s'agir alors d'une erreur d'acheminement du paquet, le paquet est alors supprimé (discarded) (E519).

A l'inverse, si la transaction objet du paquet est une transaction distante (E503, branche OUI), alors selon que la transaction est de type "requête"ou non (E507) un traitement différent est appliqué. Ainsi, si la transaction n'est pas une requête mais une réponse (E511, branche OUI), le paquet est transféré vers le port de sortie du pont pour être acheminé (E517) à sa destination. Si la transaction n'est ni une requête ni une réponse (E511, branche NON), il s'agit alors certainement d'un message erroné et le paquet est supprimé (E519).

Si au contraire la transaction est de type requête (E507, OUI), il est alors déterminé si le noeud émetteur du paquet est un système legacy ou non. Le port d'entrée du pont (unbound portal) dispose dans ce but d'une table localisée dans son unité de contrôle (114), dans laquelle sont mémorisés les identificateurs (node/D) de tous les noeuds de type legacy connectés au bus attaché au port d'entrée.

Si le noeud émetteur n'est pas un système de type legacy (E509, NON), la requête est alors transférée (E515) vers le port de sortie (outbound portal) du pont pour être acheminée à son destinataire.

Si le noeud émetteur est un système legacy (E509, OUI) alors on détermine (E513) si la requête est une requête d'écriture (write transaction request). Si ce n'est pas le cas, on supprime le paquet (E523) car seules les requêtes d'écriture des dispositifs legacy peuvent être traitées par le pont.

Si, au contraire, il s'agit d'une requête d'écriture (E513, OUI), alors on commence par transférer la requête vers le port de sortie (E525) pour que la requête soit acheminée à son destinataire. Puis, à l'étape E527, conformément à l'invention, il est procédé à la détermination et à la mémorisation de la date de réception de la requête d'écriture dans le port d'entrée du pont. Dans ce but, la

date courante notée"Date~Courante"est lue dans le registre CTR du port d'entrée, c.-à-d. le registre"de temps de cycle" (cycle time register) contenant la valeur de temps courante commune à tous les noeuds présents sur le bus. Le registre CTR est localisé dans l'unité de contrôle du port (114). La date courante"Date~Courante"lue qui correspond à la date de réception de la requête est ensuite mémorisée dans une variable notée"Date~Réception". La détermination et la mémorisation de la date de réception de la requête d'écriture sont réalisées par des moyens adaptés, en pratique des moyens logiciels (programmes) dont le code est stocké dans l'unité de contrôle (114) du port.

Toujours à l'étape E527, il est procédé à la lecture de la valeur de temporisation par défaut DTV (default timeout value), concernant le noeud legacy à l'origine de la requête d'écriture. Comme mentionné précédemment, cette valeur de temporisation DTV est lue à partir d'un emplacement mémoire situé dans l'unité de contrôle du port d'entrée. Cette valeur de temporisation est issue initialement du registre STR (split timeout register) contenu dans le système legacy émetteur.

A l'étape suivante (E529), conformément à l'invention, il est procédé à la détermination d'une date future notée"Date~Max"correspondant à la date la plus tardive à laquelle envoyer au système local (c. -à-d. le noeud legacy émetteur de la requête d'écriture) une réponse d'écriture, de manière à satisfaire la condition de temporisation prédéterminée pour le système local. La détermination de la date future est, en pratique, réalisée par des moyens logiciels (c. -à-d. programmes) dont le code est mémorisé dans l'unité de contrôle (114) du port.

En d'autres termes, conformément à l'invention, la réponse d'écriture est envoyée au système local, au plus tard lorsque la date "Date~Max"est passée. La condition de temporisation prédéterminée pour le système local émetteur est définie par la valeur prédéterminée de temporisation locale (DTV), stockée initialement dans le registre STR du système, déterminant l'intervalle de temps maximal entre la réception de la requête

d'écriture par le port d'entrée et l'envoi par ce dernier d'une réponse d'écriture au système local.

Conformément à l'invention, la date future"DateMax"est obtenue en ajoutant à la date de réception (Date-Réception) obtenue la valeur de temporisation DTV relative au système local. Ainsi, la date future

"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.

La file d'attente legacy est testée de manière périodique par l'unité de contrôle (114) du port d'entrée, par exemple tous les instants correspondant à 10% de la valeur de temporisation locale par défaut (DTR) d'un système legacy, de manière à déterminer pour chaque requête d'écriture identifiée dans la file d'attente, le moment (c.-à-d. la date) auquel envoyer une réponse d'écriture au noeud à l'origine de la requête d'écriture.

En référence à la Figure 6, on va maintenant décrire de façon détaillée, le processus selon l'invention de détermination d'une date d'envoi optimale, par le port d'entrée du pont, de la réponse d'écriture au système legacy.

Ce processus commence par une étape de test E601, dans laquelle il est déterminé si la file d'attente legacy est vide ou non. Si c'est le cas (OUI) on reste dans l'état de test de la file d'attente. Dans le cas contraire, si la file d'attente n'est pas vide, on sélectionne à l'étape suivante (E603) une requête d'écriture identifiée dans la file d'attente (par son en-tête).

Ensuite, à l'étape E605, on lit la date courante (Date-Courante) dans le registre CTR du port d'entrée, et on lit, dans la file d'attente, la date Date-maux associée à l'en-tête de la requête d'écriture identifiée.

A l'étape qui suit (E607), on vérifie que la date Date~Max déterminée pour la requête d'écriture identifiée est passée ou non. Dans ce but, on compare la date courante, lue à l'étape précédente, à la date Date~Max. Si la date Date-maux est passée, c. -à-d. si la date courante est supérieure ou égale à Datetvtax, alors on envoie (E609) une réponse d'écriture au système local émetteur de la requête d'écriture. En réalité, deux cas peuvent se produire : soit une réponse d'écriture est déjà arrivée en provenance du noeud destinataire, auquel cas on envoie cette réponse au système local ; soit aucune réponse n'a été reçue de la part du noeud destinataire, et dans ce cas le port d'entrée génère lui-même une réponse d'écriture comme si cette réponse provenait du noeud destinataire.

Ensuite, on détermine, à l'étape E617, si la requête d'écriture en cours de traitement (requête d'écriture courante) est la dernière de la file d'attente. Si c'est le cas, on retourne à l'étape E601 pour tester l'état de la file d'attente. Dans la négative, on retourne à l'étape E603 pour sélectionner une autre requête d'écriture identifiée dans la file d'attente legacy.

De retour à l'étape E607, si la date Date-maux correspondant à la requête d'écriture courante n'est pas encore passée (date courante inférieure à Date~Max), alors au cours des étapes qui suivent, E611 et E613, on détermine une seconde date future, notée"Date~Max2", comprise entre la date de réception (Date-Réception) de la requête d'écriture en cours et la date Data~Max. Comme cela va être détaillé ci-après, cette seconde date, Date~Max2, est d'autant plus proche de la date de réception de la requête d'écriture, que le flux de données entre le port d'entrée et le port de sortie du pont est faible.

Dans ce but, à l'étape E611, on calcule d'abord un coefficient k (k nombre réel compris entre 0 et 1) dont la valeur est fonction de l'importance du flux de données circulant entre le port d'entrée et le port de sortie du pont. A

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.

Selon un mode de réalisation préféré de l'invention, le flux de données entre le port d'entrée et le port de sortie du pont est mesuré par le calcul du taux de remplissage d'une file d'attente (distincte de la file d'attente legacy) dont la fonction est de stocker temporairement les paquets de données destinés à être transférés du port d'entrée vers le port de sortie du pont.

Dans ce mode de réalisation, selon une première variante de réalisation, la valeur du coefficient k est déterminée comme étant égale au taux de remplissage de la file d'attente précitée, implémentée entre le port d'entrée et le port de sortie du pont.

Selon une seconde variante de réalisation la valeur du coefficient k est déterminée comme étant égale à une valeur de seuil prédéterminée, lorsque cette dernière est atteinte par le taux de remplissage de la file d'attente. Par exemple, si le taux de remplissage de la file d'attente est mesuré comme étant supérieur à 0, 5 (valeur de seuil choisie) alors la valeur du coefficient k est égale à cette valeur de seuil : 0, 5. Dans le cas contraire, c.-à-d. si le taux de remplissage est inférieur à 0, 5, alors la valeur de k est fixée à zéro.

De retour à la FIG. 6, une fois que la seconde date, DateMax2 a été calculée (étape E613), à l'étape suivante, E615, on détermine si la date Date~Max2 est passée ou non. Pour cela, on compare Date~Max2 avec la date courante (issue du registre CTR). Si la date courante (Date-Courante) est supérieure ou égale à la date Date~Max2, alors cela signifie que celle-ci vient de passer, dans ce cas on passe à nouveau à l'étape E609 pour envoyer une réponse d'écriture au système local. Comme précédemment, deux cas peuvent se produire : soit une réponse d'écriture est déjà arrivée en provenance du noeud destinataire, auquel cas on envoie cette réponse au système local ; soit aucune réponse n'a été reçue de la part du noeud destinataire, et dans ce cas le port d'entrée génère lui-même une réponse d'écriture comme si cette

réponse provenait du noeud destinataire. De cette façon, on envoie une réponse d'écriture au système local, au plus tard lorsque la seconde date DateMax2 est passée.

Si au contraire, la date Date~Max2 n'est pas encore passée (Date-Courante inférieure à DateMax2), alors on n'envoie pas encore de réponse d'écriture, et on passe à l'étape E617 pour déterminer si la requête d'écriture en cours de traitement (requête d'écriture courante) est la dernière de la file d'attente, comme expliqué plus haut.

Selon un autre mode de réalisation préféré, on surveille dans le pont l'arrivée dans le port de sortie d'une réponse d'écriture en provenance du noeud destinataire. Dès que l'arrivée de cette réponse est détectée, avant même que la première date (Date~Max) soit passée ou bien avant que la seconde date (Date~Max2), lorsqu'elle est déterminée, soit passée, la réponse d'écriture est immédiatement transmise au système local émetteur de la requête d'écriture initiale.

Bien entendu, de nombreuses modifications peuvent être apportées aux modes de réalisation de l'invention décrits ci-dessus sans sortir du cadre de l'invention. En particulier, bien que les modes de réalisation décrits ici s'appliquent au standard IEEE 1394, l'invention s'applique généralement à tout autre standard de bus série et de pont d'interconnexion de bus, dont le mode de communication d'informations est similaire à celui décrit dans le cadre du standard IEEE 1394.

Claims

de la requête d'écriture dans le pont ; - détermination (E529) d'une première date future (DateMax) définie par rapport à ladite date de réception (Date-Réception), et correspondant à la date la plus tardive à laquelle envoyer audit système local une réponse d'écriture, de manière à satisfaire une condition de temporisation prédéterminée pour ledit système local ; - envoi d'une réponse d'écriture audit système local, au plus tard lorsque ladite première date (Date~Max) est passée.

REVENDICATIONS 1. Procédé de communication entre un système local (20) connecté à un premier bus série (21), et un système distant (30) connecté à un second bus série (31), au travers d'un pont (1) interconnectant lesdits bus, ledit système local (20) pouvant ne pas être adapté pour échanger des informations au travers dudit pont, le procédé comportant les étapes préalables de réception (E501, E503, E507, E513) d'une requête d'écriture émise par ledit système local à destination dudit système distant et de détermination (E509) du type dudit système local émetteur de la requête d'écriture, le procédé étant caractérisé en ce que, si le système local est déterminé comme n'étant pas adapté à l'échange d'informations au travers dudit pont, il comporte les étapes suivantes : - mémorisation (E527) de la date de réception (Date~Réception)
2. Procédé selon la revendication 1, caractérisé en ce que ledit pont et lesdits bus sont conformes au standard IEEE p1394. 1 et ledit système local, qui est non adapté à l'échange d'informations au travers dudit pont, est de type"legacy"au sens du standard IEEE p1394. 1.
3. Procédé selon la revendication 1 ou 2, dans lequel ledit pont comprend un port d'entrée connecté audit premier bus et un port de sortie

<Desc/Clms Page number 22>

connecté audit second bus, caractérisé en ce que l'étape d'envoi d'une réponse d'écriture audit système local comporte les étapes suivantes : - vérification (E607) que ladite première date (Datetvtax) est passée ou non ; - si c'est le cas, envoi (E609) d'une réponse d'écriture au système local ; - sinon, déterminer (E611, E613) une seconde date future (Date~Max2) comprise entre ladite date de réception (Date-Réception) de la requête d'écriture et ladite première date (Date~Max), ladite seconde date étant d'autant plus proche de ladite date de réception de la requête que le flux de données entre le port d'entrée et le port de sortie du pont est faible ; - envoi (E617, E609) d'une réponse d'écriture audit système local, au plus tard lorsque ladite seconde date (Date~Max2) est passée.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisée en ce que si une réponse d'écriture est reçue dans le pont en provenance dudit système distant, avant que ladite première date (DateMax) soit passée ou bien avant que ladite seconde date (Date~Max2), lorsqu'elle est déterminée, soit passée, la réponse d'écriture est immédiatement transmise au système local.
5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite condition de temporisation prédéterminée pour ledit système local est définie par une valeur prédéterminée de temporisation locale (DTV) déterminant l'intervalle de temps maximal entre la réception de la requête d'écriture par le port d'entrée et l'envoi par ce dernier d'une réponse d'écriture au système local.
6. Procédé selon la revendication 5, caractérisé en ce que ladite première date (DateMax) est obtenue par l'équation suivante : Date~Max = Date-Réception + DTV où :

<Desc/Clms Page number 23>

DTV représente la valeur prédéterminée de temporisation locale affectée au système local, et Date-Réception est la date de réception de la requête d'écriture dans le pont.
7. Procédé selon la revendication 6, caractérisé en ce que ladite seconde date (DateMax2) est obtenue par l'équation suivante : Date~Max2 = Date-maux + (k-1). DTV où :

DTV représente la valeur prédéterminée de temporisation locale affectée au système local, et k est un nombre réel compris entre 0 et 1, dont la valeur est fonction de l'importance du flux de données entre le port d'entrée et le port de sortie du pont.
8. Procédé selon l'une quelconque des revendications 3 à 7, caractérisé en ce que le flux de données entre le port d'entrée et le port de sortie du pont est mesuré par le calcul du taux de remplissage d'une file d'attente destinée à stocker temporairement les paquets de données destinés à être transférés du port d'entrée vers le port de sortie du pont.
9. Procédé selon la revendication 8, caractérisé en ce que le nombre k est égal au taux de remplissage de ladite file d'attente.
10. Procédé selon la revendication 8, caractérisé en ce que le nombre k est égal à une valeur de seuil prédéterminée, lorsque celle-ci est atteinte par le taux de remplissage de ladite file d'attente.
11. Dispositif de communication mis en oeuvre dans un pont, pour la communication entre un système local (20) connecté à un premier bus série (21), et un système distant (30) connecté à un second bus série (31), au travers dudit pont (1) interconnectant lesdits bus, ledit système local (20) pouvant ne

<Desc/Clms Page number 24>

(Date~Réception) de la requête d'écriture dans le pont ; - des moyens de détermination (113) d'une première date future (DateMax), définie comme étant la date la plus tardive à laquelle envoyer audit système local une réponse d'écriture, de manière à satisfaire une condition de temporisation prédéterminée pour ledit système local ; - des moyens d'envoi (113) d'une réponse d'écriture audit système local, au plus tard lorsque ladite première date (Datetvtax) est passée.

pas être adapté pour échanger des informations au travers du pont, ledit dispositif étant caractérisé en ce qu'il comporte : - des moyens de réception (113) d'une requête d'écriture émise par ledit système local à destination dudit système distant et de détermination (113) du type dudit système local émetteur de la requête d'écriture ; - des moyens de mémorisation (114) de la date de réception
12. Dispositif selon la revendication 11, caractérisé en ce que ledit pont et lesdits bus sont conformes au standard IEEE p1394. 1 et ledit système local, qui est non adapté à l'échange d'informations au travers dudit pont, est de type"legacy"au sens du standard IEEE p1394. 1.
13. Dispositif selon la revendication 11 ou 12, caractérisé en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé tel que revendiqué dans les revendications 3 à 10.
14. Pont d'interconnexion de bus série IEEE 1394, caractérisé en ce qu'il comporte un dispositif en conformité avec l'une quelconque des revendications 11 à 13.
15. Pont d'interconnexion de bus série IEEE 1394, caractérisé en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé de communication conforme à l'une quelconque des revendications 1 à 10.