FR2865089A1 - Procede pour communiquer des donnees a l'aide de tampons de donnees de relance - Google Patents
Procede pour communiquer des donnees a l'aide de tampons de donnees de relance Download PDFInfo
- Publication number
- FR2865089A1 FR2865089A1 FR0500209A FR0500209A FR2865089A1 FR 2865089 A1 FR2865089 A1 FR 2865089A1 FR 0500209 A FR0500209 A FR 0500209A FR 0500209 A FR0500209 A FR 0500209A FR 2865089 A1 FR2865089 A1 FR 2865089A1
- Authority
- FR
- France
- Prior art keywords
- data
- link
- serial
- communications
- small
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims description 53
- 239000000872 buffer Substances 0.000 title claims description 33
- 238000011084 recovery Methods 0.000 title claims description 4
- 238000004891 communication Methods 0.000 claims abstract description 270
- 238000012545 processing Methods 0.000 claims abstract description 87
- 230000005540 biological transmission Effects 0.000 claims description 54
- 238000012546 transfer Methods 0.000 claims description 27
- 238000012549 training Methods 0.000 claims description 18
- 230000015572 biosynthetic process Effects 0.000 abstract description 24
- 230000007246 mechanism Effects 0.000 abstract description 11
- 230000006870 function Effects 0.000 abstract description 9
- 239000000306 component Substances 0.000 description 49
- 230000008569 process Effects 0.000 description 18
- 238000007726 management method Methods 0.000 description 17
- 238000001514 detection method Methods 0.000 description 12
- 230000015654 memory Effects 0.000 description 10
- 238000010586 diagram Methods 0.000 description 8
- 238000012360 testing method Methods 0.000 description 7
- 230000002093 peripheral effect Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000007935 neutral effect Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 238000011282 treatment Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 238000013499 data model Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 239000008358 core component Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000004886 process control Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 238000013102 re-test Methods 0.000 description 1
- 238000002407 reforming Methods 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 208000024891 symptom Diseases 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0056—Systems characterized by the type of code used
- H04L1/0061—Error detection codes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Information Transfer Systems (AREA)
Abstract
Architecture de communications de données (200) utilisant des convertisseurs parallèle-série (300-1) et des convertisseurs série-parallèle (400-1) qui réduit la latence des communications de données. Dans une implémentation illustrative, l'architecture de communications de données (200) communique les données (230) à travers des liaisons de communications. L'architecture gère divers mécanismes pour favoriser la vitesse de communication de données et pour éviter les temps d'arrêt de la liaison de communication (215). Ces mécanismes réalisent les fonctions comprenant, sans s'y limiter, la gestion de temps d'arrivée de données incertains, la détection d'erreurs de bit-unique et de bits multiples, la gestion d'échecs de liaison de communications, l'adressage de formation de liaison échouée, l'identification et le marquage de données comme corrompues et l'identification et le traitement de transactions de données réussies à travers la liaison de communications.
Description
Domaine de l'invention
La présente invention concerne les architectures de communications de données pour les processeurs d' ordinateur architectures d' ordinateur série et des Contexte Les architectures informatiques qui fonctionnent efficacement et qui peuvent traiter des données rapidement sont généralement préférées a leurs homologues. La vitesse à laquelle ces architectures informatiques traitent les données peut être limitée par un certain nombre de facteurs qui comprennent la conception de l'architecture, les conditions de fonctionnement, la qualité des composants utilisés, ainsi que les protocoles, la logique et les méthodologies utilisés par l'architecture de l'ordinateur lors du traitement des données. Les latences dans la communication de données à travers les composants découlant des architectures de communications de données et des protocoles d'une architecture informatique peuvent également influencer la vitesse à laquelle les données peuvent être traitées.
Un certain nombre d'architectures de communication de données sont actuellement utilisées pour communiquer les données entre les composants coopérant d'une architecture d'ordinateur (par exemple, les processeurs d'ordinateur dans une unité centrale d'environnement informatique ou entre un processeur d'ordinateur et un composant périphérique tel qu'un disque de stockage de données). Par exemple, les interfaces IDE/ATA (Integrated Drive Electronics/Advanced Technology Attachment) et SCSI (système d'interface pour micro- ordinateur) sont toutes des interfaces communes pour et, plus particulièrement, les de communications pour les processeurs utilisant des convertisseurs parallèle-convertisseurs série-parallèle.
disques durs (ainsi que certains autres dispositifs, tels que les lecteurs de CD-ROM et de DVD), et il existe plusieurs types de chaque. D'autres architectures de communications de données comprennent l'architecture PCI (interconnexion des composants périphériques), le bus AGP (bus graphique AGP), le bus USB (bus série universel), les ports de communications de données et les ports de communications de données parallèles.
Bien que chacune des architectures de communications de données ci-dessus soient efficaces dans la transmission de données entre des composants coopérant, chacune de ces architectures présente des inconvénients et des limites de performance. En particulier, ces architectures de communication de données ne sont pas conçues pour gérer des quantités volumineuses de communicaticns de données qui sont communiquées à des fréquences d'horloge élevées (par exemple plusieurs gigahertz). En outre, les architectures de communication de données PCI, IDE et SCSI nécessitent généralement des calculs de traitement de temps système lors de la communication des données, ce qui influence la vitesse globale des communications de données. Exprimé différemment, outre les données souhaitées en cours de communication, des données de traitement de temps système supplémentaires doivent être communiquées. Ainsi, moins de données globales sont traitées pendant chaque cycle d'horloge.
Répondant au besoin en architectures de communications de données à bande passante supérieure, l'architecture de communications de données par SERDES (convertisseur parallèle-série/convertisseur série-parallèle) a été développée. Le SERDES fonctionne pour encoder et décoder les données selon un plan prédéfini (par exemple, un encodage 8 bits/10 bits - 8bl0b). Les données encodées sont communiquées par un ou plusieurs canaux de communication depuis le convertisseur parallèle-série vers un convertisseur série-parallèle correspondant pour le décodage. L'architecture de communication de données par SERDES a été démontrée comme augmentant la bande passante de communications de données entre les composants coopérant. Dans ce contexte, les architectures de communication de données sont déployées comme des bus de données fonctionnant pour transporter les données entre les composants coopérant.
Résumé L'invention concerne un système informatique comprenant une architecture de communications de données, procédé pour communiquer des données à l'aide de tampons de données de relance comprenant: l'établissement d'un canal de communications entre un convertisseur parallèle-série et un convertisseur série-parallèle pour la communication de petits paquets de données; le stockage des petits paquets de données dans un tampon de relance de niveau liaison pour la communication à travers les canaux de communication; la génération d'une adresse pour chacun des petits paquets de données, dans laquelle les adresses agissent comme des pointeurs vers les emplacements des petits paquets de données dans le tampon de relance de niveau liaison; la communication de l'adresse du petit paquet de données reçu depuis une extrémité de réception d'un canal de communication comme accusé réception d'un transfert réussi des données; et la libération de l'entrée de tampon de relance de niveau liaison depuis le tampon de relance de niveau liaison pour utilisation par un petit paquet de données suivant.
L'invention concerne un procédé comprenant en outre la génération d'une balise de relance devant être comprise dans un sous-paquet d'en-tête de données, dans lequel la balise de relance contient des informations accusant réception du transfert de données réussi.
L'invention concerne un procédé comprenant en outre la communication de l'adresse du petit paquet de données à travers le canal de communication comme partie du sous-paquet d'en-tête de données entre le convertisseur parallèle-série et le convertisseur série-parallèle.
L'invention concerne un procédé comprenant en outre l'alimentation de l'adresse du petit paquet de données par un composant sur l'extrémité de réception du canal de communication avec des informations indicatrices du petit paquet le plus récent reçu avec succès par l'extrémité de réception du canal de communications.
L'invention concerne un procédé comprenant en outre l'accusé réception d'un transfert réussi en transmettant l'adresse du petit paquet entre le convertisseur parallèle-série et le convertisseur série-parallèle.
L'invention concerne un procédé comprenant en outre le renvoi d'une adresse de dernier petit paquet de données qui a fait l'objet d'un accusé réception correct à la fin d'une séquence de reformation, dans lequel l'adresse du petit paquet de données est compris dans un sous-paquet de formation.
L'invention concerne un procédé comprenant en outre la création d'un entête inactif dans le cas où il n'existe aucune adresse de petit paquet de données valide à envoyer depuis le convertisseur parallèle-série vers le convertisseur série-parallèle.
L'invention concerne un procédé dans lequel l'en-tête inactif communique un accusé réception de 5 transmission de données.
L'invention concerne un procédé comprenant en outre la communication de l'adresse du petit paquet de données le plus récent transmis avec succès comme partie d'une séquence de redémarrage de liaison sélectionnée.
L'invention concerne un procédé pour accuser réception de la transmission réussie de données ayant, associées à celles-ci, une adresse de petit paquet à travers une architecture de communications de données par SERDES comprenant: la gestion d'une copie des données dans un tampon de relance jusqu'à ce qu'un accusé réception soit reçu indiquant un transfert réussi des données; le traitement de l'adresse de petit paquet pour déterminer si un transfert réussi de données s'est produit à travers un canal de communications; et la libération de la copie des données dans le tampon de relance.
Une architecture de communications de données utilisant des convertisseurs parallèle-série et des convertisseurs série-parallèle destinée à être utilisée dans la communication de données entre des composants de traitement d'ordinateur d'un environnement informatique pour réduire la latence est proposée. Dans une mise en ouvre illustrative, une architecture de communications de données comprend une interface de données, un convertisseur parallèle-série et un convertisseur sérieparallèle. En fonctionnement, les données provenant des composants de traitement d'ordinateur sont reçues par le convertisseur parallèle-série. Le convertisseur parallèle-série coopérant avec l'interface de données encode les données pour la communication vers le convertisseur sérieparallèle selon un protocole d'encodage sélectionné. En fonctionnement, le convertisseur parallèle-série et le convertisseur série-parallèle (SERDES) coopèrent pour former une liaison de communications ou un canal de communications.
L'interface de données, entre autres choses, permet la collecte de données à transférer à travers la liaison depuis chaque extrémité de la liaison, fournit les informations de gestion et de commande de liaison, encode la protection contre les erreurs et fournit la logique pour traiter les données à travers le canal de communications.
Outre l'exemple de mise en uvre, l'architecture de communications de données illustrative comprend en outre un contrôleur de statut de formation de liaison, un module de formation de liaison, un module de contrôle, un tampon de données, un module de formation de données, un module de bit de parité, un module de reconnaissance de transmission de données et un tampon de données. Ces modules comprennent une partie du convertisseur parallèle-série et du convertisseur série-parallèle. En fonctionnement, ces modules coopèrent avec l'interface de données et des ensembles d'instructions contenus dans le convertisseur parallèle- série et le convertisseur série-parallèle pour réaliser des fonctions comprenant, sans s'y limiter, la gestion de temps d'arrivée de données incertains, la détection d'erreurs de bit unique et de bit multiple, la gestion des échecs de liaison de communications, l'adressage de formation de liaison échouée, l'identification et le marquage de données comme étant corrompues, et: l'identification et le traitement de transactions de données réussies à travers la liaison de communications.
D'autres caractéristiques de la présente invention sont décrites cidessous.
Brève description des dessins
L'architecture de communications de données et des procédés d'utilisation est en outre décrite en référence aux dessins en annexe sur lesquels: la figure 1 est un schéma de principe d'un exemple 10 d'environnement informatique selon une implémentation des systèmes et procédés décrits ici; la figure 2 est un schéma de principe représentant la coopération d'exemples de composants d'un exemple d'architecture de communications de données; la figure 3 est un schéma de principe d'un coeur de transmission selon un exemple d'implémentation d'une architecture de communications de données; la figure 4 est un schéma de principe d'un c ur de réception selon un exemple d'implémentation d'une 20 architecture de communications de données; la figure 5 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de la communication de données; la figure 6 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de la gestion de l'arrivée de données incertaine; la figure 7 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de la détection d'erreurs de bit dans les communications de données; la figure 8 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de l'adressage d'un échec de liaison; la figure 9 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de l'adressage d'une formation d'échec de liaison; la figure 10 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de l'adressage de données corrompues; la figure 11 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données lors de la gestion de détection d'erreur; et la figure 12 est un organigramme représentant le traitement réalisé par un exemple d'architecture de communications de données pour accuser réception de communications de données réussies.
Description détaillée des implémentations illustratives 20 Généralités Pour fournir les environnements informatiques à bande passante d'infrastructure requise, les mises en oeuvre sont venues à utiliser des architectures de communications de données point à point par convertisseurs parallèle-série/convertisseurs série-parallèle (SERDES) fonctionnant à des fréquences élevées. Dans l'application de l'architecture de communications de données SERDES à une infrastructure de communications de données internes d'un environnement informatique, un certain nombre de limites apparaissent. En termes généraux, la latence des communications de données découle d'une gestion d'architecture de communications de données inefficace. La gestion de l'architecture de communications de données SERDES peut être réalisée par une interface de données qui, entre autres choses, collecte les données pour la communication le long des liaisons de communication SERDES et fournit des instructions de détection et de gestion d'erreur pour les données erratiques.
La présente invention propose une interface de données destinée à être utilisée par des canaux de liaison par SERDES qui supportent des opérations se produisant de manière bidirectionnelle entre des composants d'architecture de communications de données. Dans une implémentation illustrative, un mécanisme est fourni pour collecter les données pour un transfert à travers une liaison par SERDES depuis chaque extrémité de la liaison. En outre, le mécanisme peut fonctionner pour fournir des informations de gestion de liaison de recouvrement, pour encoder une protection contre les erreurs, et pour encoder les données dans le format approprié. L'interface de données de l'implémentation illustrative décrite ici gère également la logique qui accepte de diriger les composants SERDES pour collecter et communiquer les données entre des composants de liaison SERDES et pour vérifier que ces données sont correctement collectées et communiquées.
L'architecture de communications de données par SERDES illustrative peut également utiliser un tampon de données pour stocker les données. En fonctionnement, le tampon de données peut être utilisé pour stocker les données jusqu'à ce qu'une réception correcte soit confirmée par une réponse provenant de l'extrémité de réception d'une liaison de communications par SERDES. Dans un tel cas, un accusé réception peut être intégré comme partie des données communiquées entre des composants coopérants de l'architecture de communications de données par SERDES. Lorsqu'une erreur est détectée par les composants SERDES, le tampon de données peut être utilisé pour renvoyer les données pour corriger l'erreur.
En outre, l'implémentation illustrative peut orchestrer l'utilisation de canaux de communications par SERDES parallèles multiples. Un canal de communications par SERDES peut comprendre une liaison de communications logique fonctionnant sur une liaison physique (par exemple des câbles) entre des composants SERDES (par exemple des convertisseurs parallèlesérie et des convertisseurs série-parallèle). Lors de la réalisation de la détection d'erreurs, la formation et d'autres opérations, l'architecture de communications de données par SERDES illustrative peut utiliser un canal de rechange. En outre, un tel canal de rechange peut être utilisé pour gérer la disponibilité de communications même dans le cas d'un échec dur de l'un des canaux.
La mise en oeuvre illustrative fournit la flexibilité pour commander divers supports - câble, trace PC ou même une fibre de tampon appropriée et supporte une variété de fréquences de liaison pour fonctionner mieux avec le support choisi.
Environnement informatique illustratif La figure 1 décrit un exemple de système de calcul 100 selon le système et les procédés décrits ici. Le système informatique 100 est capable d'exécuter une variété d'applications informatiques 180. L'exemple de système informatique 100 est commandé principalement par des instructions lisibles par ordinateur, qui peuvent être sous la forme de logiciel, où et comment ce logiciel est stocké ou accédé. Un tel logiciel peut être exécuté dans l'unité de traitement central (UC) 110 pour amener le système de traitement de données 100 à réaliser la tâche. Dans de nombreux serveurs informatiques connus, stations de travail et ordinateurs personnels, l'unité de traitement central 110 est implémentée par des UC à puces microélectroniques appelées microprocesseurs. Le coprocesseur 115 est un processeur optionnel, distinct de l'UC principale 110, qui réalise des fonctions supplémentaires ou aide l'UC 110. Un type commun de coprocesseur est le coprocesseur à point flottant, également appelé coprocesseur numérique ou mathématique, qui est conçu pour réaliser des calculs numériques plus rapidement et mieux que l'UC à objet général 110.
Il est apprécié que, bien que l'environnement informatique illustratif soit représenté pour comprendre une UC unique 110 une telle description est purement illustrative puisqu'un environnement informatique 100 peut comprendre un nombre d'UC 110. En outre, un environnement informatique 100 peut exploiter les ressources d'UC distantes (non représentées) à travers un réseau de communications 160 ou certains autres moyens de communications de données (non représentés).
En fonctionnement, l'UC 110 extrait, décode et exécute les instructions et transfère les informations vers et depuis d'autres ressources par l'intermédiaire du chemin de transfert de données principal de l'ordinateur, le bus système 105. Un tel bus système raccorde les composants dans le système informatique et définit le support pour l'échange de données. Le bus système 105 comprend généralement des lignes de données pour envoyer des données, des lignes d'adresse pour envoyer des adresses et des lignes de commande pour envoyer des interruptions et pour actionner le bus système. Un exemple d'un tel bus système est le bus PCI (Interconnexion des composants périphériques). Certains des bus avancés d'aujourd'hui fournissent une fonction appelée arbitrage de bus qui régule l'accès au bus par des cartes d'extension, des contrôleurs et une UC 110. Des dispositifs qui se fixent à ces bus et arbitrent pour prendre le bus sont appelés des maîtres bus. Un support de maître bus permet également des configurations de multiprocesseur des bus à créer par l'ajout d'adaptateurs de maître de bus contenant un processeur et ses puces de support.
Des dispositifs de mémoire couplés au bus système 105 comprennent une mémoire vive (RAM) 110 et une mémoire morte (ROM)130. Ces mémoires comprennent des circuits électriques qui permettent aux informations d'être stockées et extraites. Les mémoires ROM 130 contiennent généralement des données stockées qui ne peuvent pas être modifiées. Les données stockées dans la mémoire RAM 125 peuvent être lues ou modifiées par l'UC 110 ou d'autres dispositifs matériels. L'accès à la mémoire RAM 125 et/ou à la mémoire ROM 130 peut être contrôlé par un contrôleur mémoire 120. Le contrôleur mémoire 105 peut fournir une fonction de conversion d'adresse qui convertit des adresses virtuelles en adresses physiques lorsque les instructions sont exécutées. Le contrôleur mémoire 120 peut également fournir une fonction de protection de mémoire qui isole les traitements dans le système et isole les traitements du système des traitements de l'utilisateur. Ainsi, un programme fonctionnant en mode utilisateur peut normalement accéder uniquement à la mémoire mappée par son propre espace d'adresse virtuelle de traitement; il ne peut pas accéder à une mémoire dans l'espace d'adresse virtuelle d'un autre traitement à moins que le partage de mémoire entre les traitements ait été paramétré.
En outre, le système informatique 100 peut contenir un contrôleur de périphériques 135 chargé de communiquer les instructions provenant de l'UC 110 vers les périphériques tels qu'une imprimante 140, un clavier 145, une souris 150 et. un disque de stockage de données 155.
Un affichage 165, qui est contrôlé par un contrôleur d'affichage 163, est utilisé pour afficher la sortie visuelle générée par le système informatique 100. Une telle sortie visuelle peut comprendre du texte, des graphiques, des graphiques animés et de la vidéo. L'affichage 165 peut être implémenté avec un affichage vidéo CRT, un affichage à écran plat LCD, un affichage à écran plat au plasma à gaz ou un écran tactile ou d'autres formes d'affichage. Le contrôleur d'affichage 163 comprend des composants électroniques nécessaires pour générer un signal vidéo qui est envoyé vers l'affichage 165.
En outre, le système informatique 100 peut contenir un adaptateur réseau 170 qui peut être utilisé pour connecter le système informatique 100 à un réseau de communication externe 160. Le réseau de communications 160 peut fournir aux utilisateurs d'ordinateur des moyens de communication et de transfert de logiciel et d'informations par voie électronique. En outre, le réseau de communication 185 peut fournir un traitement distribué, qui implique plusieurs ordinateurs et le partage de charges de travail ou des efforts coopératifs dans la réalisation d'une tâche. Il sera apprécié que les connexions de réseau représentées sont des exemples et d'autres moyens d'établir d'une liaison de communications entre les ordinateurs peuvent être utilisés.
Il est apprécié que l'exemple de système informatique 100 est purement illustratif d'un environnement informatique dans lequel les systèmes et procédés décrits ici peuvent fonctionner et ne limitent pas l'implémentation des systèmes et procédés décrits ici dans des environnements informations comprenant des composants et des configurations différentes puisque les concepts de la présente invention décrits ici peuvent être implémentés dans divers environnements informatiques comprenant divers composants et configurations.
Architecture de communications de données Les figures 2 à 4 représentent des schémas de principe d'une architecture de communications de données illustrative destinée à être utilisée dans un exemple d'environnement informatique. L'architecture de communications de données illustrative peut être implémentée comme des composants de l'environnement informatique et peut utiliser des composants SERDES. En particulier, la figure 2 représente un schéma de principe d'une architecture de communications de données illustrative 200. Comme cela est représenté sur la figure 2, l'architecture de composants de données 200 comprend des cartes d'interface de communications de données 205 et 210 coopérant pour communiquer des données 230 sur des liaisons physiques 220. Les cartes de communications d'interface de données 205 et 210 comprennent au moins un coeur de transmission et au moins un coeur de réception. Les liaisons physiques 220 se fixent aux cartes d'interface de communications de données 205 et 210 à travers des connecteurs physiques 225.
En fonctionnement, un exemple d'environnement informatique (non représenté) coopère avec des cartes d'interface de communications de données 205 et 210 pour communiquer des données entre des cartes d'interface de communications de données 205 et 210. Dans l'implémentation illustrative, les cartes d'interface de communication de données peuvent résider dans des emplacements géographiques disparates dans l'exemple d'environnement informatique (non représenté) ou peuvent résider comme partie de l'une des cartes de circuit imprimé (PCB) de l'exemple d'environnement informatique (non représenté). Comme cela est représenté, les données peuvent être communiquées dans un sens sélectionné ou de manière bidirectionnelle, comme cela est indiqué par les flèches sur les liaisons physiques 220 et les données 230, entre les coeurs de transmission et les coeurs de réception des interfaces de communication de données 205 et 210. En outre, il est apprécié que les liaisons physiques 220 sont décrites présentant une épaisseur de ligne différente pour indiquer des supports de liaison physique différente 220.
En outre, comme cela est représenté, le cadre en pointillés 215 représente les composants d'un exemple de plan arrière de communications de données. Dans l'implémentation fournie, le plan arrière 215 est représenté comme comprenant une paire de coeurs de transmission/réception fonctionnant pour communiquer des données. En particulier, les données sont traitées par un c ur de transmission 235 d'interface de communications de données 205 pour la communication à travers un connecteur physique 225 et des liaisons physiques 220 vers un c ur de réception 245 de l'interface de communications de données 210. De même, les données peuvent être traitées pour la communication par le coeur de transmission 250 de l'interface de communications de données 210 vers le c ur de réception 240 de l'interface de communications de données 205. En outre, des paires de c ur de transmission/réception 235, 240 et 245, 250 peuvent coopérer pour former un canal de communications. Comme un canal de communications, les paires de c urs de transmission/réception peuvent être alignées et formées pour traiter les données selon un protocole d'encodage sélectionné tel qu'un encodage huit bits dix bits (8blOb).
En outre, comme cela est représenté sur la figure 2, les données 230 peuvent comprendre un nombre de paquets. En particulier, des données 230 peuvent comprendre une partie d'en-tête et une partie de paquet de données. La partie de paquet de données peut en outre contenir de petits paquets de données. Il est apprécié que dans l'implémentation illustrative fournie, un petit paquet peut être considéré comme un paquet de données qui est inférieur en taille qu'un paquet de données normal de taille complète. En fonctionnement, diverses données, informations de contrôle, de formation et de gestion de canal peuvent être communiquées sur un exemple d'architecture de communications de données 200 comme des données 230.
La figure 3 représente un schéma de principe d'un exemple d'environnement de c ur de transmission 300 décrivant ses composants et leur coopération. Comme cela est représenté sur la figure 3, l'exemple d'environnement de coeur de transmission 300 comprend une pluralité de coeurs de transmission allant du c ur de transmission 300-1 au coeur de transmission 300-n. Le coeur de transmission 300-1 est représenté comme comprenant un bloc de logique, une pluralité de convertisseurs parallèle- série et de pilotes du convertisseur parallèle-série 1 au convertisseur parallèle-série n, et du pilote 1 au pilote n, respectivement. En outre, le coeur de transmission 300-1 coopère avec un composant de communications de données externe (non représenté) pour obtenir un signal d'horloge CLK. En outre, comme cela est représenté, le coeur de transmission 300-1 comprend une logique qui gère les ensembles d'instruction pour instruire les composants de coeur de transmission 300- 1 (par exemple un convertisseur parallèle-série 1) pour réaliser des fonctions selon des opérations de communications de données. La logique du coeur de transmission 300-1 peut également agir pour gérerun ou plusieurs modules et mécanismes destinés à être utilisés pendant les opérations de communications de données, notamment, mais sans s'y limiter, un moniteur de statut de formation de liaison, un module de formation de liaison, un module de contrôle, un tampon de données, un module de formation de liaison, un module de bit de parité et un module d'accusé réception de transmission de données.
En fonctionnement, les données sont fournies comme une entrée vers l'un des convertisseurs parallèle-série du c ur de transmission 301. Les données sont encodées selon un protocole d'encodage sélectionné et est préparé pour la communication par un des pilotes du coeur de transmission vers un composant de communications de données coopérant au niveau d'un des canaux de sortie du coeur de transmission. Le protocole d'encodage peut utiliser un signal CLK pour encoder un nombre de bits dans un cycle sélectionné du signal CLK. Par exemple, les données A peuvent être encodées par le convertisseur parallèle-série 1 du c ur de transmission 300-1 selon un protocole d'encodage sélectionné et préparées pour la communication par le pilote 1 pour produire les données encodées au niveau de la sortie du canal A suivant les instructions fournies par la logique du c ur de transmission 300-1. De même, les données B peuvent être encodées par le convertisseur parallèle-série 2 du c ur de transmission 300-1 selon un protocole d'encodage sélectionné et préparées pour la communication par le pilote 2 pour produire des données encodées au niveau du canal B. Un tel procédé d'encodage et une telle préparation de communication de données sont réalisés à travers les convertisseurs parallèle-série et les pilotes restants du coeur de transmission 300-1 et les autres coeurs de transmission de l'environnement de coeur de transmission 300.
La figure 4 représente un schéma de principe de l'exemple d'environnement de coeur de réception 400 illustrant ses composants et leur coopération. Comme cela est représenté sur la figure 4, l'exemple de coeur de réception 400 comprend une pluralité de coeurs de réception allant du coeur de réception 400-1 au coeur de réception 400-n. Le coeur de réception 400-1 est représenté comme comprenant un bloc de logique, une pluralité de convertisseurs série-parallèle et des pilotes du convertisseur série-parallèle 1 au convertisseur série-parallèle n et du pilote 1 au pilote n, respectivement. En outre, le coeur de réception 400- 1 coopère avec un composant de communications de données externe (non représenté) pour obtenir un signal d'horloge CLK. En outre, comme cela est représenté, le coeur de réception 400-1 comprend une logique qui gère des ensembles d'instructions pour instruire les composants du coeur de réception 400-1 (par exemple le convertisseur série-parallèle 1) de réaliser des fonctions selon des opérations de communications de données. La logique du coeur de réception 400-1 peut également agir pour gérer un ou plusieurs modules et mécanismes pour une utilisation pendant les opérations de communications de données comprenant, sans s'y limiter, un moniteur de statut de formation de liaison, un module de formation de liaison, un module de contrôle, un tampon de données, un module de formation de liaison, un module de bit de parité et un module d'accusé de réception de transmission de données.
En fonctionnement, les données encodées sont 35 fournies comme une entrée à l'un des convertisseurs série-parallèle du coeur de réception 400-1. Les données sont décodées selon un protocole de décodage sélectionné et sont préparées pour la communication par l'un des pilotes de coeur de réception à un composant de communications de données cocpérant au niveau de l'une des sorties du convertisseur série-parallèle du coeur de réception. Le protocole de décodage peut utiliser le signal CLK pour décoder un nombre de bits dans un cycle sélectionné du signal CLK. Par exemple, les données encodées A peuvent être décodées par le convertisseur série-parallèle 1 du coeur de réception 400-1 selon un protocole de décodage sélectionné et préparées pour la communication par le pilote 1 pour produire les données A suivant les instructions fournies par la logique du coeur de réception 400-1. De même, les données encodées B peuvent être décodées par le convertisseur série-parallèle 2 du coeur de réception 400-1 selon un protocole de décodage sélectionné et préparées pour la communication par le pilote 2 pour produire les données B. Un tel procédé de décodage et la préparation de communication de données sont réalisés à travers les convertisseurs série-parallèle et les pilotes restants du coeur de réception 400-1 et les autres coeurs de réception de l'environnement de coeur de transmission 400.
Prises conjointement, la figure 3 et la figure 4 décrivent un exemple d'environnement de canal de communications de sorte que les données sont encodées pour la communication par un ou plusieurs coeurs de transmission pour le décodage et le traitement ultérieur par un ou plusieurs coeurs de réception. Bien que décrits comme des composants séparés, il est apprécié que des coeurs de transmission et des coeurs de réception peuvent résider sur un composant de communications unique (voir interface de communication de données 205 de la figure 2). En outre, les coeurs de transmission et les coeurs de réception peuvent fonctionner comme des paires pour former un ou plusieurs canaux de communications de données bidirectionnels.
Communiquer des données à travers des liaisons de communication La figure 5 représente le traitement réalisé par un exemple d'architecture de communications de données 200 lors de l'établissement d'un canal de communications. Comme cela est représenté, le traitement commence au bloc 500 et continue au bloc 505 où les composants de communications sont mis sous tension pour le fonctionnement. A partir de là, le traitement continue au bloc 510 où les liaisons de communications sont établies entre les composants d'architecture de communication de données. Les liaisons de communications sont ensuite formées au bloc 515 pour former un canal de communications. Les données de formation sont ensuite envoyées sur le canal de communications au bloc 520 pour tester le canal de communications. Une vérification est ensuite réalisée au bloc 525 pour déterminer si le test de canal de communications est réussi. S'il est réussi, le traitement continue au bloc 540 où une vérification est réalisée pour déterminer s'il existe des données à communiquer sur le canal de communications testé avec succès. Si au bloc 540 il est déterminé qu'il n'existe aucunes données à communiquer, le traitement revient au bloc 525. Cependant, s'il existe des données à communiquer sur le canal de communications testé et formé avec succès, le traitement passe au bloc 545 où les données sont encodées par des convertisseurs parallèle-série. Les données encodées sont ensuite communiquées sur le canal de communications aux convertisseurs série-parallèle au bloc 550. Les données sont ensuite décodées par les convertisseurs série-parallèle au bloc 555. Une vérification est ensuite réalisée au bloc 560 pour déterminer si les données ont été communiquées avec succès. Si les données sont transmises avec succès, le traitement revient au bloc 540 et continue à partir de là. Cependant, si les données ne sont pas communiquées avec succès, le traitement passe au bloc 565 où les convertisseurs série-parallèle demandent que les données soient renvoyées par les convertisseurs parallèle-série. A partir de là, le traitement revient au bloc 550 et continue à partir de là.
Cependant, si au bloc 525, il est déterminé que le test de canal de communications n'est pas réussi, le traitement passe au bloc 530 où les liaisons de communications sont reformées. A partir de là, le traitement passe au bloc 535 où les informations de commandes sont communiquées entre les composants de liaison de communications. A partir de là, le traitement revient au bloc 520 et continue à partir de là.
En fonctionnement, l'implémentation illustrative prévoit que la séquence de formation est dirigée par les convertisseurs série-parallèle d'une liaison de communications. En particulier, la formation initiale est complétée totalement lors de la reconnaissance d'une indication de l'écriture d'un registre de type logiciel sélectionné sur le convertisseur série- parallèle. A un tel moment, les données sont commandées sur la liaison par les convertisseurs parallèle-série du canal de communications. Dans le contexte des opérations de convertisseur série-parallèle, les convertisseurs série-parallèle gèrent un ou plusieurs ensembles d'instructions qui dirigent les convertisseurs série-parallèle pour détecter l'activité sur la liaison vers les convertisseurs parallèlesérie coopérant de signal pour commencer l'initialisation. Les convertisseurs série-parallèle et les convertisseurs parallèle- série des canaux de communications gèrent au moins un ensemble d'instructions pour diriger les canaux à se mettre sous tension. Lors d'une mise sous tension réussie, un test automatique par canal est réalisé à partir duquel les résultats sont collectés et comparés. L'ensemble d'instructions dirige ensuite les convertisseurs parallèle- série et les convertisseurs série-parallèle pour communiquer un modèle de données sélectionné qui est attendu par les convertisseurs série- parallèle qui permettent aux convertisseurs série-parallèle de déterminer un groupage d'unités de bit destiné à être utilisé par les protocoles d'encodage et de décodage utilisés par les convertisseurs parallèle-série et les convertisseurs série-parallèle.
En outre, un deuxième modèle de données reconnaissables est communiqué aux convertisseurs série-parallèle, lequel des convertisseurs série- parallèle attribuent comme les communications de données par petits paquets. En définissant les communications de données par petits paquets, les convertisseurs série-parallèle peuvent fonctionner pour associer des petits paquets ensemble dans des groupages constitués avec la manière dont ils ont été communiqués à l'origine. Une fois le deuxième modèle de données est communiqué et traité avec succès, un signal de commande est envoyé depuis les convertisseurs série-parallèle vers les convertisseurs parallèle-série des liaisons de communications indiquant que la formation est terminée. A ce point, les paquets de données peuvent être communiqués à travers les canaux formés.
En outre, l'implémentation illustrative prévoit que, si une erreur se produit sur la liaison de communications, la liaison peut réaliser un procédé de reformation. La reformation de liaison est similaire à la formation de liaison décrite ci-dessus en dehors de la mise sous tension des composants de canal de communication. La reformation peut être déclenchée par un nombre d'événements, y compris mais sans s'y limiter, la reconnaissance d'une erreur à travers la liaison de communications ou par réception d'un signal d'erreur sur la liaison générée par l'extrémité de réception de la liaison de communications.
Gérer les ecarts de communication de données (horodatage d'arrivée de données) L'architecture de communications de données illustrative est capable de gérer des temps d'arrivée de données incertains entre des composants coopérant. Dans le contexte d'une architecture de communications de données par SERDES, les données extraites à partir de l'extrémité de réception d'une liaison SERDES ne peut pas être synchronisée précisément à une horloge locale. Exprimé différemment, dans un quelconque cycle donné de l'horloge locale, la liaison peut ou non comprendre de nouvelles données valides à présent.
Dans l'implémentation illustrative et, comme cela est décrit ci-dessus, les transactions de données sont passées à travers les liaisons dans un format de paquets . Chaque paquet est formé d'un ou plusieurs petits paquets, selon la quantité d'informations et les données que la transaction comprend. Un petit paquet peut être considéré comme une unité de données utiles que la liaison transfère pendant une durée donnée. Un paquet peut comprendre un paquet d'en-tête suivi par un certain nombre de petits paquets de données pour remplir la transaction. L'en-tête peut comprendre des informations décrivant le type de paquets et d'autres informations pour gérer le paquet, telles que son adresse de destination.
Pour traverser un exemple d'infrastructure de communications de données d'environnement informatique, il peut être le cas qu'une transaction transmise à travers une liaison SERDES soit acheminée vers une autre liaison SERDES vers sa destination finale. Dans un tel contexte, une transaction de données peut prendre plusieurs cycles sur la liaison SERDES pour terminer le transfert de tous ses petits paquets. Une latence non souhaitée peut résulter si une transaction entière est mise en tampon avant d'être transférée vers la liaison de communications suivante. En outre, il peut être le cas qu'une liaison puisse échouer, sa tentative initiale de transmettre une partie d'un paquet créant une longue pause entre le début et la fin du paquet. En outre, l'opération de fréquence de différentes liaisons peut être différente, ce qui peut provoquer des écarts dans le flux de petits paquets sur une liaison plus rapide si les données arrivent depuis une liaison plus lente.
L'architecture de communications de données illustrative gère de tels cas en fournissant un mécanisme pour permettre un fonctionnement correct de la liaison SERDES pour cette application en présence d'écarts dans le flux des paquets de petite taille et de taille normale. En fonctionnement, l'interface de liaison SERDES au niveau de l'extrémité de transmission de la liaison (voir coeur de transmission 235 de la figure 2) utilise une valeur encodée ou de contrôle sélectionnée à envoyer à travers la liaison s'il ne dispose pas du petit paque valide suivant pour la transmission. En outre, l'extrémité de réception de la liaison (voir c ur de réception 245 de la figure 2) génère un petit paquet de contrôle sortant lorsqu'il ne trouve pas de données reçues récemment au niveau de son interface de liaison au début de son cycle d'horloge ou s'il trouve un petit paquet encodé. Les petits paquets de contrôle sont ignorés pendant le traitement de données.
La figure 6 représente le traitement réalisé lors de la gestion des écarts de communications de données pour des données communiquées à travers l'exemple d'architecture de communicat_ons de données 200 de la figure 2. Comme cela est représenté, le traitement commence au bloc 600 et continue au bloc 605 où une vérification est réalisée pour déterminer s'il existe des données à communiquer à travers les canaux de communication de l'exemple d'architecture de communications de données. S'il n'existe aucunes données à communiquer, le traitement revient au bloc 600 et continue à partir de 1à. Cependant, s'il existe des données à communiquer, le traitement passe au bloc 610 où les données à communiquer sont contrôlées pour les écarts de communiquées. En fonctionnement, les données peuvent être mises en tampon dans un tampon de données avant d'être encodées par un convertisseur parallèle-série de l'architecture de communications de données. C'est dans le tampon de données que les données sont traitées pour les écarts. Une vérification est ensuite réalisée au bloc 615 pour déterminer s'il existe un écart de communications de données. S'il n'existe aucun écart de communication de données, le traitement passe au bloc 620 où les données sont communiquées par le convertisseur parallèle-série vers un convertisseur série-parallèle coopérant. A partir de là, le traitement passe au bloc 605 et continue à partir de là.
Cependant, si au bloc 615, il est déterminé qu'il existe un écart de données, le traitement continue au bloc 625 où un petit paquet de contrôle est généré. Le petit paquet de contrôle est ensuite communiqué au convertisseur série-parallèle coopérant au bloc 630 pour notifier au convertisseur série-parallèle coopérant l'écart de communications. Le convertisseur série-parallèle traite le petit paquet de contrôle au bloc 635 et propage le petit paquet de contrôle à travers l'architecture de communications de données au bloc 640. Le traitement se termine ensuite au bloc 645. Détection d'erreurs L'exemple d'architecture de communications de données 200 de la figure 2 est également capable de réaliser une détection d'erreurs sur les données qui sont communiquées entre ses composants. Dans le contexte d'une architecture de communications de données par SERDES, la relance de transferts de données peut être nécessaire pour communiquer des données qui échouent pour passer précisément à travers la liaison. Pour relancer une transmission, une erreur est tout d'abord détectée. L'erreur peut être détectée pour identifier correctement le premier petit paquet qui est relancé pour continuer avec les opérations de communications de données.
Dans l'implémentation proposée, le standard d'encodage qui peut être utilisé pour formater les données pour une liaison SERDES peut être conçu pour suivre les caractéristiques électriques nécessaires pour que la liaison SERDES soit capable de transmettre des données aux fréquences élevées qu'elle utilise. En outre, suffisamment de transitions peuvent être réalisées sur le canal de sorte qu'une horloge peut être extraite du flux binaire au niveau de l'extrémité de réception de la liaison. En outre, le modèle de bit peut présenter une disparité neutre. Exprimé différemment, à un quelconque moment le nombre de uns et de zéros transmis peut être égal ou au plus différer de un. L'exemple de protocole d'encodage fonctionne de sorte que des erreurs de bit unique résultent en un encodage illégal. Il peut être le cas, cependant que dans certaines instances, l'encodage illégal puisse sembler légal mais génère la mauvaise disparité attendue. Lorsque l'erreur est de ce type, l'erreur n'est pas détectée jusqu'à ce que les modèles de données ultérieurs poussent la disparité au niveau de l'extrémité de réception de la liaison à +/-2.
Dans l'architecture de communications de données par SERDES, une liaison unique peut fonctionner pour passer de grands volumes d'informations rapidement à travers son canal. Ainsi, les erreurs peuvent être liées en envoyant des caractères de contrôle de paquet final spécial sur la liaison. Ceux-ci garantissent qu'une erreur est reconnue avant que le bloc de données soit relâché. Cette approche ajoute le temps système du besoin d'envoyer le caractère de contrôle spécial et peut fourcir des inefficacités dans le process de communications de données ajoutant une latence. En pratique, il peut prendre un cycle d'encodage pour envoyer un caractère de contrôle. Il est apprécié que pour une architecture de communications de données comprenant une pluralité de liaisons SERDES, une quantité significative de temps est requise pour traiter des caractères de contrôle menant aux inefficacités substantielles dans les communications de données.
La mise en oeuvre illustrative fournit une approche variante où l'architecture de communications de données reconnaît que le premier symptôme d'erreur du standard d'encodage peut être déterminé par la comparaison de la disparité de l'extrémité de réception (voir coeur de réception 245 de l'interface de communications de données 210 de la figure 2) et de l'extrémité de transmission (voir coeur de transmission 235 de l'interface de communications de données 205 de la figure 2) des données communiquées. Si la disparité utilisée pour transmettre les données est connue au niveau du récepteur, une erreur peut être détectée immédiatement. Pour atteindre cela, la disparité des liaisons utilisées pour envoyer un petit paquet est collectée et utilisée pour générer un code d'erreur à cinq bits. Cette valeur à cinq bits est ensuite passée à l'extrémité de réception de la liaison. Dans l'implémentation illustrative, un tel code d'erreur peut être communiqué à l'extrémité de réception de la liaison à l'aide d'un canal de liaison SERDES supplémentaire. Cette valeur peut être ensuite utilisée sur l'extrémité de réception de la liaison pour vérifier les disparités au niveau de la réception de la liaison, et pour demander immédiatement un renvoi de données depuis l'extrémité de transmission du canal de communications si les disparités ne sont pas les valeurs attendues.
En fonctionnement, l'implémentation illustrative utilise un encodage cinq bits à dix bits lors de la communication du code d'erreur. Les cinq bits sont envoyés deux fois, une fois comme vrai positif et une fois comme vrai négatif. De cette manière, le modèle dix bits comprend cinq uns et cinq zéros, atteignant une disparité neutre. Un tel traitement est également efficace de sorte que l'horodatage système peut être géré lors de l'utilisation d'un plan d'encodage 10 bits.
En outre, l'implémentation illustrative prévoit qu'à la fin de la formation de liaison, les données peuvent être communiquées à travers la liaison. Les données peuvent comprendre un en-tête, de petits paquets de données, s'ils sont disponibles pour la communication ou des informations de contrôle telles que de petits paquets de données de gestion de liaison.
Ces données, quel que soit le type, lorsqu'elles sont encodées produisent un modèle de 1 et de 0 présentant une disparité associée.
La figure 7 représente le traitement réalisé par l'exemple d'architecture de communications de données 200 lors de la réalisation de la détection d'erreur. Comme cela est représenté, le traitement commence au bloc 700 et continue au bloc 705 où une vérification est réalisée pour déterminer si les données doivent être communiquées à travers les composants d'un exemple d'architecture de communications de données 200 de la figure 2. Si la vérification au bloc 705 donne la détermination que les données ne doivent être communiquées, le traitement revient au bloc 700 et continue à partir de là. Cependant, si au bloc 705, il est déterminé que les données doivent être communiquées, le traitement passe au bloc 710 où la disparité des données à communiquer est calculée. A partir de là, un code d'erreur pour les données devant être communiquées est calculé à l'aide des disparités calculées par le convertisseur parallèle-série au bloc 715. Les données ainsi que le code d'erreur calculé sont ensuite communiquées par le convertisseur parallèle-série vers un convertisseur série-parallèle coopérant au bloc 720. Le convertisseur série-parallèle reçoit les données et calcule le code d'erreur en fonction des données communiquées au bloc 725. A partir de là, une vérification est réalisée pour déterminer si les codes d'erreur correspondent au bloc 730. Si les codes d'erreur ne correspondent pas au bloc 730, le traitement continue au bloc 735 où une demande de recommuniquer les données est envoyée par le convertisseur série-parallèle au convertisseur parallèle-série. Le convertisseur parallèle-série obtient les données pour la recommunication au bloc 740 et le traitement revient au bloc 710 et continue à partir de là.
Cependant, si au bloc 730 il est déterminé que les codes d'erreur générés par calcul par le convertisseur parallèle-série et le convertisseur sérieparallèle, respectivement, correspondent, le traitement passe au bloc 745 où les transactions de données sont continuées. A partir de là, le traitement revient au bloc 700 et continue à partir de là.
Echecs de liaison L'exemple d'architecture de communications de données 200 est également capable de gérer les échecs de liaison si les liaisons échouent pendant l'opération. L'implémentation illustrative fonctionne pour permettre la connexion avec l'infrastructure de l'exemple d'environnement informatique pour rester active lorsqu'une liaison échoue et ne force pas l'environnement informatique à devenir instable (par exemple, plantage).
Dans le contexte d'une architecture de communications de données par SERDES, les connexions point à point dans l'infrastructure de l'ordinateur peuvent être composées de plusieurs liaisons SERDES fonctionnant de concert pour fournir une bande passante de communications de données accrue. L'implémentation illustrative fournit l'utilisation d'une liaison SERDES supplémentaire à déployer sur un canal de liaison de rechange dans le cas où l'une des autres liaisons de communications échouent. En outre, l'implémentation illustrative peut détecter qu'un canal de liaison n'est pas fiable et de ne pas l'utiliser. L'implémentation prévoit également un protocole par lequel l'extrémité de réception (voir coeur de réception 245 de l'interface de communications de données 210 de la figure 2) de la liaison peut communiquer avec l'extrémité de transmission (voir coeur de transmission 235 de l'interface de communications de données 205 de la figure 2) de la liaison que le canal de liaison ne doit pas être utilisé. En fonctionnement, l'implémentation illustrative détermine qu'une liaison a échoué pendant la séquence de formation de liaison. La formation de liaison se produit en réponse à une erreur détectée sur la transmission normale de données ou sur une mise à niveau de liaison initiale. La reconnaissance qu'une liaison échoue comprend, entre autres événements, la perte du signal de détection de présence pour cette liaison; l'échec de cette liaison à passer le test automatique de liaison; l'échec de cette liaison à signaler un alignement approprié.
En réponse à un échec de liaison, la logique sur l'extrémité de réception de la liaison décale les canaux de liaison logiques de la liaison en échec à la dernière liaison numéroté éloignée de la liaison physique en échec. En outre, un nouveau mappage est encodé dans un champ à 5 bits et renvoyé vers l'extrémité d'envoi de la liaison. Là, le nouveau mappage est utilisé pour programmer la logique de transmission pour entraîner les liaisons dans la tentative de formation suivante sur les canaux physiques appropriés.
La figure 8 représente le traitement réalisé par l'exemple d'architecture de communications de données 200 lors de la gestion d'un échec de liaison. Comme cela est représenté, le traitement commence au bloc 800 et continue au bloc 805 où l'architecture de communications de données lance la formation de la liaison de communications. A partir de là, un convertisseur parallèle-série et un convertisseur série-parallèle de l'architecture de communications de données 200 sont associés pour créer une liaison de communications logique au bloc 810. La liaison de communications logique créée est ensuite actionnée sur une liaison de communications physique au bloc 815. A partir de là, le traitement passe au bloc 820 où la formation de la liaison de communications est contrôlée pour identifier de quelconques échecs de liaison. Une vérification est ensuite réalisée au bloc 825 pour déterminer s'il existe des échecs sur la liaison. S'il n'existe aucun échec comme cela est déterminé par la vérification au bloc 825, le traitement continue au bloc 845 où la formation de la liaison est terminée. Les transactions de communications de données sont ensuite réalisées sur la liaison formée au bloc 850. Le traitement se termine ensuite au bloc 855.
Cependant, si au bloc 825 il est déterminé qu'un échec de liaison s'est produit, le traitement passe au bloc 830 où la liaison de communicationslogique est décalée à distance de la liaison de communications physique en échec. Un nouveau mappage fournissant de nouveaux agencements de liaison de communication logique et physique est créé au bloc 835 et les liaisons de communication logiques et physiques sont alignées selon le nouveau mappage au bloc 840. A partir de là, le traitement revient au bloc 815 pour retester les canaux qui viennent d'être mappés pour un fonctionnement approprié. A partir de là, le traitement continue comme cela est montré.
Il est apprécié que, après un nombre sélectionné de tentatives en échec, un signal est envoyé à travers les composants cooperant de l'architecture de communications de données 200 pour indiquer que la liaison a échoué. Dans un tel contexte, la liaison n'est pas utilisée pour les transactions de communications de données.
Formation et échec de formation L'exemple d'architecture de communications de données 200 est également capable de gérer la reformation de liaisons en échec. Dans le contexte des architectures de communications de données par SERDES, l'implémentation illustrative utilise une pluralité de nombreuses liaisons SERDES utilisées ensemble pour fournir une bande passante élevée et une latence faible. En pratique, avant que les liaisons SERDES puissent être utilisées pour transférer des données, elles sont d'abord formées en envoyant des séquences de données connues appropriées que l'extrémité de réception de la liaison peut utiliser pour aligner les liaisons de manière appropriée. En outre, la formation donne également une opportunité de tester que les liaisons transmettent d'autres séquences de données connues de manière précise. Dans certaines circonstances, la formation de liaison peut échouer pendant une première tentative et être réussie pendant une deuxième tentative. Dans ce contexte, l'implémentation illustrative fonctionne pour communiquer à partir de l'extrémité de transmission du canal de communications (voir coeur de transmission 235 de l'interface de communications de données 205 de la figure 2) vers l'extrémité de réception (voir coeur de réception 245 de l'interface de communications de données 210 de la figure 2) du canal de communication des informations qui peuvent permettre à la formation d'être réussie pendant une deuxième tentative.
L'implémentation illustrative fournit en outre un mécanisme pour transmettre des informations à travers la liaison lorsque la formation de liaison a échoué. En opération, les séquences de données pour tester les liaisons sont formatées avant d'être présentées sur l'encodeur d'une telle manière que le même encodage binaire est généré, quelle que soit la disparité précédente du plan d'encodage, c'est-à-dire, une disparité neutre.
Sur l'extrémité de réception de la liaison, les données provenant de l'interface SERDES est un modèle reçu de bit statique, puisque les données sont formatées pour maintenir une disparité neutre. Ainsi, même si l'alignement entre les liaisons et chacune autre des horloges de logique de réception n'est pas garanti, les données fournies peuvent être traitées comme une valeur statique. En outre, en fonctionnement, l'implémentation illustrative prévoit que des copies des séquences de données sont comparées l'une à l'autre sur l'extrémité de réception de la liaison de communications pour disqualifier l'une quelconque des liaisons qui peut être mauvaise. En outre, les informations peuvent ensuite être utilisées pour reprogrammer chaque extrémité de la liaison pour modifier la manière dont les données sont sensées arriver pour se reformer autour d'un quelconque défaut.
La figure 9 représente le traitement réalisé par l'exemple d'architecture de communications de données 200 lors de la gestion des échecs de formation de liaison. Comme cela est représenté, le traitement commence au bloc 900 et continue au bloc 905 où l'exemple d'architecture de communications de données lance la formation de la liaison de communications. A partir de là, le traitement continue au bloc 910 où les données de gestion de liaison sont générées. Les données de gestion de liaison. sont ensuite communiquées à travers la gestion de liaison depuis les convertisseurs parallèle-série et les convertisseurs série-parallèle au bloc 915. La formation est contrôlée au bloc 920 pour identifier les échecs de formation de liaison. Une vérification est ensuite réalisée au bloc 925 pour déterminer s'il existe de quelconques échecs de formation de liaison. S'il n'existe aucun échec de formation de liaison, le traitement passe au bloc 950 où les transactions de communications de données sont réalisées. A partir de là, le traitement se termine au bloc 955.
Cependant, si au bloc 925, il est déterminé qu'il existe des échecs de formation de liaison, le traitement continue au bloc 930 où les données de gestion de liaison sont traitées par les convertisseurs série- parallèle. Les données de gestion de liaison sont ensuite comparées à travers les convertisseurs série-parallèle coopérant pour identifier les échecs de formation au bloc 935. Les convertisseurs parallèle-série et les convertisseurs série-parallèle sont ensuite reprogrammés pour se reformer autour de l'échec de formation de liaison au bloc 940. A partir de là, le traitement revient au bloc 905 et continue comme cela est représenté.
Il est apprécié que, après un nombre sélectionné d'échecs comme cela est déterminé au bloc 825, une détermination est effectuée que la liaison a échoué et n'est pas utilisée pour les transactions de communications de données. Dans ce contexte, un traitement supplémentaire comme cela est décrit par la figure 8 peut être réalisé pour remapper les canaux logiques et physiques.
Gestion des données corrompues Un exemple d'architecture de communications de données 200 est également capable d'identifier et de marquer les données comme corrompues pour augmenter la robustesse de l'architecture de communications de données. Dans le contexte des architectures de communications de données par SERDES, l'implémentation illustrative fournit un mécanisme pour reconnaître lorsque les données ne sont pas transmises avec succès à travers la liaison et marque ces données comme corrompues. Cela peut se produire lors le petit paquet de données est corrompu avant d'être transmis. L'implémentation illustrative fonctionne pour permettre aux données en échec d'être acceptées, de sorte que la liaison peut continuer à transmettre des données après le petit paquet de données en échec. En outre, le petit paquet de données en échec est marqué comme corrompu et envoyé vers sa destination.
En outre, l'implémentation illustrative permet à une liaison d'accepter un petit paquet de données marqué comme corrompu et de terminer une quelconque transaction en cours lorsque la liaison rencontre des échecs. Cela est réalisé en envoyant les données fabriques pour remplir la transaction et en marquant les données entières, partielles et caractère de remplissage, comme corrompues. Ce faisant, les transactions partiellement transmises sont empêcher d'obstruer d'autres interfaces de liaison, permettant à l'infrastructure de contenir l'échec vers des traitements qui utilisent activement la liaison en échec.
La figure 10 représente le traitement réalisé lors de l'identification et du marquage des données comme corrompues pendant les transactions de communications de données. Comme cela est représenté, le traitement commence au bloc 1000 et continue au bloc 1005 où une liaison de communications est établie entre des composants coopérant de l'exemple d'architecture de communications de données 200. A partir de là, le traitement continue au bloc 1010 où la transmission de données à travers la liaison de communication établie est contrôlée. Les données qui n'ont pas été transmises avec succès à travers la liaison de communications sont identifiées au bloc 1015. les données transmises sans succès identifiées sont marquées comme corrompues au bloc 1020. A partir de là, une vérification est réalisée au bloc 1025 pour déterminer si les données corrompues contiennent des données partielles. Si la vérification au bloc 1025 donne qu'il n'existe aucunes données partielles, le traitement passe au bloc 1040 où les données marquées comme corrompues sont traitées par les composants de l'architecture de communications de données. A partir de là, les données marquées comme corrompues sont propagées à travers l'architecture de communications de données au bloc 1045. Les transactions de communications de données sont ensuite réalisées au bloc 1050. Le traitement se termine ensuite au bloc 1055.
Si, cependant, au bloc 1025, il est déterminé qu'il existe des données partielles, le traitement passe au bloc 1030 où des données de remplissage sont générées pour s'annexer aux données corrompues partielles. Les données de remplissage et les données corrompues partielles sont ensuite marquées collectivement comme un ensemble de données corrompues au bloc 1035. A partir de là, le traitement passe au bloc 1040 et continue à partir de là.
En outre, l'implémentation illustrative prévoit que les données sont identifiées comme corrompues en résultat d'une ou plusieurs itérations de tentatives réussies de formation de liaison de communications.
Exprimé différemment, si la liaison de communications peut finalement être formée avec succès mais que la transmission d'un petit paquet de données spécifique échoue de manière répétée, le problème est déterminé comme étant un problème avec les données. Codes d'erreur à utiliser dans la détection d'erreurs L'exemple d'architecture de communications de données 200 de la figure 2 est également capable de détecter les erreurs efficacement à travers une pluralité de ses canaux de communications sans réaliser un traitement extensif. Dans le contexte d'une architecture de communications de données par SERDES, l'implémentation illustrative fournit un encodage d'erreur qui fonctionne à l'aide du protocole d'encodage de l'architecture de communications de données.
En fonctionnement, les transactions (ou paquets de données) sont transmises à travers un ensemble de plusieurs canaux de liaison en unités appelées petits paquets de données, chaque transaction nécessitant un nombre de petits paquets de données selon sa taille. Chaque petit paquet de données comprend un nombre (par exemple 8) bits logiques par canal qui sont transmis dans un protocole d'encodage de bit numéroté (par exemple 10). Ce plan de détection d'erreur fonctionne sur un petit paquet de données à la fois. En pratique, l'encodage 8blOb standard utilisé par canal est capable de détecter des erreurs de bit unique dans un canal. Cette détection est combinée à la logique pour calculer huit bits de parité à travers les canaux transportant le petit paquet de données. Le bit de parité est fondé sur du ler, 2ème, Sème, , Sème bit des 8 bits de données envoyés sur le canal. Ces 8 bits de parité sont ensuite utilisés comme les données à transmettre à travers un canal de liaison supplémentaire. Des erreurs peuvent être détectées en calculant les bits de parité pour les données transmises sur un canal de communications sur l'extrémité de réception.
La figure 11 représente le traitement réalisé par l'exemple d'architecture de communications de données 200 lors de la détection d'erreurs à travers une pluralité de canaux de communications. Comme cela est représenté, le traitement commence au bloc 1100 et continue au bloc 1105 où une liaison de communications est établie entre les composants de l'exemple d'architecture de communications de données 200. A partir de là, le traitement passe au bloc 1110 où des bits de parité sont calculés pour les données communiquées en fonction du protocole d'encodage comprenant n bits. Les bits de parité sont ensuite communiqués à travers la liaison de communications au bloc 1115 depuis les convertisseurs parallèle-série aux convertisseurs série-parallèle. Les bits de parité sont ensuite traités par les convertisseurs série-parallèle au bloc 1120. Une vérification est ensuite réalisée au bloc 1125 pour déterminer si de quelconques erreurs ont été identifiées à l'aide des bits de parité. Si aucune erreur n'est identifiée au bloc 1125, le traitement passe au bloc 1135 où des transactions de communications de données sont réalisées. Le traitement se termine ensuite au bloc 1140.
Cependant, si au bloc 1125, il est déterminé qu'il existe des erreurs identifiées, le traitement passe au bloc 1130 où des données sont recommuniquées depuis le convertisseur parallèle-série vers le convertisseur série-parallèle. A partir de là, le traitement revient au bloc 1110 et continue comme cela est représenté.
Il est apprécié que, après un nombre de tentatives de recommuniquer les données depuis le convertisseur parallèle-série vers le convertisseur série-parallèle et que les erreurs continuent d'être identifiées, alors ces données peuvent être marquées comme corrompues suivant le traitement décrit ci-dessus sur la figure 10.
Relance de niveau liaison L'exemple d'architecture de communications de données 200 de la figure 2 est également capable d'accuser réception du transfert réussi de données entre ses composants. Dans le contexte d'une architecture de communications de données par SERDES, les transactions peuvent être transmises à travers les liaisons dans un format de : paquet . Un paquet peut être formé à partir d'un ou plusieurs paquets selon la quantité d'informations et de données que la transaction comprend. Un petit paquet de données peut être considéré comme l'unité de données utiles que la liaison est destinée à transférer en une fois. Le paquet peut comprendre un petit paquet d'en-tête suivi par un certain nombre de petits paquets de données pour remplir la transaction. L'en- tête, entre autres choses, peut comprendre des informations décrivant le type de paquet et d'autres informations pour gérer le paquet, telles que son adresse de destination.
Pour obtenir la capacité de renvoyer ou de relancer le transfert de petits paquets de données à travers la liaison, l'implémentation illustrative gère sensiblement tous les petits paquets de données et de paquets de données d'en-tête transférés à travers la liaison dans un tampon de données jusqu'à ce qu'un moment tel qu'un signal d'accusé réception soit reçu depuis l'extrémité opposée de la liaison. Une fois que l'accusé réception d'un transfert réussi est reçu, l'entrée de tampon de données contenant ce petit paquet d'en-tête et de données peut être libérée pour être utilisé par un autre petit paquet de données. Dans l'implémentation proposée, généralement, pas plus de petits paquets de données et de paquets de données d'en-tête ne peuvent être envoyées à travers la liaison qu'il n'existe d'entrées de tampon de relance de niveau liaison pour les gérer. S'il existe un échec pour transférer correctement un petit paquet de données à travers la liaison, lors le premier petit paquet de données et d'en-tête à être renvoyé à travers la liaison est le petit paquet de données le plus ancien dans le tampon de données qui n'a pas fait l'objet d'un accusé réception.
L'implémentation illustrative propose un mécanisme et un protocole pour obtenir l'accusé réception d'un transfert réussi d'un petit. paquet de données. En pratique, le petit paquet de données transféré à travers la liaison comprend une balise qui lui est associée qui correspond à l'adresse d'entrée du tampon de données où le petit paquet de données est stocké. Le petit paquet d'en-tête contient un champ réservé pour l'accusé réception de transfert réussi. Lorsqu'un en-tête est envoyé à travers la liaison, ce champ est rempli avec l'adresse du dernier petit paquet de données reçu avec succès à ce moment. Lors de l'envoi de l'adresse, si un accusé réception est perdu, l'accusé réception suivant corrige automatiquement le mécanisme.
Dans l'instance où il n'existe aucun caractère valide prêt à transporter l'accusé réception d'adresse à travers la liaison, l'implémentation illustrative crée un en-tête inactif pour transporter l'accusé réception en retour à travers la liaison.
Enfin, après qu'un échec de transfert de liaison est corrigé, mais avant qu'une opération normale soit redémarrée, l'adresse du petit paquet de données le plus récemment reçu avec succès est envoyée comme faisant partie de la séquence de redémarrage de liaison pour garantir que les petits paquets de données reçus avec succès font l'objet d'un accusé réception approprié.
La figure 12 représente le traitement réalisé par l'exemple d'architecture de communications de données 200 de la figure 2 lors de la création et la transaction d'accusés réception pour des communications de données réussies. Comme cela est représenté, le traitement commence au bloc 1200 et continue au bloc 1205 où une liaison de communications est établie entre des composants coopérant de l'architecture de communications de données 200 de la figure 2. Les petits paquets de données sont ensuite stockés dans un tampon de données coopérant au bloc 1210. A partir de là, le traitement passe au bloc 1215 où une adresse est générée pour le petit paquet de données. Les données avec l'adresse de petit paquet de données sont ensuite communiquées depuis un convertisseur parallèle-série de transmission au bloc 1220. Une vérification est ensuite réalisée au bloc 1225 pour déterminer si les données ont été communiquées correctement vers le convertisseur série-parallèle de réception... Si la vérification au bloc 1225 indique que les données n'ont pas été communiquées correctement, le traitement passe au bloc 1230 où les données font l'objet d'une demande d'être renvoyées par l'extrémité de transmission de la liaison de communications utilisant l'adresse de petit paquet de données reçu le plus récent. A partir de là, le traitement revient au bloc 1220 et continue comme cela est représenté.
Cependant, si au bloc 1225, il est déterminé que les données sont communiquées correctement, le traitement passe au bloc 1235 où une vérification est réalisée pour déterminer si un en-tête est disponible pour transporter l'accuser réception depuis l'extrémité de réception de la liaison de communications vers l'extrémité de transmission de la liaison de communications. Un retard peut se produire avant que l'accusé réception ne soit préparé car les petits paquets de données sont d'abord envoyés pour compléter les paquets sortant actuels. Si la vérification au bloc 1235 indique qu'un en-tête est disponible, le traitement passe au bloc 1255 où l'adresse de petit paquet de données est communiquée depuis l'extrémité de réception du canal de communications vers l'extrémité de transmission du canal de communications comme accusé réception d'un transfert réussi à l'aide de l'en-tête disponible. Le traitement passe au bloc 1260 où l'adresse de petit paquet de données est libéré e depuis le tampon de données coopérant. Le traitement se termine ensuite au bloc 1250.
Si, cependant, au bloc 1235, il est déterminé qu'aucun en-tête n'est disponible, un en-tête inactif est créé pour transporter l'accusé réception d'un transfert réussi au bloc 1240. L'en-tête inactif est communiqué depuis l'extrémité de réception de la liaison de communications vers l'extrémité de transmission de la liaison de communications au bloc 1245. Le traitement passe de nouveau au bloc 1260 où l'adresse de petit paquet de données est libérée depuis le tampon de données coopérant. Le traitement se termine au bloc 1250.
En résumé, le dispositif et les procédés décrits ici fournissent une architecture de communication de données destinée à être utilisée comme réseau de communication d'environnements informatiques qui réduit la latence des données. Il est compris, cependant, que la présente invention est susceptible de nombreuses modifications et variantes de construction. Il n'existe aucune intention de limiter la présente invention aux constructions spécifiques décrites ici. Au contraire, la présente invention est destinée à couvrir toutes les modifications, variantes de construction et équivalents entrant dans la portée et l'esprit de la présente invention.
Il doit également être noté que la présente invention peut être implémentée dans une variété d'environnements informatiques (y compris les environnements informatiques fixes et sans fil), d'environnements informatiques partiels et d'environnements du monde réel. Les diverses techniques décrites ici peuvent être implémentées dans un matériel ou un logiciel ou une combinaison des deux. De préférence, les techniques sont implémentées dans des environnements informatiques gérant des ordinateurs programmables qui comprennent un processeur, un support de stockage lisible par le processeur (y compris la mémoire vive et la mémoire morte et/ou des éléments de stockage), au moins un dispositif d'entrée et au moins un dispositif de sortie. La logique du matériel informatique coopérant avec divers ensembles d'instructions est appliquée aux données pour réaliser les fonctions décrites ci-dessus et pour générer des informations de sortie. Les informations de sortie sont appliquées à un ou plusieurs dispositifs de sortie. Des programmes utilisés par l'exemple de matériel informatique peuvent être de préférence implémentés dans divers langages de programmation, notamment le langage de programmation de procédure haut niveau ou orienté objet pour communiquer avec un système informatique. Par exemple, le dispositif et les procédés décrits ici peuvent être implémentés dans un langage d'assemblage ou machine si nécessaire. Dans tous les cas, le langage peut être un langage compilé ou interprété. Chaque tel prcgramme informatique est de préférence stocké sur un support ou dispositif de stockage (par exemple un disque ROM ou magnétique) qui est lisible par un ordinateur programme à objet général ou particulier pour configuration et faire fonctionner l'ordinateur lorsque le support ou dispositif de stockage est lu par l'ordinateur pour réaliser les procédures décrites ci-dessus. Le dispositif peut également être considéré pour être implémenté comme un support de stockage lisible par ordinateur, configuré avec un programme information où le support de stockage ainsi configuré amène un ordinateur à fonctionner d'une manière spécifique et prédéfinie.
Bien qu'un exemple d'implémentation de la présente invention soit décrit en détail ci-dessus, l'homme du métier appréciera facilement que de nombreuses modifications supplémentaires sont possibles dans les exemples de mode de réalisation sans s'éloigner matériellement des enseignements et avantages novateurs de la présente invention. Par conséquent, ces modifications sont destinées à être comprises dans la portée de la présente invention. La présente invention peut être mieux définie par les revendications exemplaires suivantes.
Claims (10)
1. Dans un système informatique (100) comprenant une architecture de communications de données (200), procédé pour communiquer des données à l'aide de tampons de données de relance comprenant: l'établissement (1205) d'un canal de communications entre un convertisseur parallèle-série (3001) et un convertisseur série-parallèle (400-1) pour la communication de petits paquets de données; le stockage (210) des petits paquets de données dans un tampon de relance de niveau liaison pour la communication à travers les canaux de communication (215) ; la génération (1215) d'une adresse pour chacun des petits paquets de données, dans laquelle les adresses agissent comme des pointeurs vers les emplacements des petits paquets de données dans le tampon de relance de niveau liaison; la communication (1255) de l'adresse du petit paquet de données reçu depuis une extrémité de réception d'un canal de communication (215) comme accusé réception d'un transfert réussi des données; et la libération (1260) de l'entrée de tampon de relance de niveau liaison depuis le tampon de relance de niveau liaison pour utilisation par un petit paquet de données suivant.
2. Procédé selon la revendication 1, comprenant en outre la génération d'une balise de relance devant être comprise dans un sous-paquet d'entête de données, dans lequel la balise de relance contient des informations accusant réception du transfert de données réussi.
3. Procédé selon la revendication 2 comprenant en outre la communication de l'adresse du petit paquet de données à travers le canal de communication (215) comme partie du sous-paquet d'en-tête de données entre le convertisseur parallèle-série et le convertisseur série- parallèle.
4. Procédé selon la revendication 3 comprenant en outre l'alimentation de l'adresse du petit paquet de données par un composant sur l'extrémité de réception du canal de communication (215) avec des informations indicatrices du petit paquet le plus récent reçu avec succès par l'extrémité de réception du canal de communications (215).
5. Procédé selon la revendication 4, comprenant en outre l'accusé réception (1255) d'un transfert réussi en transmettant l'adresse du petit paquet entre le convertisseur parallèle-série et le convertisseur sérieparallèle.
6. Procédé selon la revendication 5, comprenant en outre le renvoi d'une adresse de dernier petit paquet de données qui a fait l'objet d'un accusé réception correct à la fin d'une séquence de reformation, dans lequel l'adresse du petit paquet de données est compris dans un sous-paquet de formation.
7. Procédé selon la revendication 1 comprenant en outre la création (1240) d'un en-tête inactif dans le cas où il n'existe aucune adresse de petit paquet de données valide à envoyer depuis le convertisseur parallèlesérie (300-1) vers le convertisseur série-parallèle (400-1).
8. Procédé selon la revendication 7, dans lequel l'en-tête inactif communique un accusé réception de 30 transmission de données.
9. Procédé selon la revendication 1, comprenant en outre la communication de l'adresse du petit paquet de données le plus récent transmis avec succès comme partie d'une séquence de redémarrage de liaison sélectionnée.
10. Procédé pour accuser réception de la transmission réussie de données ayant, associées à celles-ci, une adresse de petit paquet à travers une architecture de communications de données par SERDES (200) comprenant: la gestion d'une copie des données dans un tampon de relance jusqu'à ce qu'un accusé réception (1255) soit reçu indiquant un transfert réussi des données; le traitement (1255) de l'adresse de petit paquet pour déterminer si un transfert réussi de données s'est produit à travers un canal de communications; et la libération (1260) de la copie des données dans le tampon de relance.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/756,667 US7606253B2 (en) | 2004-01-12 | 2004-01-12 | Successful transactions |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2865089A1 true FR2865089A1 (fr) | 2005-07-15 |
| FR2865089B1 FR2865089B1 (fr) | 2007-09-07 |
Family
ID=34701308
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0500209A Active FR2865089B1 (fr) | 2004-01-12 | 2005-01-10 | Procede pour communiquer des donnees a l'aide de tampons de donnees de relance |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7606253B2 (fr) |
| FR (1) | FR2865089B1 (fr) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7711878B2 (en) * | 2004-05-21 | 2010-05-04 | Intel Corporation | Method and apparatus for acknowledgement-based handshake mechanism for interactively training links |
| US20050262184A1 (en) * | 2004-05-21 | 2005-11-24 | Naveen Cherukuri | Method and apparatus for interactively training links in a lockstep fashion |
| US8782237B2 (en) | 2010-01-28 | 2014-07-15 | Intel Corporation | Audio/video streaming in a topology of devices |
| US9007904B2 (en) | 2011-11-17 | 2015-04-14 | International Business Machines Corporation | System to improve an ethernet network |
| US10430789B1 (en) | 2014-06-10 | 2019-10-01 | Lockheed Martin Corporation | System, method and computer program product for secure retail transactions (SRT) |
| US9225695B1 (en) | 2014-06-10 | 2015-12-29 | Lockheed Martin Corporation | Storing and transmitting sensitive data |
| US10320528B2 (en) * | 2017-04-21 | 2019-06-11 | Silicon Laboratories Inc. | Fault tolerant communication channel |
| US11336592B2 (en) | 2020-08-14 | 2022-05-17 | Google Llc | Flexible link level retry for shared memory switches |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4322793A (en) * | 1979-01-02 | 1982-03-30 | International Business Machines Corp. | Communication controller transparently integrated into a host CPU |
| US4490788A (en) * | 1982-09-29 | 1984-12-25 | Schlumberger Technology Corporation | Well-logging data processing system having segmented serial processor-to-peripheral data links |
| US4677614A (en) * | 1983-02-15 | 1987-06-30 | Emc Controls, Inc. | Data communication system and method and communication controller and method therefor, having a data/clock synchronizer and method |
| JPH0369244A (ja) * | 1989-08-08 | 1991-03-25 | Nec Corp | データ受信制御回路 |
Family Cites Families (92)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3676859A (en) | 1970-12-23 | 1972-07-11 | Ibm | Data communication system incorporating device selection control |
| GB1478363A (en) * | 1974-07-30 | 1977-06-29 | Mullard Ltd | Data transmission systems |
| DE3309878C1 (de) | 1983-03-18 | 1984-06-14 | Caroline Christ Fabrikation chemischer Erzeugnisse, 8060 Dachau | Vorrichtung zum Reinigen solcher Teile von Kunststoffverarbeitungsmaschinen,an denen Kunststoffreste anhaften |
| US4569052A (en) | 1983-07-14 | 1986-02-04 | Sperry Corporation | Coset code generator for computer memory protection |
| DE3788577T2 (de) | 1986-01-09 | 1994-07-07 | Nippon Electric Co | Paketvermitteltes Fernmeldenetz mit parallelen virtuellen Verbindungen zur Umweglenkung von Nachrichtenpaketen. |
| JPH01205946A (ja) | 1988-03-03 | 1989-08-18 | Star Micronics Co Ltd | 数値制御自動旋盤の安全装置 |
| US5218691A (en) | 1988-07-26 | 1993-06-08 | Disk Emulation Systems, Inc. | Disk emulation system |
| US5068854A (en) | 1989-09-12 | 1991-11-26 | Cupertino, California U.S.A. | Error detection for fiber distributed interfaced optic link |
| FR2664765B1 (fr) | 1990-07-11 | 2003-05-16 | Bull Sa | Dispositif de serialisation et de deserialisation de donnees et systeme de transmission numerique de donnees en serie en resultant. |
| FI921268A (fi) | 1991-04-15 | 1992-10-16 | Hochiki Co | Detekteringssystem foer oeverfoerningsfel foer anvaendning i bevakningssystem foerebyggande av destruktioner |
| JP3501305B2 (ja) * | 1993-08-04 | 2004-03-02 | サン・マイクロシステムズ・インコーポレイテッド | 相互接続制御装置及び方法 |
| US5956370A (en) | 1996-01-17 | 1999-09-21 | Lsi Logic Corporation | Wrap-back test system and method |
| US5790563A (en) | 1996-02-05 | 1998-08-04 | Lsi Logic Corp. | Self test of core with unpredictable latency |
| JPH1174868A (ja) | 1996-09-02 | 1999-03-16 | Toshiba Corp | 情報伝送方法およびその方法が適用される情報伝送システムにおける符号化装置／復号化装置、並びに符号化・多重化装置／復号化・逆多重化装置 |
| FR2759796B1 (fr) | 1997-02-19 | 2001-12-07 | Bull Sa | Dispositif et procede de detection d'erreurs sur un circuit integre comportant un port parallele serie |
| US6202108B1 (en) | 1997-03-13 | 2001-03-13 | Bull S.A. | Process and system for initializing a serial link between two integrated circuits comprising a parallel-serial port using two clocks with different frequencies |
| US6404739B1 (en) | 1997-04-30 | 2002-06-11 | Sony Corporation | Transmitter and transmitting method, receiver and receiving method, and transceiver and transmitting/receiving method |
| US5907566A (en) | 1997-05-29 | 1999-05-25 | 3Com Corporation | Continuous byte-stream encoder/decoder using frequency increase and cyclic redundancy check |
| US6154870A (en) | 1997-06-04 | 2000-11-28 | Seagate Technology Llc | Signal error-correction system and method |
| US6085257A (en) | 1997-10-16 | 2000-07-04 | Lsi Logic Corporation | Enhanced receiving chip for a computer monitor |
| US6292906B1 (en) | 1997-12-17 | 2001-09-18 | Intel Corporation | Method and apparatus for detecting and compensating for certain snoop errors in a system with multiple agents having cache memories |
| US6167077A (en) | 1997-12-23 | 2000-12-26 | Lsi Logic Corporation | Using multiple high speed serial lines to transmit high data rates while compensating for overall skew |
| US6052812A (en) | 1998-01-07 | 2000-04-18 | Pocketscience, Inc. | Messaging communication protocol |
| GB2334641A (en) | 1998-02-11 | 1999-08-25 | Northern Telecom Ltd | Multiplexed transmission of optical signals |
| US6092233A (en) | 1998-03-20 | 2000-07-18 | Adaptec, Inc. | Pipelined Berlekamp-Massey error locator polynomial generating apparatus and method |
| US6156952A (en) * | 1998-04-09 | 2000-12-05 | Constituent Institution Of The University Of Maryland System | HIV transgenic animals and uses therefor |
| US6233073B1 (en) | 1998-07-30 | 2001-05-15 | International Business Machines Corporation | Diagnostic injection of transmission errors in fiber optic networks |
| US6311239B1 (en) | 1998-10-29 | 2001-10-30 | Cypress Semiconductor Corp. | Architecture, circuitry and method for transmitting n-bit wide data over m-bit wide media |
| FI982854A (fi) | 1998-12-31 | 2000-07-01 | Nokia Networks Oy | Datasiirto tietoliikennejärjestelmässä |
| US6690682B1 (en) | 1999-03-12 | 2004-02-10 | Lucent Technologies Inc. | Bit multiplexing of packet-based channels |
| US6771671B1 (en) | 1999-03-12 | 2004-08-03 | Lucent Technologies Inc. | Data flow synchronization and ordering |
| US6516952B1 (en) | 1999-05-13 | 2003-02-11 | 3Com Corporation | Dual mode serializer-deserializer for data networks |
| US6850559B1 (en) | 1999-06-28 | 2005-02-01 | At&T Corp. | System and methods for transmitting data |
| US6449694B1 (en) | 1999-07-27 | 2002-09-10 | Intel Corporation | Low power cache operation through the use of partial tag comparison |
| US6587432B1 (en) | 1999-08-31 | 2003-07-01 | Intel Corporation | Method and system for diagnosing network congestion using mobile agents |
| US7010607B1 (en) | 1999-09-15 | 2006-03-07 | Hewlett-Packard Development Company, L.P. | Method for training a communication link between ports to correct for errors |
| US6374398B1 (en) * | 1999-12-28 | 2002-04-16 | Vlsi Technology, Inc. | Efficient database for die-per-wafer computations |
| US6628679B1 (en) | 1999-12-29 | 2003-09-30 | Intel Corporation | SERDES (serializer/deserializer) time domain multiplexing/demultiplexing technique |
| US6738935B1 (en) | 2000-02-07 | 2004-05-18 | 3Com Corporation | Coding sublayer for multi-channel media with error correction |
| US6647428B1 (en) | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
| US6690757B1 (en) | 2000-06-20 | 2004-02-10 | Hewlett-Packard Development Company, L.P. | High-speed interconnection adapter having automated lane de-skew |
| US7010612B1 (en) | 2000-06-22 | 2006-03-07 | Ubicom, Inc. | Universal serializer/deserializer |
| US6662332B1 (en) | 2000-07-05 | 2003-12-09 | 3Com Corporation | Interleaver for burst error correction |
| US7054331B1 (en) | 2000-09-13 | 2006-05-30 | Intel Corporation | Multi-lane receiver de-skewing |
| US6894969B1 (en) | 2000-11-14 | 2005-05-17 | Lucent Technologies Inc. | Apparatus and method for redundancy of processing modules interfaced to a switching core |
| US6684351B1 (en) | 2000-12-22 | 2004-01-27 | Applied Micro Circuits Corporation | System and method for diagnosing errors in multidimensional digital frame structure communications |
| US7180867B2 (en) | 2000-12-26 | 2007-02-20 | Lucent Technologies Inc. | Apparatus and method for flow path based fault detection and service restoration in a packet based switching system |
| US6963533B2 (en) | 2000-12-29 | 2005-11-08 | Nokia Inc. | Method and system for establishing link bit rate for inverse multiplexed data streams |
| US6804800B2 (en) | 2000-12-29 | 2004-10-12 | Intel Corporation | Method and apparatus for detecting and recovering from errors in a source synchronous bus |
| US7046623B2 (en) | 2000-12-29 | 2006-05-16 | Nokia Inc. | Fault recovery system and method for inverse multiplexed digital subscriber lines |
| WO2002071713A2 (fr) | 2001-03-01 | 2002-09-12 | Broadcom Corporation | Convertisseur serie-parallele de traitement de signaux numeriques |
| US6745353B2 (en) | 2001-03-15 | 2004-06-01 | Intel Corporation | Method and apparatus for sliding window link physical error detection |
| US6834362B2 (en) | 2001-03-26 | 2004-12-21 | Sun Microsystems, Inc. | Apparatus and method for error detection on source-synchronous buses |
| US7058010B2 (en) | 2001-03-29 | 2006-06-06 | Lucent Technologies Inc. | Controlled switchover of unicast and multicast data flows in a packet based switching system |
| JP2002304310A (ja) | 2001-04-06 | 2002-10-18 | Fujitsu Ltd | 半導体集積回路 |
| US8051212B2 (en) * | 2001-04-11 | 2011-11-01 | Mellanox Technologies Ltd. | Network interface adapter with shared data send resources |
| US7016304B2 (en) * | 2001-05-18 | 2006-03-21 | Intel Corporation | Link level retry scheme |
| US7035294B2 (en) | 2001-06-04 | 2006-04-25 | Calix Networks, Inc. | Backplane bus |
| US20030002505A1 (en) | 2001-06-30 | 2003-01-02 | Hoch Thomas A. | Apparatus and method for packet-based switching |
| US6556152B2 (en) | 2001-07-20 | 2003-04-29 | Parama Networks, Inc. | Deserializer |
| KR20040018241A (ko) | 2001-07-27 | 2004-03-02 | 코닌클리케 필립스 일렉트로닉스 엔.브이. | 신호 코딩 |
| US7536473B2 (en) | 2001-08-24 | 2009-05-19 | Intel Corporation | General input/output architecture, protocol and related methods to implement flow control |
| CA2357932A1 (fr) * | 2001-09-27 | 2003-03-27 | Alcatel Canada Inc. | Methode de synchronisation de liaisons optiques paralleles entre des dispositifs de communication |
| US7065101B2 (en) | 2001-11-15 | 2006-06-20 | International Business Machines Corporation | Modification of bus protocol packet for serial data synchronization |
| US7092629B2 (en) | 2001-11-19 | 2006-08-15 | Hewlett-Packard Development Company, L.P. | Time-division and wave-division multiplexed link for use in a service area network |
| US7130317B2 (en) | 2001-11-19 | 2006-10-31 | Annadurai Andy P | Method and circuit for de-skewing data in a communication system |
| US6985502B2 (en) | 2001-11-19 | 2006-01-10 | Hewlett-Packard Development Company, L.P. | Time-division multiplexed link for use in a service area network |
| US7187863B2 (en) | 2001-12-13 | 2007-03-06 | International Business Machines Corporation | Identifying substreams in parallel/serial data link |
| US7079528B2 (en) | 2001-12-13 | 2006-07-18 | International Business Machines Corporation | Data communication method |
| US6988161B2 (en) | 2001-12-20 | 2006-01-17 | Intel Corporation | Multiple port allocation and configurations for different port operation modes on a host |
| US6671833B2 (en) * | 2002-01-08 | 2003-12-30 | Parama Networks, Inc. | Forward error correction and framing protocol |
| US7062568B1 (en) | 2002-01-31 | 2006-06-13 | Forcelo Networks, Inc. | Point-to-point protocol flow control extension |
| US7343535B2 (en) | 2002-02-06 | 2008-03-11 | Avago Technologies General Ip Dte Ltd | Embedded testing capability for integrated serializer/deserializers |
| US7073001B1 (en) | 2002-04-03 | 2006-07-04 | Applied Micro Circuits Corporation | Fault-tolerant digital communications channel having synchronized unidirectional links |
| US7191371B2 (en) | 2002-04-09 | 2007-03-13 | Internatioanl Business Machines Corporation | System and method for sequential testing of high speed serial link core |
| US7243291B1 (en) | 2002-04-30 | 2007-07-10 | Silicon Graphics, Inc. | System and method for communicating image data using error correction coding |
| US6864709B2 (en) | 2002-05-13 | 2005-03-08 | Fairchild Semiconductor Corporation | Cross point switch with serializer and deserializer functions |
| US6898752B2 (en) | 2002-05-31 | 2005-05-24 | Agilent Technologies, Inc. | Apparatus and methods for combinational error detection in an InfiniBand switch |
| US7082556B2 (en) | 2002-10-07 | 2006-07-25 | Finisar Corporation | System and method of detecting a bit processing error |
| US6653957B1 (en) | 2002-10-08 | 2003-11-25 | Agilent Technologies, Inc. | SERDES cooperates with the boundary scan test technique |
| US7373561B2 (en) | 2002-10-29 | 2008-05-13 | Broadcom Corporation | Integrated packet bit error rate tester for 10G SERDES |
| US7203853B2 (en) | 2002-11-22 | 2007-04-10 | Intel Corporation | Apparatus and method for low latency power management on a serial data link |
| US6992987B2 (en) | 2003-05-01 | 2006-01-31 | Genesis Microchip Inc. | Enumeration method for the link clock rate and the pixel/audio clock rate |
| US7251764B2 (en) | 2003-05-27 | 2007-07-31 | International Business Machines Corporation | Serializer/deserializer circuit for jitter sensitivity characterization |
| US7200790B2 (en) | 2003-07-08 | 2007-04-03 | Sun Microsystems, Inc. | Switch level reliable transmission |
| US7159137B2 (en) * | 2003-08-05 | 2007-01-02 | Newisys, Inc. | Synchronized communication between multi-processor clusters of multi-cluster computer systems |
| JP4207718B2 (ja) | 2003-08-26 | 2009-01-14 | トヨタ自動車株式会社 | 内燃機関の制御装置 |
| GB2406404C (en) | 2003-09-26 | 2011-11-02 | Advanced Risc Mach Ltd | Data processing apparatus and method for handling corrupted data values |
| US7275195B2 (en) | 2003-10-03 | 2007-09-25 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Programmable built-in self-test circuit for serializer/deserializer circuits and method |
| US20050073586A1 (en) | 2003-10-06 | 2005-04-07 | Songnian Li | Digital camera interface |
| US7447953B2 (en) | 2003-11-14 | 2008-11-04 | Intel Corporation | Lane testing with variable mapping |
| US7328375B2 (en) | 2003-12-30 | 2008-02-05 | Intel Corporation | Pass through debug port on a high speed asynchronous link |
-
2004
- 2004-01-12 US US10/756,667 patent/US7606253B2/en not_active Expired - Fee Related
-
2005
- 2005-01-10 FR FR0500209A patent/FR2865089B1/fr active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4322793A (en) * | 1979-01-02 | 1982-03-30 | International Business Machines Corp. | Communication controller transparently integrated into a host CPU |
| US4490788A (en) * | 1982-09-29 | 1984-12-25 | Schlumberger Technology Corporation | Well-logging data processing system having segmented serial processor-to-peripheral data links |
| US4677614A (en) * | 1983-02-15 | 1987-06-30 | Emc Controls, Inc. | Data communication system and method and communication controller and method therefor, having a data/clock synchronizer and method |
| JPH0369244A (ja) * | 1989-08-08 | 1991-03-25 | Nec Corp | データ受信制御回路 |
Non-Patent Citations (1)
| Title |
|---|
| PATENT ABSTRACTS OF JAPAN vol. 015, no. 233 (E - 1077) 14 June 1991 (1991-06-14) * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20050152386A1 (en) | 2005-07-14 |
| US7606253B2 (en) | 2009-10-20 |
| FR2865089B1 (fr) | 2007-09-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2865089A1 (fr) | Procede pour communiquer des donnees a l'aide de tampons de donnees de relance | |
| US7836378B2 (en) | System to detect and identify errors in control information, read data and/or write data | |
| US8327105B2 (en) | Providing frame start indication in a memory system having indeterminate read data latency | |
| US7810013B2 (en) | Memory device that reflects back error detection signals | |
| US9015557B2 (en) | Simultaneous data transfer and error control to reduce latency and improve throughput to a host | |
| TW201015291A (en) | Cyclical redundancy code for use in a high-speed serial link | |
| JP3996928B2 (ja) | 破損データを処理する方法 | |
| CN101123485B (zh) | iSCSI报文处理方法和装置、错误恢复方法和装置 | |
| CN109918226A (zh) | 一种静默错误检测方法、装置及存储介质 | |
| US7461321B2 (en) | Error detection | |
| US7721159B2 (en) | Passing debug information | |
| US7436777B2 (en) | Failed link training | |
| US7363402B2 (en) | Data communications architecture employing parallel SERDES channels | |
| KR101086599B1 (ko) | 데이터 통신의 갭을 처리하는 방법 | |
| CN116436564A (zh) | 用于发送带内跨芯片触发以保持高速互连的方法和*** | |
| US7672222B2 (en) | Link failures | |
| US20060184707A1 (en) | Error injection | |
| CN115706661A (zh) | 同步高速信令互连 | |
| US7310762B2 (en) | Detection of errors | |
| US7702054B2 (en) | Detecting errors in transmitted data | |
| US7613958B2 (en) | Error detection in a system having coupled channels | |
| US7451240B2 (en) | Method and related circuit for increasing network transmission efficiency by increasing a data updating rate of a memory | |
| US7624213B2 (en) | Passing identification information | |
| CN116775390B (zh) | 接口协议转换验证***及方法、电子设备及存储介质 | |
| FR2870958A1 (fr) | Systeme pour injecter des erreurs dans une liaison de commun ications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 12 |
|
| TP | Transmission of property |
Owner name: HEWLETT PACKARD ENTREPRISE DEVELOPMENT LP, US Effective date: 20160819 |
|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |
|
| PLFP | Fee payment |
Year of fee payment: 20 |