Brevet FR2870958A1 — publié le 20051202

La présente invention concerne des architectures de communications de données pour des processeurs d'ordinateur et, plus particulièrement, des architectures de communications pour des processeurs d'ordinateur utilisant des convertisseurs parallèle-série et des convertisseurs sérieparallèle. Des architectures informatiques qui fonctionnent de manière efficace et qui peuvent traiter des données rapidement sont généralement préférées à leurs équivalents. La vitesse à laquelle ces architectures informatiques traitent des données peut être limitée par un nombre de facteurs qui inclut la conception de l'architecture, les conditions de fonctionnement, la qualité des composants utilisés, et les protocoles, une fonction logique, et des méthodologies utilisées par l'architecture d'ordinateur lors du traitement des données. Des temps d'attente dans la communication de données sur des composants résultant d'architectures de communications de données et des protocoles d'une architecture informatique peuvent également avoir un 2870958 2 impact sur la vitesse à laquelle des données peuvent être traitées. Un certain nombre d'architectures de communications de données sont actuellement utilisées afin de communiquer des données entre des composants coopérants d'une architecture d'ordinateur (par exemple des processeurs d'ordinateur dans une unité de traitement d'un environnement informatique ou entre un processeur d'ordinateur et un composant périphérique tel qu'un dispositif de stockage de données). Par exemple, l'IDE/ATA (Integrated Drive Electronics/ Advanced Technology Attachment: environnement IDE/ technologie de transfert ATA) et le SCSI (Samll Computer Systems Interface: interface SCSI) sont toutes deux des interfaces communes au disque dur (ainsi qu'à certains autres dispositifs, tels que les lecteurs CDROM et DVD), et il existe de nombreuses autres versions de chacune. D'autres architectures de communications de données incluent le PCI (Peripheral Components Interconnect: architecture PCI), l'AGP (Accelerated Graphics Port: bus AGP), l'USB (Universal Serial Bus: bus USB), des ports séries de communications de données, et des ports parallèles de communications de données. Bien que chacune des architectures de communications de données ci-dessus soit efficace dans la transmission de données entre des composants coopérants, chacune de ces architectures présente des inconvénients, des limitations de performance et peut ne pas être fiable. Clairement, de telles architectures de communications de données ne sont pas conçues pour manipuler des quantités volumineuses de communications de données, qui sont communiquées à des fréquences d'horloge élevées (par exemple, plusieurs Giga Hertz). De plus, les architectures de communications de données PCI, IDE, et SCSI nécessitent généralement des calculs de traitement en temps système lors de la communication de données qui ont un impact sur la vitesse des communications de données globales. Autrement dit, en plus de la transmission des données souhaitées, des données de traitement en temps système supplémentaires doivent être communiquées. En tant que tel, moins de données globales sont traitées au cours de chaque cycle d'horloge. En réponse aux besoins d'architectures de communications de données à bande passante plus élevées, l'architecture de communications de données SERDES (serializer/deserializer: convertisseur parallèlesérie/convertisseur série-parallèle) a été développée. Le SERDES fonctionne pour encoder et décoder des données selon un schéma prédéfini (par exemple, un encodage huit bits/dix bits-8b10b). Les données encodées sont communiquées sur un ou plusieurs canaux de communication depuis le convertisseur parallèle-série jusqu'au convertisseur série-parallèle correspondant pour le décodage. On a montré que l'architecture de communication de données SERDES augmente la bande passante de communications de données entre les composants coopérants. Dans ce contexte, des architectures de communications de données SERDES sont déployées en tant que bus de données fonctionnant pour transporter des données entre des composants coopérants. Une architecture de communications de données utilisant des convertisseurs parallèle-série et des convertisseurs série-parallèle destinés à être utilisés dans la communication de données entre des composants de traitement d'ordinateur d'un environnement informatique afin de réduire un temps d'attente est mis à disposition. Dans un mode de réalisation illustratif, une architecture de communications de données comprend une interface de données, un convertisseur parallèle-série et un convertisseur série-parallèle. En fonctionnement, des données en provenance de 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 les communiquer vers le convertisseur série- parallèle selon un protocole d'encodage choisi. En fonctionnement, le convertisseur parallèle-série et le convertisseur série-parallèle (SERRES) coopère afin de former une liaison de communications ou un canal de communications. L'interface de données, parmi d'autres choses, permet le rassemblement de données devant être transférées sur la liaison depuis chaque extrémité de la liaison, fournit une gestion de liaison et une information de commande, encode une protection contre les erreurs et fournit une fonction logique destinée au traitement des données sur le canal des communications. En plus du mode de réalisation exemplaire, l'architecture des communications de données illustratives comprend en outre des tampons de données, un module de formation, un module de déboguage, un module d'injection d'erreur et un module de détection d'erreur. Ces moniteurs et/ou modules comprennent une partie du convertisseur parallèle-série et du convertisseur série-parallèle. En fonctionnement, ces moniteurs et/ou modules coopèrent avec l'interface de données et des ensembles d'instructions contenues dans le convertisseur parallèle-série et le convertisseur série-parallèle pour réaliser des fonctions incluant, mais non limitées à, le traitement d'information de déboguage, le traitement d'information d'identification de liaison, l'injection d'erreurs sur les liaisons de communications, et la réalisation de détection d'erreur. D'autres caractéristiques de l'invention sont décrites de manière supplémentaire ci-dessous. L'architecture des communications de données et les procédés d'utilisation sont décrits de manière supplémentaire en référence aux dessins joints dans lesquels: la figure 1 est un schéma de principe d'un 10 environnement informatique exemplaire conformément à un mode de réalisation des systèmes et procédés décrits ici; la figure 2 est un schéma de principe représentant la coopération de composants d'exemplaires d'une architecture des communications de données exemplaire; la figure 3 est un schéma de principe d'un noyau d'émission conformément à un mode de réalisation exemplaire d'une architecture des communications de données; la figure 4 est un schéma de principe d'un noyau de réception conformément à un mode de réalisation exemplaire d'une architecture des communications de données; la figure 5 est un organigramme représentant le traitement réalisé par une architecture des communications de données exemplaire lors de la communication de données; la figure 6 est un organigramme représentant le traitement réalisé par une architecture des communications de données exemplaire lors de la manipulation d'information de déboguage; la figure 7 est un organigramme représentant le traitement réalisé par une architecture des communications de données exemplaire lors de la manipulation d'information d'identification; la figure 8 est un organigramme représentant le traitement réalisé par une architecture des communications de données exemplaire lors de l'injection d'erreurs faisant partie d'un essai de liaison; et la figure 9 est un organigramme représentant le traitement réalisé par une architecture des 10 communications de données exemplaire lors de la manipulation de détection d'erreur. Afin de fournir la bande passante d'infrastructure nécessaire aux environnements informatiques, des mises en oeuvre se sont orientées vers l'utilisation d'architectures des communications de données point à point de convertisseur parallèle-série/convertisseur série-parallèle (SERDES) fonctionnant à des fréquences élevées. En appliquant l'architecture des communications de données SERDES à une infrastructure des communications de données interne de l'environnement informatique, un certain nombre de limites apparaissent. En termes généraux, un temps d'attente superflu dans des communications de données résulte d'une gestion d'architecture des communications de données inefficaces. La gestion de l'architecture des communications de données SERDES peut être réalisée par une interface de données qui, parmi d'autres choses, rassemble des données pour une communication le long des liaisons de communications SERDES et fournit une détection d'erreur et des instructions de manipulation pour des données errantes. La présente invention fournit une interface de données destinée à être utilisée par des canaux de liaison SERDES qui supportent des opérations se produisant de manière bidirectionnelle entre des composants d'architecture des communications de données. Dans un mode de réalisation illustratif, un mécanisme est mis à disposition afin de rassembler des données destinées à être transférées sur une liaison SERDES depuis chaque extrémité de la liaison. De plus, le mécanisme peut fonctionner afin de fournir des informations de gestion de liaison en recouvrement, pour encoder une détection d'erreur et pour encoder les données dans le format approprié. L'interface de données du mode de réalisation illustratif décrite ici maintient également une fonction logique qui dirige des composants SERDES afin de rassembler, générer, intégrer, et/ou communiquer des types particuliers de données (par exemple des informations de détection d'erreur, des informations d'identification de liaison, des informations d'erreur, et des informations de déboguage) entre des composants de liaison SERDES pour effectuer des essais de fiabilité et/ou une caractérisation, un déboguage, une formation de liaison, et pour vérifier que telles données sont correctement rassemblées et communiquées. L'architecture des communications de données SERDES illustrative peut également utiliser un tampon de données afin de mémoriser des données. En fonctionnement, le tampon de données peut être utilisé pour mémoriser des données jusqu'à ce qu'une bonne réception soit confirmée par une réponse en provenance de l'extrémité de réception d'une liaison des communications SERDES. Dans un tel cas, un accusé de réception peut être intégré en tant que partie de données communiquées entre des composants coopérants de l'architecture des communications de données SERDES. Lorsqu'une erreur est détectée par des composants SERDES, le tampon de données peut être utilisé pour envoyer les données pour corriger l'erreur. Par ailleurs, le mode de réalisation illustratif peut orchestrer l'utilisation de canaux de communications SERDES parallèles multiples. Un canal des communications SERDES peut comprendre une liaison des communications logiques fonctionnant sur une liaison physique (par exemple, des fils) entre des composants SERDES (par exemple des convertisseurs parallèle-série et des convertisseurs série-parallèle). Lors d'une réalisation de détection d'erreur, et d'autres opérations, l'architecture des communications de données SERDES illustrative peut utiliser un canal de rechange. De plus, un tel canal de rechange peut être utilisé afin de maintenir une disponibilité de communication même dans le cas d'une erreur permanente d'un des canaux. La figure 1 représente un système informatique 100 exemplaire conformément aux systèmes et procédés décrits ici. Le système informatique 100 est capable d'exécuter diverses applications informatiques 180. Le système informatique 100 exemplaire est commandé tout d'abord par des instructions lisibles par ordinateur, qui peuvent être de la forme d'un logiciel, où et comment un tel logiciel est mémorisé ou atteint. Un tel logiciel peut être exécuté dans une unité centrale (UC) 110 pour entraîner le système 100 de traitement de données à travailler. Dans de nombreux serveurs d'ordinateur, postes de travail et ordinateurs personnels connus, une unité centrale 110 est mise en oeuvre par des unités centrales de micropuces électroniques appelées microprocesseur Un coprocesseur 115 est un processeur optionnel, distinct de l'UC principale 110, qui réalise des fonctions supplémentaires ou assiste l'UC 110. L'UC 110 peut être connectée au coprocesseur 115 au travers de l'interconnexion 112. Un type commun de coprocesseur est un coprocesseur à virgule flottante, é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 110 courante. Il faut être conscient du fait que bien qu'un environnement informatique illustratif soit représenté pour comprendre une unité centrale 110 unique, une telle description est uniquement illustrative d'un environnement informatique 100 qui peut comprendre un certain nombre d'unités centrales 110. De plus, un environnement informatique 100 peut exploiter les ressources d'unités centrales distantes (non représentées) au travers d'un réseau 160 de communications ou de quelques qu'autres moyens de communications de données (non représentés). En fonctionnement, l'UC 110 met en place, décode, et exécute des instructions, et transfère des informations vers et depuis d'autres ressources par le biais du chemin de transfert de données principales de l'ordinateur, un bus système 105. Un tel système bus connecte les composants dans un système informatique et définit les supports pour l'échange de données. Le système bus 105 inclut habituellement des lignes de données pour l'envoi de données, des lignes d'adresses pour l'envoi d'adresses, et des lignes de commande pour l'envoi d'interruption, et pour faire fonctionner le bus système. Un exemple d'un tel bus système est le bus PCI (Peripheral component interconnect). Certains des bus évolués actuels fournissent une fonction appelée arbitrage de bus qui régule l'accès au bus par des cartes d'extension, des dispositifs de commande, et une unité centrale 110. Des dispositifs qui s'attachent à ces bus et arbitrent pour reprendre le bus sont appelés bus maîtres. Un support de bus maître permet également la création de configurations multiprocesseurs de bus par l'addition d'adaptateurs de bus maître contenant un processeur et ses puces de support. Des dispositifs de mémoire couplés au bus système 105 incluent de la mémoire vive (RAM) 125 et de la mémoire morte (ROM) 130. De telles mémoires incluent un ensemble de circuits qui permet aux informations d'être mémorisées et retrouvées. Des ROM 130 contiennent généralement des données mémorisées qui ne peuvent être modifiées. Des données mémorisées dans la RAM 125 peuvent être lues ou modifiées par l'UC 110 ou d'autres dispositifs matériels. L'accès à la RAM 125 et/ou à la ROM 130 peut être commandé par un dispositif de commande 120 de mémoire. Un dispositif de commande 120 de mémoire peut fournir une fonction de translation d'adresse qui translate des adresses virtuelles en adresses physiques lorsque des instructions sont exécutées. Un dispositif de commande 120 de mémoire peut également fournir une fonction de protection de mémoire qui isole des processus à l'intérieur du système et isole des processus de système des processus d'utilisateur. Ainsi, un programme fonctionnant en mode utilisateur peut accéder normalement uniquement à une mémoire mappée par son propre espace d'adresse virtuelle de processus; il ne peut accéder à une mémoire dans un autre espace d'adresse virtuelle du processus à moins qu'un partage de mémoire entre les processus ait été établi. De plus, le système informatique 100 peut contenir des dispositifs de commande 135 de périphériques responsables des instructions de communications depuis l'UC 110 vers des périphériques, tels que, une imprimante 140, un clavier 145, une souris 150, et une unité 155 de mémorisation de données. Un afficheur 165, qui est commandé par le 35 dispositif de commande 163 d'afficheur, est utilisé afin d'afficher une sortie visuelle générée par le système informatique 100. Une telle sortie visuelle peut inclure du texte, des graphiques, des graphiques animés, et de la vidéo. L'afficheur 165 peut être mis en oeuvre avec un afficheur vidéo de base CRT, un écran plat à base LCD, un écran plat à plasma, un écran tactile, ou d'autres formes d'afficheur. Le dispositif de commande 163 d'afficheur inclut des composants électroniques nécessaires pour générer un signal vidéo qui est envoyé vers l'afficheur 165. En outre, le système informatique 100 peut contenir un adaptateur 170 réseau qui peut être utilisé pour connecter le système informatique 100 à un réseau 160 de communication externe. Un réseau 160 de communications peut mettre à disposition des utilisateurs d'ordinateur des moyens de communication et de transfert de logiciel et d'information de manière électronique. De plus, un réseau 160 de communications peut prévoir un traitement distribué, qui implique plusieurs ordinateurs et le partage de charge de travail ou d'effort de coopération dans la réalisation d'une tâche. On sera conscient du fait que les connexions de réseau représentées sont exemplaires et d'autres moyens d'établir une liaison de communications entre les ordinateurs peuvent être utilisés. Il faut être conscient du fait que le système 100 d'ordinateur exemplaire est uniquement illustratif d'un environnement informatique dans lequel les systèmes et procédés décrits ici peuvent fonctionner et ne limitent pas la mise en oeuvre des systèmes et procédés décrits ici dans des environnements informatiques ayant des composants et configurations différentes, car les concepts inventifs décrits ici peuvent être mis en oeuvre dans différents environnements informatiques ayant divers composants et configurations. 2870958 12 Les figures 2 à 4 représentent des schémas de principe d'une architecture de communications de données illustrative pour une utilisation dans un environnement informatique exemplaire. L'architecture de communications de données illustrative peut être mise en oeuvre en tant que composants de l'environnement informatique et peut utiliser des composants SERDES. Plus précisément, la figure 2 représente un schéma de principe d'une architecture 200 de communications de données illustrative. Tel que représenté sur la figure 2, l'architecture 200 de communications de données comprend des modules 205 et 210 d'interface de communications de données coopérant pour communiquer des données 230 sur des liaisons 220 physiques. Des modules 205 et 210 de communications d'interface de données comprennent au moins un noyau d'émission et au moins un noyau de réception. Des liaisons 220 physiques s'attachent au module 205 et 210 d'interface de communications de données au travers des connecteurs 225 physiques. En fonctionnement, un environnement informatique exemplaire (non représenté) coopère avec des modules 205 et 210 d'interface de communications de données pour communiquer des données entre des modules 205 et 210 d'interface de communications de données. Dans le mode de réalisation illustratif, des modules d'interface de communications de données peuvent résider à des emplacements géographiques disparates dans un environnement informatique exemplaire (non représenté) ou peuvent résider en tant que partie de cartes de circuits imprimés (PCB). Tel que représenté, des données peuvent être communiquées dans une direction choisie ou de manière bidirectionnelle. Tel qu'indiqué par les flèches 232 et 234 sur les liaisons physiques 220 et les données 230, entre des noyaux d'émission et des noyaux de réception d'interface 205 et 210 de communications de données. De même, il faut être conscient du fait que des liaisons 220 physiques sont représentées avec une épaisseur de lignes différentes afin d'indiquer différents supports de liaison 220 physique. Par ailleurs, tel que représenté, la boite 215 en pointillés représente les composants d'un plan arrière de communications de données exemplaires. Dans le mode de réalisation fourni, le plan arrière 215 est représenté avec une paire de noyaux d'émission-réception fonctionnant pour communiquer des données. Plus précisément, des données sont traitées par le noyau d'émission 235 de l'interface 205 de communications de données pour une communication au travers du connecteur 225 physique et des liaisons 220 physiques jusqu'au noyau de réception 245 de l'interface 210 de communications de données. De la même manière, des données peuvent être traitées pour une communication par le noyau 250 d'émission de l'interface 210 de communications de données vers le noyau de réception 240 de l'interface 205 de communications de données. De plus, les paires de noyaux d'émission-réception 235, 240 et 245, 250 peuvent coopérer pour former un canal de communications. En tant que canal de communications, les paires de noyaux d'émission-réception peuvent être alignées et formées pour traiter des données selon un protocole d'encodage choisi tel qu'un encodage huit bits-dix bits (8b10b). En outre, tel que représenté sur la figure 2, des données 230 peuvent comprendre un nombre de paquets. Plus précisément, des données 230 peuvent contenir 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 des petits paquets de données. Il faut être conscient du fait que dans le mode de réalisation illustratif fournie, un petit paquet peut être considéré comme un paquet de données qui est plus petit en taille qu'un paquet de données normal de taille conventionnelle. En fonctionnement, diverses données, commandes, formations, et informations de gestion de canaux peuvent être communiquées sur l'architecture 200 de communications de données exemplaire en tant que données 230. La figure 3 représente un schéma de principe d'un environnement 300 de noyau d'émission exemplaire représentant ses composants et leur coopération. Tel que représenté sur la figure 3, l'environnement 300 de noyau d'émission exemplaire comprend une pluralité de noyaux d'émission allant d'un noyau d'émission 300-1 à un noyau d'émission 300-n. Le noyau d'émission 300-1 est représenté comme comprenant en bloc logique une pluralité de convertisseurs parallèle-série et de pilotes du convertisseur parallèle-série 1 jusqu'au convertisseur parallèle-série, et du pilote 1 au pilote m, respectivement. De plus, le noyau d'émission 300-1 coopère avec un composant de communications de données externe (non représenté) pour obtenir un signal d'horloge CLK. De même, tel que représenté, le noyau d'émission 300-1 comprend une fonction logique qui maintient des ensembles d'instructions afin d'ordonner aux composants du noyau d'émission 300-1 (par exemple le convertisseur parallèle-série 1) de réaliser des fonctions conformément à des opérations de communications de données. La fonction logique du noyau d'émission 300-1 peut également agir afin de maintenir un ou plusieurs modules et mécanismes en utilisation au cours des opérations de communications de données incluant, mais n'étant pas limité à, des tampons de données (non représentés), un module 305 de déboguage, un module 310 de formation, un module 315 d'injection d'erreurs et un module 320 de détection d'erreurs. En fonctionnement, des données sont fournies en tant qu'entrée à l'un des convertisseurs parallèle-série du noyau d'émission 300-1. Les données sont encodées selon un protocole d'encodage choisi (par exemple, un encodage 8 bits - 10 bits) et est préparé pour une communication vers un composant de communications de données coopérant par l'un des pilotes du noyau d'émission sur l'un des canaux de sortie du noyau d'émission. Le protocole d'encodage peut utiliser un signal CLK pour encoder un nombre de bits dans un (des) cycles choisis du signal CLK. Par exemple, des données A peuvent être encodées par le convertisseur parallèle-série 1 du noyau d'émission 300-1 selon un protocole d'encodage choisi et préparé pour une communication par le pilote 1 pour produire des Données Encodées au niveau de la sortie de canal A à l'instruction fournie par la fonction logique du noyau d'émission 300-1. De la même manière, des données B peuvent être encodées par le convertisseur parallèle-série 2 du noyau d'émission 300-1 selon un protocole d'encodage choisi et préparé pour une communication par le pilote 2 pour produire des Données Encodées au niveau du canal B. Une telle préparation de processus d'encodage et de communications de données est réalisée sur les convertisseurs parallèle-série restants et les pilotes du noyau d'émission 300-1 et les autres noyaux d'émission de l'environnement 300 de noyau d'émission. La figure 4 représente un schéma de principe d'un environnement 400 de noyau de réception exemplaire représentant ses composants et leur coopération. Tel que représenté sur la figure 4, un noyau de réception 400 exemplaire comprend une pluralité de noyaux de réception allant du noyau de réception 400-1 au noyau de réception 400-n. Le noyau de réception 400-1 est représenté comme comprenant en bloc logique une pluralité de convertisseurs série-parallèle et de pilotes du convertisseur série-parallèle 1 jusqu'au convertisseur série-parallèle n, et du pilote 1 au pilote même respectivement. De plus, le noyau 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. De même, tel que représenté, le noyau de réception 400-1 comprend une fonction logique qui maintient des ensembles d'instructions pour ordonner aux composants du noyau de réception 400-1 (par exemple, le convertisseur série- parallèle 1) de réaliser des fonctions conformément aux opérations de communications de données. La fonction logique du noyau de réception 400- 1 peut également agir pour maintenir un ou plusieurs modules et mécanismes en utilisation au cours d'opérations de communications de données incluant, mais n'étant pas limité à, des tampons de données (non représentés), un module 405 de déboguage, un module 410 de formation, un module 415 d'injection d'erreurs et un module 420 de détection d'erreurs. En fonctionnement, des données encodées sont fournies en tant qu'entrée à l'un des convertisseurs série-parallèle du noyau de réception 400-1. Les données sont décodées selon un protocole de décodage choisi (par exemple 10 bits - 8 bits) et sont préparées pour une communication par un des pilotes du noyau de réception vers un composant de communications de données coopérant au niveau de l'une des sorties du convertisseur sérieparallèle du noyau de réception. Le protocole de décodage peut utiliser un signal CLK pour décoder un nombre de bits dans un (des) cycle(s) du signal CLK. Par exemple, des Données Encodées A peuvent être décodées par le convertisseur série-parallèle 1 du noyau de réception 400-1 selon un protocole de décodage choisi et préparé pour une communication par le pilote 1 pour produire des données A à l'instruction fournie par lafonction logique du noyau de réception 400-1. De la même manière, des Données Encodées B peuvent être décodées par le convertisseur série-parallèle 2 du noyau de réception 400-1 selon un protocole de décodage choisi et préparé pour une communication par le pilote 2 pour produire des données B. Une telle préparation de processus de décodage et de communications de données est réalisée sur les convertisseurs série-parallèle restants et les pilotes du noyau de réception 400-1 et les autres noyaux de réception de l'environnement 400 de noyau d'émission. Les figures 3 et 4 décrivent ensemble un environnement de canaux de communications exemplaires de telle manière que les données sont encodées pour une communication par un ou plusieurs noyaux d'émission, pour un décodage et un traitement ultérieur par un ou plusieurs noyaux de réception. Bien que décrit en tant que composants séparés, il faut être conscient du fait que des noyaux d'émission et des noyaux de réception peuvent résider sur un composant de communication unique (voir l'interface 205 de communications de données de la figure 2). De plus, des noyaux d'émission et des noyaux de réception peuvent fonctionner par paire pour former un ou plusieurs canaux de communications de données bidirectionnelles. La figure 5 représente le traitement réalisé par l'architecture 200 de communications de données exemplaire lors de l'établissent d'un canal de communications. Tel que représenté, le traitement commence au niveau du bloc 500 et continue jusqu'au bloc 505 où les composants de communications sont mis en marche pour une opération. A partir de là, le traitement continue jusqu'au bloc 510 où des liaisons de communications sont établies entre les composants d'architecture de communications de données. Les liaisons de communications sont ensuite formées au niveau du bloc 515 pour initier un canal de communications. Des données de formation sont ensuite envoyées sur le canal de communications au niveau du bloc 520 afin d'effectuer des essais sur le canal de communications. Une vérification est ensuite réalisée au niveau du bloc 525 pour déterminer si l'essai de canal de communications a été réussi. S'il a été réussi, le traitement continue vers le bloc 540 où une vérification est réalisée pour déterminer s'il existe un flot de données afin de communiquer sur le canal de communications dont les essais ont été réussis. Si, au niveau du bloc 540, il est déterminé qu'il n'existe aucune données à communiquer, le traitement retourne à l'entrée du bloc 540. Cependant, s'il existe un flot de données pour communiquer sur le canal de communications formé et dont les essais ont été réussis, le traitement continue jusqu'au bloc 545 où le flot de données est encodé par des convertisseurs parallèle-série. Le flot de données encodées est ensuite communiqué sur le canal de communications jusqu'au convertisseur série- parallèle coopérant au niveau du bloc 550. Le flot de données est ensuite décodé par les convertisseurs série-parallèle au niveau du bloc 555. Une vérification est ensuite réalisée au niveau du bloc 560 pour déterminer si chaque petit paquet de données du flot de données a été communiqué avec succès. Si le petit paquet de données a été transmis avec succès, le traitement retourne au bloc 540 et continue à partir de là. Cependant, si le petit paquet de données n'a pas été communiqué avec succès, le traitement retourne au bloc 530 où le canal de communications est reformé et continue à partir de là. Cependant, si au niveau du bloc 525 il est déterminé que l'essai de canal de communications n'a pas été réussi, le traitement continue jusqu'au bloc 530 où les liaisons de communications sont reformées. A partir de là, le traitement continue jusqu'au bloc 535 où des informations de commande sont communiquées entre les composants de liaison de communications. A partir de là, le traitement retourne au bloc 520 et continue à partir de là. En fonctionnement, le mode de réalisation illustratif prévoit que la séquence de formation est dirigée par les convertisseurs série-parallèle d'une liaison de communications. Plus précisément, une formation initiale est considérée comme achevée après la reconnaissance d'une indication de l'écriture d'un registre du type de logiciel choisi sur le convertisseur série-parallèle. A un tel moment, des données sont conduites sur la liaison par les convertisseurs série-parallèle du canal de communications. Dans le contexte d'opérations de convertisseur série-parallèle, les convertisseurs série-parallèle maintiennent un ou plusieurs ensembles d'instructions qui amènent les convertisseurs série-parallèle à détecter une activité sur la liaison pour signaler aux convertisseurs série-parallèle coopérant d'entamer une initialisation. Les convertisseurs série- parallèle et les convertisseurs parallèle-série des canaux de communications maintiennent au moins un ensemble d'instructions pour amener les canaux à se mettre en marche. Après un allumage réussi, un auto-test pas canal est réalisé, dont les résultats sont rassemblés et comparés. L'ensemble d'instructions amènent ensuite les convertisseurs parallèle-série et les convertisseurs série-parallèle à communiquer un motif de données choisies qui est attendu par les convertisseurs sérieparallèle, qui permet au convertisseur série-parallèle de déterminer un groupage d'unités de bits destinées à être utilisées par les protocoles d'encodage et de décodages utilisés les convertisseurs parallèle-série et les convertisseurs série-parallèle. De plus, un second motif de données reconnaissables est communiqué aux convertisseurs série-parallèle que les convertisseurs série-parallèle attribuent comme les communications de petits paquets de données. En établissant les communications de petits paquets de données, les convertisseurs série-parallèle peuvent fonctionner afin de faire correspondre ensemble des petits paquets en groupement cohérent avec la manière selon laquelle les petits paquets ont été communiqués à l'origine. Une fois que la seconde forme de données a été communiquée avec succès et traitée, un signal de commande est envoyé depuis les convertisseurs série-parallèle jusqu'aux convertisseurs parallèle-série des liaisons de communications indiquant que al formation a été achevée. A ce niveau, des paquets de données peuvent être communiqués sur les canaux formés. De plus, le mode de réalisation illustratif prévoit que si une erreur devait se produire sur la liaison de communications, la liaison peut réaliser un processus de reformation. Une reformation de liaison est similaire à la formation de liaison décrite ci-dessus en dehors de l'allumage des composants de canaux de communication. Une reformation peut être déclenchée par un certain nombre d'événements, incluant mais n'étant pas limité à, la reconnaissance d'une erreur sur la liaison de communications ou par une 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. Une architecture 200 de communications de données exemplaire de la figure 2 est également capable de passer des données de déboguage pour un traitement et une analyse. Dans le contexte d'une architecture de communications de données SERDES, une visibilité accrue dans la conception interne de l'architecture de communications de données exemplaire peut se traduire par un déboguage plus efficace et une validation de la conception de l'architecture de communications de données SERDES et une mise en oeuvre. Dans l'architecture de communications de données SERDES, au cours d'une opération de déboguage, des données de déboguage sont routées sur les divers composants de l'architecture pour un traitement et une analyse. Une activation et un transfert approprié des informations de déboguage se produisent lorsque les données de déboguage sont propagées avec succès sur l'architecture. Dans le mode de réalisation fourni, les données de déboguage peuvent provenir d'un composant matériel de données de déboguage interne comprenant une partie soit du noyau d'émission (300 de la figure 3) soit du noyau de réception (400 de la figure 4). Les données de déboguage sont traitées selon un ou plusieurs ensembles d'instructions pour propager les données de déboguage parmi les composants coopérants de l'architecture de communications exemplaire. Dans le mode de réalisation fourni, l'architecture exemplaire peut recevoir des données de déboguage ayant un premier nombre choisi de bits et accouplés de telles données de déboguage pour créer des données de déboguage modifiées (par exemple un paquet de données de déboguage) ayant un second nombre choisi de bits. Les données de déboguage accouplées peuvent ensuite être mises en tampon afin d'être mises en correspondance avec une fréquence de liaison de communication et ensuite communiquer sur la liaison de communication. A l'extrémité de réception, les données de déboguage accouplées peuvent être capturées et décomposées en un paquet de données ayant le premier nombre choisi de bits. La capacité pour l'extrémité de réception d'une liaison de communication exemplaire de l'architecture de communications exemplaire de rassembler des transactions de non déboguage régulières de la liaison est de fournir tout ou partie des transactions de non déboguage à la fonction logique de déboguage interne pour une communication ultérieure (par exemple, une transaction de données répétée sur une liaison différente en aval exemplaire de l'architecture de communication exemplaire) peut être inclus dans les opérations de déboguage. En agissant ainsi, la fonction logique de déboguage contribue à un traitement et une communication plus efficace des données sur l'architecture de communications de données. De plus, le mode de réalisation illustratif prévoit que l'extrémité de transmission de la liaison de communication peut soit alterner des cycles par paire du composant matériel de données de déboguage interne en tant que paquet de données de déboguage, ou soit qu'elle peut utiliser une indication valide envoyée avec les données de déboguage pour faire correspondre des données de déboguage envoyées depuis un composant d'architecture de communications de données coopérant (par exemple, un port de liaison). En outre, le mode de réalisation illustratif prévoit que l'architecture de communications de données exemplaire peut entrer des opérations de déboguage au travers de l'initiation d'une reformation de liaison. Après réalisation de la séquence de formation de liaison, des opérations de déboguage continuent. La figure 6 représente le traitement réalisé par une architecture 200 de communications de données exemplaire lors de la manipulation de données de déboguage. Tel que représenté, un traitement commence au niveau du bloc 600 et continue jusqu'au bloc 610 où les données de déboguage, ayant un nombre choisi de bits d'origine (par exemple 76 bits), sont accouplées pour générer un paquet de données de déboguage ayant un second nombre de bits choisies (par exemple 152 bits). A partir de là, le paquet de données de déboguage est mis en tampon afin d'être mis en correspondance avec la fréquence de liaison de communications au niveau du bloc 615. Le paquet de données de déboguage est ensuite communiqué sur la liaison de communication au niveau du bloc 620. A partir de là, le paquet de données de déboguage est capturé et envoyé au niveau de l'extrémité de réception de la liaison de communications au niveau du bloc 625. Une vérification est ensuite réalisée au niveau du bloc 640 pour déterminer si il existe des dysfonctionnements de liaison. Si la vérification au niveau du bloc 640 indique un dysfonctionnement de liaison, le traitement continue jusqu'au bloc 645 où le dysfonctionnement est signalé pour une action adéquate. Le traitement continue ensuite jusqu'au bloc 660 où la liaison de communication est reformée. A partir de là, le traitement retourne au bloc 610 et continue à partir de là. Cependant, si au niveau du bloc 640 il est déterminé qu'il n'existe aucun dysfonctionnement de liaison, le traitement continue jusqu'au bloc 635 où le paquet de données de déboguage est décomposé pour prendre une forme dans laquelle les données de déboguage ont leur nombre d'origine de bits choisis. A partir de là, le traitement continue jusqu'au bloc 650 pour poursuivre les transactions de données. Le traitement se termine ensuite au niveau du bloc 655. Une architecture 200 de communications de données exemplaire est également capable de passer des informations d'identification de liaison. Le mode de réalisation illustratif fonctionne pour permettre la confirmation, la validation, et le mappage des liaisons de communications physiques de l'architecture 200 de communications de données exemplaire au travers de l'utilisation d'informations d'identification de liaison. Dans le contexte d'une architecture de communications de données SERDES, de nombreuses liaisons sont utilisées ensemble pour chaque connexion point à point dans l'architecture de communications de données exemplaire. Dans le mode de réalisation illustratif, les noeuds de communication d'une architecture de communications de données SERDES peuvent être connectés dans des composants matériels à barres croisées qui facilitent la communication des données sur une architecture de communications de données SERDES. Ces connexions physiques amènent et dictent le fonctionnement de l'architecture de communications de données exemplaire. Afin d'assurer que ces connexions soient correctes, et/ou pour construire un mappage des connexions, une connaissance de ces connexions est nécessaire. Le mode de réalisation illustratif prévoit que les liaisons de communications de l'architecture de communications de données exemplaire peuvent être formées avant l'utilisation. Au cours de la formation, parmi d'autres choses, l'architecture de communications de données exemplaire, identifie le placement des horloges des divers composants coopérant de l'architecture de communications de données. En utilisant les informations de position d'horloge, les paquets de données peuvent être alignés depuis l'extrémité de transmission jusqu'à l'extrémité de réception de la liaison de communications, assurant des communications de données cohésives. Le mode de réalisation illustratif prévoit en outre que, en fonctionne, un identificateur d'emplacement est généré et communiqué depuis l'extrémité de transmission d'une liaison de communications exemplaire jusqu'à l'extrémité de réception de la liaison de communications fournissant des informations d'emplacement (par exemple, mappage et connexion) à propos de l'extrémité de transmission de la liaison de communications. Dans le mode de réalisation illustratif, l'identificateur d'emplacement peut être intégré à la séquence de formation au niveau d'un certain intervalle choisi ou étape de formation mais avant la libération de la liaison pour un fonctionnement normal. L'identificateur d'emplacement intégré est capturé par l'extrémité de réception selon la fonction logique de l'extrémité de réception (par exemple ensembles d'instructions et ordres), au cours de la séquence de formation, en plaçant le signal d'identification d'emplacement dans un composant de mémorisation pour un traitement ultérieur. Dans ce contexte, l'architecture de communications de données exemplaire peut utiliser un ou plusieurs ensembles d'instructions pour traiter l'information d'identification d'emplacement (par exemple au travers de l'utilisation d'un logiciel interne ou externe) pour générer une topologie des connexions d'architecture de communications de données et des relations de connexion. Plus précisément, la forme de données (par exemple, identificateur d'emplacement) devant être passée au travers de l'extrémité de transmission de la liaison de communications peut être câblée par une fonction logique matérielle et/ou être programmable par le biais d'un ensemble d'instructions (par exemple logiciel) ou peut être fournie par des sources externes telles que des composants matériels coopérants. Le mode de réalisation illustratif prévoit que le champ de données d'identificateur d'emplacement peut être du genre programmable chargé dans l'extrémité de réception par permutation de la forme de données (par exemple, identificateur d'emplacement) depuis un port de communications d'entrée externe qui peut être entraîné par un réseau de porte programmable sur place (FPGA) (non représenté). En étant du type programmable, la forme de données peut inclure des informations supplémentaires sur la connexion physique au-delà uniquement de l'emplacement, incluant, mais n'étant pas limité à, le type de matériel (par exemple, le type de puce, la fréquence de liaison et l'état de liaison). Dans le contexte d'information d'état, de telles informations peuvent inclure, mais ne pas être limitées à, une progression de réinitialisation, un état de port, les informations de configuration ou une statut d'erreur. La figure 7 représente le traitement réalisé par une architecture 200 de communications de données exemplaire lors du passage d'information d'identification de liaison. Tel que représenté, le traitement commence au niveau du bloc 700 et continue jusqu'au bloc 705 où une architecture de communications de données engage une formation de la liaison de communication. A partir de là, le traitement continue jusqu'au bloc 710 où un identificateur d'emplacement est obtenu, qui identifie la position relative de l'extrémité de transmission jusqu'à l'extrémité de réception d'une liaison de communications exemplaire. Au niveau du bloc 715, l'identificateur d'emplacement est intégré en tant que partie de la séquence de formation de la liaison de communications. Le traitement continue ensuite jusqu'au bloc 720 où l'identificateur d'emplacement est capturé et traité par l'extrémité de réception de la liaison de communications. La valeur d'identificateur d'emplacement est comparée à une valeur attendue au niveau du bloc 725 par l'extrémité de réception et de la liaison de communication. Une vérification est ensuite réalisée au niveau du bloc 830 afin de déterminer s'il n'y a pas eu d'erreur de la transmission de l'identificateur d'emplacement. S'il n'y a pas eu d'erreur déterminée au niveau du bloc 830, le traitement continue jusqu'au bloc 735 où une formation est achevée et des transactions de données réalisées au niveau du bloc 745. Cependant, si au niveau du bloc 730, il est déterminé qu'il y a eu des erreurs, le traitement continue jusqu'au bloc 750 où l'erreur est signalée. Les erreurs sont ensuite résolues au niveau du bloc 755. A partir de là, le traitement continue 705 et continue à partir de là. Une architecture 200 de communications de données exemplaire de la figure 2 est également capable d'injecter des erreurs choisies en tant que partie d'un essai de liaison de communications. Dans le contexte d'une architecture de communications de données SERDES, le mode de réalisation illustratif valide une fonctionnalité de cas d'erreur dans un système en cours d'évaluation (par exemple, essai d'une liaison de communication). Des architectures de communications de données SERDES prévoient plusieurs vérifications différentes d'exactitudes des données reçues au niveau de l'extrémité de réception d'une liaison de communication. Différentes actions sont attendues sur la base de la nature de l'erreur, et différentes informations peuvent être attendues au niveau de l'extrémité de réception de la liaison de communications. Le mode de réalisation illustratif définit divers événements d'erreurs injectées déclenchés par un signal provenant de la fonction logique de déboguage (par exemple, 315 sur la figure 3), trouvé sur l'extrémité de transmission de la liaison de communications. Par exemple, de tels événements d'erreurs peuvent inclure, mais ne sont pas limités à, de simples erreurs de bits uniques, sautées ou ajoutées à un petit paquet de données, et fermer un canal de liaison de communications. De plus, le mode de réalisation illustratif prévoit que plus d'une erreur soit injectée en tant que partie d'une séquence d'essai. Dans ce contexte, une erreur ultérieure peut être injectée de sorte qu'elle se produise de manière simultanée avec la première erreur, ou lorsqu'un second déclenchement se produit. Avec une telle capacité, des événements à erreurs multiples peuvent être mis à l'essai. De plus, le mode de réalisation illustratif peut permettre la spécification de la durée de chaque type d'erreur. Ceci peut aller d'un à plusieurs cycles, ou être permanent (par exemple, jusqu'à ce que la condition soit effacée de la liaison de communications). En tant que tel, mode de réalisation illustratif est capable de manipuler à la fois les défauts sporadiques et ceux de type de collage. De plus, le mode de réalisation illustratif peut capturer les petits paquets de données corrompues dans une mémoire tampon (par exemple, 300 sur la figure 3) sur l'extrémité de transmission de la liaison de communications lorsqu'une erreur de d'écoulement se produit. En agissant ainsi, une référence peut être créée pour comparaison aux journaux d'erreurs capturées au niveau de l'extrémité de réception de la liaison pour confirmer un comportement de liaison de communications attendu. La figure 8 représente le traitement réalisé par une architecture 200 de communications de données exemplaire de la figure 2 lors de l'injection d'erreurs en tant que partie d'un essai de liaison de communications. Tel que représenté, le traitement commence au niveau du bloc 800 et continue jusqu'au bloc 805 où une liaison de communication est établie. A partir de là, le traitement continue jusqu'au bloc 810 où une ou plusieurs erreurs (par exemple, un arrêt, un intervalle de temps, un petit paquet de données incorrectes, etc.) sont générées pour une injection dans des données devant être communiquées depuis l'extrémité de transmission jusqu'à l'extrémité de réception de la liaison de communications. Le traitement continue ensuite vers le bloc 815 où les erreurs générées sont injectées dans les données. Les données modifiées sont ensuite communiquées sur la liaison de communications au niveau du bloc 820. Le (les) erreur(s) sont ensuite capturées sur l'extrémité de réception de la liaison de communications au niveau du bloc 8925. Les erreurs capturées sont ensuite analysées pour comparaison avec les erreurs injectées à l'origine au niveau du bloc 830. Sur la base des comparaisons, l'opération de liaison de communications est vérifiée au niveau du bloc 835. Une vérification est ensuite réalisée au niveau du bloc 840 afin de déterminer si la liaison se comporte comme attendue. Si la vérification au niveau du bloc 840 indique que la liaison de communications se comporte comme attendu, le traitement se termine au niveau du bloc 850. Cependant, si au niveau du bloc 840, il est déterminé que la liaison se comporte de manière incorrecte, le traitement continue jusqu'au bloc 845 où les dysfonctionnements de liaison de communications sont analysées. A partir de là, le traitement se termine au niveau du bloc 850. Une architecture 200 de communications de données exemplaire de la figure 2 est également capable de détecter de manière efficace des erreurs dans des transactions de communications de données sans introduire de temps d'attente dans la liaison de communications. Dans le contexte d'une architecture de communications de données SERDES, le mode de réalisation illustratif est capable de relancer des transferts de données qui ne parviennent pas à passer avec exactitude sur la liaison de communications SERDES. Dans des architectures de communications de données SERDES, des paquets de données peuvent être suivis et surveillés pour déterminer une transmission réussie. Dans ce contexte, l'étiquette d'un petit paquet de données choisies qui croise la liaison est surveillée pour déterminer une transmission réussie depuis l'extrémité de transmission de la liaison de communications jusqu'à l'extrémité de réception de la liaison de communications. Après transmission réussie, un message d'accusé de réception peut être envoyé depuis l'extrémité de réception de la liaison de communications jusqu'à l'extrémité de transmission de la liaison de communication pour indiquer une transmission réussie. Tel que décrit précédemment, des transactions peuvent être envoyées sur la liaison de communications en tant qu'une séquence de petits paquets de données: un petit paquet de données à en- tête avec un routage et une transaction et des informations de type de transactions suivies par autant de séquences supplémentaires de petits paquets de données que nécessaire pour achever le transfert de données. Dans le mode de réalisation illustratif, l'entête peut inclure l'étiquette actuelle de petits paquets de données. En fonctionnement, l'extrémité de réception de la liaison vérifie l'étiquette incluse dans les paquets d'en-tête et signale une erreur de liaison si l'étiquette attendue n'est pas trouvée. En tant que tel, une erreur causée par un petit paquet rompu ou répété sera découverte lorsque le prochain petit paquet de données attendu devant être un en-tête ne possède pas l'étiquette correcte. Cependant, des manques d'efficacité peuvent résulter en ce qu'une erreur peut ne pas décrite jusqu'à ce que la transaction complète soit achevée. Le mode de réalisation illustratif fournit la capacité d'inclure des bits de l'étiquette impliquée dans le (les) champs de parité utilisés pour protéger les petits paquets de données d'erreurs de bit. En fonctionnement, les bits de l'étiquette sont inclus dans un bit différent parmi les bits de parité calculés pour détecter des erreurs de bit. En tant que tel, des petits paquets de données perdus ou répétés entraîneront une erreur de calcule de parité sur l'extrémité de réception de la liaison de communications. Le mode de réalisation illustratif, après détection d'une erreur de parité, peut demander la retransmission du petit paquet de données et peut également empêcher des données corrompues d'être acheminées depuis l'extrémité de réception de la liaison de communications. La figure 9 représente le traitement réalisé par une architecture 200 de communications de données exemplaire de la figure 2 lors de la détection d'erreurs dans des transactions de communications de données. Tel que représenté, le traitement commence au niveau du bloc 900 et continue jusqu'au bloc 905 où une liaison de communications est établie. A partir de là, le traitement continue jusqu'au bloc 910 où les bits d'étiquette de l'étiquette de données impliquées sont générés. Les bits d'étiquette générés sont ensuite encodés (par exemple, le calcul de huit bits de parité sur les canaux de transport de données où chaque bit de parité est basé sur le 1, 2, 3, sèmes bits des 8 bits de données envoyés sur une liaison de communications) dans le calcul de bit de parité sur l'extrémité de transmission de la liaison de communications au niveau du bloc 915. A partir de là, le traitement continue jusqu'au bloc 920 où les données ayant les bits d'étiquette encodés en tant que partie des bits de parité sont communiquées sur la liaison de communications. Les données sont reçues au niveau de l'extrémité de réception de la liaison de communications et la parité des données est calculée par l'extrémité de réception au niveau du bloc 925. Une vérification est ensuite réalisée auniveau du bloc 930 afin de déterminer si il existe des erreurs quelconques dans le calcul de parité transmis et le calcul de parité reçu. Si, au niveau du bloc 930, il est déterminé qu'il n'existe aucune erreur, le traitement continue jusqu'au bloc 940 où les données de transactions de communications continuent. Le traitement se termine ensuite au niveau du bloc 945. Cependant, si au niveau du bloc 930, il est déterminé qu'il existe des erreurs, le traitement continue jusqu'au bloc 940 où une demande de retransmission des données est envoyée par l'extrémité de réception de la liaison de communications jusqu'à l'extrémité de transmission de la liaison de communications. Le traitement retourne ensuite jusqu'au bloc 910 continue à partir de là. En somme, l'appareil et les procédés décrits ici fournissent une architecture de communication de données utilisant, pour une utilisation en tant qu'environnements informatique, une structure de communication qui réduit le temps d'attente. On comprendra, cependant, que l'invention est susceptible d'être modifiée de diverses manières et construite de manière alternative. Il n'existe aucune intention de limiter l'invention aux constructions spécifiques décrites ici. Au contraire, l'invention est destinée à couvrir toutes les modifications, constructions alternatives, et équivalences entrant dans la portée et l'esprit de l'invention. Il est également à noter que la présente invention peut être mise en oeuvre dans divers environnements d'ordinateur (incluant à la fois les environnements d'ordinateur sans fil et câblé), des environnements informatiques partiels, et des environnements du monde réel. Les diverses techniques décrites ici peuvent être mises en oeuvre dans un matériel ou un logiciel, ou dans une combinaison des deux. De préférence, les techniques sont mises en oeuvre dans des environnements informatiques maintenant des ordinateurs programmables qui incluent un processeur, un support de mémorisation lisible par le processeur (incluant une mémoire volatile et non volatile et/ou des organes de mémorisation), au moins un dispositif d'entrée, et au moins un dispositif de sortie. Une fonction logique de matériel informatique coopérant avec divers ensembles d'instructions est appliquée à des données afin de 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 le matériel informatique exemplaire peuvent être de préférence intégrés dans divers langages de programmation, incluant un langage de programmation par objet ou de procédure à niveau élevé pour communiquer avec un système d'ordinateur. A des fins d'illustration, l'appareil et les procédés décrits ici peuvent être intégrés dans un langage d'assemblage ou machine, si on le souhaite. Dans tous les cas, le langage peut être un langage de compilation ou d'interprétation. Chaque tel programme d'ordinateur est de préférence mémorisé sur un support de mémorisation ou dispositif (par exemple, de la ROM ou un disque magnétique) qui est visible par un ordinateur programmable universel ou spécialisé pour configurer et faire fonctionner l'ordinateur lorsque le support de mémorisation ou dispositif est lu par l'ordinateur pour réaliser les procédures décrites ci-dessus. On peut également envisager d'intégrer l'appareil en tant que support de mémorisation lisible par un ordinateur, configuré avec un programme d'ordinateur, ou le support de mémorisation ainsi configuré entraîne un ordinateur à fonctionner d'une manière prédéfinie et spécifique. Bien qu'un mode de réalisation exemplaire de l'invention ait été décrit en détail ci-dessus, l'homme du métier comprendra aisément que de nombreuses modifications supplémentaires sont possibles dans les modes de réalisation exemplaires sans s'écarter matériellement des enseignements innovants et des avantages de l'invention. Par conséquent, ces dernières et de telles modifications sont destinées à être incluses dans la portée de l'invention. L'invention peut être mieux définie par les revendications exemplaires suivantes. REVENDICATIONS 1. Système pour injecter des erreurs dans une liaison de communications d'une architecture (200) de 5 communications de données comprenant: un module d'injection d'erreurs (315, 415) fonctionnant pour générer une ou plusieurs erreurs en vue d'une injection dans des données destinées aux communications à travers la liaison de communications (215) ; et un ensemble d'instructions fournissant des directives au module d'injection d'erreurs (315, 415) afin de générer lesdites une ou plusieurs erreurs. 2. Système selon la revendication 1, dans lequel le module d'injection d'erreurs (315, 415) comprend une portion de la liaison de communications comprenant l'un quelconque parmi un convertisseur parallèle-série (300) et un convertisseur série-parallèle (400). 3. Système selon la revendication 2, comprenant en outre un ensemble d'instructions pour diriger le module d'injection d'erreurs (315, 415) afin qu'il injecte des erreurs dans les données en train d'être communiquées à travers la liaison de communications (215). 4. Système selon la revendication 3, dans lequel le module d'injection d'erreurs (315, 415) fonctionne sur l'extrémité de transmission (235, 250) de la liaison de communications (215). 5. Système selon la revendication 4, comprenant en outre un module de détection d'erreur (315, 415) 35 fonctionnant sur l'extrémité de réception (240, 245) de la liaison de communications (215) afin de capter les données ayant des erreurs injectées. 6. Système selon la revendication 5, dans lequel le module de détection d'erreur (315, 415) vérifie les opérations de liaison de communications, en se basant sur une comparaison des erreurs injectées et transmises par. le module d'injection d'erreurs (315, 415) sur l'extrémité de transmission (235, 250) de la liaison de communications (215), les erreurs étant captées sur l'extrémité de réception (240, 245) de la liaison de communications. 7. Système selon la revendication 6, dans lequel le module de détection d'erreur (315, 415) fonctionne pour vérifier et déterminer si la liaison de communications (215) s'est comportée de la façon prévue. 8. Système selon la revendication 7, comprenant en outre un ensemble d'instructions pour diriger le module de détection d'erreur (315, 415) afin qu'il analyse les erreurs. injectées ayant été communiquées à travers la liaison de communications (215). 9. Système selon la revendication 8, dans lequel le module. d'injection d'.erreurs (315, 415) génère des erreurs en vue de L'injection, en se basant sur un 30 ordre choisi. 10. Système selon la revendication 1, dans lequel le module d'injection d'erreurs (315, 415) injecte les erreurs sous la forme de petits paquets de données.