FR 2728704 A1 19960628 FR 9415590 A 19941223 I L'invention conceme un procédé et un dispositif de codage de données numériques échangées entre un processeur et des périphériques quelconques, notamment un procédé de codage de mots de 32 bits circulant entre un port de communication d'un processeur destiné initialement à la connexion de plusieurs processeurs du même type entre eux, et un périphérique. Par la suite, le terme "lien" définira la connexion d'un port du processeur avec un périphérique et le terme "échange", le transfert d'un mot sur ce lien. Dans les structures à microprocesseurs, les communications sont bidirectionnelles. Le format des échanges sur le lien a été conçu pour optimiser les échanges d'informations sur ce type de liaisons. L'invention est plus particulièrement mise en oeuvre autour d'une structure connue d'un processeur de traitement de signal de type 320C4x commercialisé par Texas Instruments. Ce processeur 32 bits possède six liens de communication asynchrone. Ces liens sont a priori destinés à faciliter les architectures multiprocesseurs à base de 320C4x ceux-ci pouvant communiquer leurs données entre eux par l'intermédiaire de ces liens. Les échanges sur ces liens se font avec des mots de 32 bits, par série de quatre octets consécutifs (le poids faible d'abord, le poids fort en dernier) par l'intermédiaire de l'échange de deux signaux: "présence donnée" (CStrB: strobe) et "acquittement" (CRdyB: ready). Le retournement du lien (émetteur devenant récepteur, soit prise du jeton, et vice-versa) est réalisé par l'échange de deux signaux: "requête d'émission" (CReqB: request) et "acquittement de la requête" (CackB: acknowledge), et relâchement du jeton. Le principe de ce lien est décrit plus précisément dans la documentation du processeur 320C4x. On dit que le périphérique possède le jeton lorsque celui-ci possède la maîtrise et le droit d'émission sur le lien considéré. Le type de bus généralement utilisé pour l'échange de 3o données/adresses entre un processeur et un périphérique ne permet pas d'optimiser au maximum les échanges sur le bus, notamment dans une application ou plusieurs types de périphériques, de structure pouvant être complètement différente avec des vitesses et des synchronisations des échanges totalement différents, lui sont connectés. Enfin, aucune procédure de contrôle automatique sur les données échangées entre le processeur et un périphérique n'est effectuée directement par le bus. L'invention a pour but de pallier les inconvénients précités. L'invention permet d'accéder à des composants périphériques non spécifiques (lents ou rapides indifféremment), par exemple: une liaison série, des registres, des mémoires de tous types... en se servant de ces liens de communications en exploitant leurs propriétés de vitesse et d'asynchronisme. to A cet effet, I'invention a pour objet un procédé de codage de données numériques échangées entre un processeur et au moins un périphérique quelconque, caractérisé en ce qu'il consiste, en utilisant les liens de communication asynchrones du processeur, liens destinés à l'interconnexion de plusieurs processeurs du même type entre eux, pour échanger des données numériques entre le processeur et le périphérique: à identifier le ou les correspondants, - à optimiser la vitesse de transmission des données transitant sur le lien, - à différencier l'interprétation des données et de leur application sur le périphérique, et - à tester les échanges de données sur le lien. L'invention a également pour objet un dispositif de codage de données numériques échangées sous forme de mots de donnée et de commande à un format déterminé entre un processeur et au moins un périphérique quelconque, caractérisé en ce qu'il comporte un Module connecté entre le port de communication asynchrone du processeur, destiné à la connexion de plusieurs processeurs du même type entre eux, et le périphérique, et en ce que le Module comporte: - un premier bloc (A) couplé au port de communication du processeur, assurant la réception et l'émission des mots échangés entre le processeur et le périphérique en gérant les échanges de jetons et les échanges sur les données (CStrB, CRdyB), et - un deuxième bloc (B) couplé au périphérique, interprétant le mot de commande pour gérer les accès au périphérique d'une part et les accès au premier bloc (A) d'autre part. Le procédé de codage selon l'invention permet d'utiliser de façon optimale les ressources matérielles disponibles sur les liens de communications du type de ceux du 320C4x afin d'accéder à tous les types de périphériques possibles. L'utilisation optimale est déterminée aussi bien du point de vue matériel (logique minimale, standardisation du développement, modularité, coût série du matériel) que du point de vue logiciel (modularité, rapidité des accès, compactage des données, paramétrage peu important, standardisation des modules logiciels d'adressage des périphériques). L'invention sera mieux comprise et d'autres avantages et caractéristiques apparaîtront plus clairement à la lecture de la description qui suit exposée en référence aux figures annexées qui représentent respectivement: - la figure 1, un type de liaison point à point sur un lien selon I'invention, -la figure 2, un type de liaison multi-points sur un lien selon l'invention, -les figures 3 à 10, différents chronogrammes respectifs à un échange de données sur un lien selon l'invention, - la figure 11, un synoptique d'un Module de codage selon l'invention, -la figure 12, une architecture du bloc IntProc du Module selon l'invention, -la figure 13, une architecture du bloc IntPer du Module selon I'invention, -la figure 14, un schéma fonctionnel d'une machine d'état assurant le séquencement des échanges sur le lien selon l'invention, et -les figures 15 à 19, des formats utilisés pour ces différents échanges. La mise en oeuvre du procédé selon l'invention est basée sur une architecture multiprocesseur. Cette architecture est implantée à base de processeurs du type 320C4x, interconnectés avec leurs liens de communications. Le flot d'informations entre ces processeurs transite donc sur les liens de communications. En plus de ces processeurs, un certain nombre de cartes de traitement spécialisées sont implantées dans ce matériel. Ces cartes de traitement sont réalisées à base d'ASICs, abréviation anglo-saxonne pour "Application Specific Integrated Circuit", et d'opérateurs spécialisés du commerce. Des cartes de traitement de signaux vidéo, par exemple, extraient des signaux un certain nombre d'informations à destination d'un des processeurs 320C4x. Or les ASICs et les opérateurs cités ci- dessus sont interfaçables sur des bus microprocesseurs (adresses, données). Le procédé selon l'invention n'utilise que les liens de communications type 320C4x pour faire transiter les informations dans ce matériel. Il convertit sur les cartes de traitement, le lien de communication en un bus adresses/données compatible des opérateurs employés pour permettre d'unifier la gestion des flux de données et les drivers de communications développés en logiciel sur les processeurs du type 320C4x. Le procédé consiste à formater les données à transmettre sur un lien de communication, au mieux, transformant le lien en bus adresses/données pour tous les opérateurs utilisés et consiste à optimiser au maximum les échanges sur ce lien. L'objectif est donc d'émuler un bus adresses/données performant sur un lien série, lien utilisé pour un processeur du type 320C4x, par l'intermédiaire d'un dispositif dédié dénommé ci-après "module de codage" ou plus simplement "Module". Une première contrainte concernant le codage des données est de permettre l'implantation de plusieurs architectures matérielles autour de processeurs du type 320C4x. Le procédé proposé est donc applicable à une liaison point à point (le lien relie un processeur à un Module unique), mais permet également une liaison multi-points de type "broadcast" (un processeur vers un ou plusieurs Modules). Ce besoin implique que l'échange de données comporte l'identification du ou des correspondants. Ces deux types de liaison, point à point et multi-points sont illustrés respectivement par les figures 1 et 2. Une deuxième contrainte consiste en la recherche de l'optimisation de la vitesse des échanges de données, en particulier pour des transferts de blocs de données. Par blocs de données, on entend une série de données mémorisées dans une structure de type mémoire avec des adresses de mémorisation séquentielles (Donnée D à l'adresse A, Donnée suivante à l'adresse (A+1)). Cette recherche d'optimisation ne doit pas, par contre, pénaliser les accès aléatoires à certains périphériques à des adresses déterminées. Une troisième contrainte est liée à la nécessité d'obtenir une architecture modulaire pour implanter le Module, les structures des périphériques pouvant être complètement différentes de l'un à l'autre. Ce besoin entraîne forcément la différenciation de l'interprétation des données et de leur application sur les périphériques. Le séquencement de I l'interprétation des messages doit également, pour cette raison, être "universel". La fonction d'interprétation des données devient alors totalement modulaire et peut être réutilisée dans de multiples applications. La dernière contrainte est de disposer de fonctionnalités de test sur les données. En effet, le test "automatisé" des échanges de données est particulièrement intéressant, déchargeant le processeur de toute tâche inutile. Le codage des données doit donc répondre à ces différentes contraintes. La dynamique des données échangées sur le lien vers le périphérique est par exemple normalisée à 16 bits. Néanmoins, le procédé reste applicable pour des dynamiques de données différentes, à la condition qu'un mot de 32 bits puisse contenir l'ensemble d'une "Commande" telle que définie ci-dessous. Pour optimiser la vitesse de transmission de données sur le lien de communication, le meilleur moyen consiste en la concaténation des données dans les mots échangés sans répétition d'informations superflues. Deux types de mots échangés sur le lien sont définis ci-après: un premier type dénommé "Commande" et un deuxième type dénommé "Donnée". Dans le type Commande, le mot contient des informations sur le type d'échange en cours (Lecture/Ecriture, mode Séquentiel ou Monocoup, fonction de Rebouclage ou non), ainsi que des adresses d'accès. Dans le type Donnée, le mot ne contient que des données exclusivement. Ce type de mot ne peut être échangé que lors d'une phase È5 de transfert séquentiel. Il est à noter qu'un transfert ne peut être initialisé que par l'échange d'un mot de type Commande. Deux modes d'échanges sont utilisés par le procédé selon l'invention: un premier mode dénommé "Monocoup" et un deuxième mode dénommé "Séquentiel". Dans le mode Monocoup, I'échange sur le lien ne concerne qu'un seul mot de 32 bits. Après l'envoi de ce mot, I'émetteur libère le lien ou rend le jeton et le processus de communication retourne à son état initial. Dans le mode Séquentiel, I'échange d'informations sur le lien s'effectue sous la forme d'une trame de longueur paramétrable de mots de 32 bits. Après l'envoi de cette trame, I'émetteur libère le lien ou rend le jeton et le processus de communication retourne à son état initial. Le Module interfacé sur le lien de communication est un Module esclave du processeur connecté sur le lien. Les échanges étant bidirectionnels, deux sens d'échanges sont définis: un sens "Ecriture" et un sens "Lecture". Le sens Ecriture est défini comme l'émission de données du processeur 320C4x vers le Module, ou, autrement dit, les échanges de données ont lieu alors que le processeur a le jeton du lien. Ecriture du processeur dans le Module d'interface. Le sens Lecture est défini comme l'émission de données du module vers le processeur 320C4x, ou, autrement dit, les échanges de données ont lieu alors que le périphérique a le jeton du lien. Lecture du processeur dans le Module d'interface. Par ailleurs, un mode dit de "Rebouclage" (ou "écho") est défini comme étant la succession d'un échange de type Ecriture, suivi de l'échange équivalent de type Lecture. Le contenu des mots échangés sur le lien doit être optimisé afin de répondre au besoin de vitesse de transmission. Le contenu des 3o commandes doit donc être décrit avec précision. Un mot de commande doit définir le sens d'échanges Ecriture/Lecture. Il doit aussi contenir l'activation du mode Rebouclage ou non, ainsi qu'indiquer si le cycle d'accès est Monocoup ou Séquentiel. Dès lors, il n'est plus besoin d'indiquer si le mot est un mot de commande ou un mot de donnée, cette information étant déductible de la position du mot dans la séquence d'échanges. Un mot de commande doit également contenir l'adresse du Module adressé, afin de pouvoir fonctionner en mode "Broadcast". Il doit également contenir l'adresse du périphérique adressé afin de permettre de le sélectionner. De plus, le mot de commande doit contenir l'adresse d'accès au périphérique choisi, afin de permettre des accès aléatoires à celuici. La dernière information contenue dans le mot de commande est un champ de données qui diffère suivant le mode d'échange utilisé. En mode Monocoup, dans le sens Ecriture, il s'agit de la donnée à écrire à l'adresse choisie dans le périphérique sélectionné. Dans le sens Lecture, ce champ n'a aucune signification. En mode Séquentiel, le contenu de ce champ indique alors la longueur de la séquence qui suit. Un format de données émises par le processeur sur le lien selon les deux modes est donné ci-après à titre d'exemple. Les dynamiques des paramètres sont indiquées pour exemple et peuvent être modifiées suivant le besoin dans le cadre des 32 bits d'un mot. En mode Monocoup: Mot Poids (31:29) Poids (28:16) Poids (15:0) Mot transmis Rebouclage, Adresse Donnée Séquentiel, Lecture/Ecriture En mode Séquentiel: Mot Poids (31:29) Poids (28:16) Poids (15:0) Mot transmis Rebouclage, Adresse Longueur Séquentiel, Séquence (15:0) Lecture/Ecriture En mode Séquentiel, le format est équivalent à celui de l'adressage Monocoup, le mot commande contient simplement la longueur de la séquence. La longueur de la séquence est définie comme étant le nombre de données (16 bits) à transmettre et non pas le nombre de mots de 32 bits. Sur les mots suivants, dans le sens Ecriture, la concaténation de deux mots de données sur un seul message peut prendre le format suivant: Mot | Poids (31:16) | Poids (15:0) Mot transmis Donnée (Adr+1) Donnée (Adr) Il est à noter que la longueur effective de la séquence peut être impaire: dans ce cas, aucune action pour la dernière donnée (numéro pair) transmise n'est effectuée par le Module. Un format de données émises par le Module (en réponse à une demande de Lecture du processeur) sur le lien est donnée ci-après à titre o d'exemple pour les modes Monocoup et Séquentiel. En mode Monocoup: Mot Poids (31:16) Poids (15:0) Mot transmis Recopie de la commande Donnée (mêmes poids) En mode Séquentiel: Mot Poids (31:0) Mot transmis Recopie de la commande Sur les mots suivants, dans le sens Ecriture, la concaténation des deux mots de données sur un seul message utilise le format suivant: Mot Poids (31:16) Poids (15:0) Mot transmis Donnée (Adr+ 1) Donnée (Adr) Il est à noter que la longueur effective de la séquence peut être impaire: le Module recopie alors sur la dernière donnée transmise, l'antépénultième. A la fin de la transmission de données, le Module renvoie un mot de "Checksum", terminologie anglosaxonne signifiant "calcul de contrôle", calculé sur 32 bits sur tous les mots de données émis sans prendre en compte le mot de recopie du "Header", terminologie anglo-saxonne signifiant "en-tête". Il est à noter que la structure d'une trame en Lecture Séquentielle est adaptée au traitement qui peut être faite par le processeur. Celui-ci peut traiter le "Header", calculer ainsi la longueur de la trame à suivre et armer un de ses DMA, abréviation anglo-saxonne pour "Direct Memory Access", sur cette longueur. Ce système permet d'absorber un fort débit sur le lien avec traitement différé par le processeur des informations reçues dans leur globalité et sans ralentir le débit de communication. Dans le cas d'une commande de Rebouclage, la séquence d'écriture reste inchangée, puis, dès qu'elle est terminée, le Module recopie (en interne et sans intervention du processeur) la commande initiale en modifiant la valeur du bit mode Lecture/Ecriture. Cette "pseudo" commande est alors exécutée comme une commande de lecture "normale" avec les mêmes paramètres que la commande d'écriture précédente. ce mode de Rebouclage est également valable pour les modes Monocoup et Séquentiel. i5 Ce mode de fonctionnement permet au processeur de vérifier aisément l'intégrité de l'écriture qui a précédé. Un autre intérêt lié à cette commande est le positionnement et la relecture des demandes de sémaphores par le processeur. En effet, une simple commande d'écriture rebouclée lui permet de demander un sémaphore et de contrôler s'il l'a obtenu ou non. La puissance de ce mode de fonctionnement est ainsi mise en évidence pour le test de la communication, mais aussi en terme de fonctionnalité d'échange. Dans certains cas, configurables suivant le besoin, le Module peut émettre une séquence de mots vers le processeur. Cet échange particulier est dénommé mode "Interruption". Dans ce mode, le Module génère en interne une demande de lecture avec les paramètres désirés. Le traitement de cette commande est effectué ensuite comme une lecture normale. Cette génération a lieu alors 3o que la fonction d'interprétation des commandes est dans son état de repos (aucune commande active). L'utilisation la plus courante de ce mode est dans le cas de la détection d'un défaut sur le Module pour la signaler au processeur, maître sur son lien. Dans ce cas, le Module renvoie un mot vers le processeur correspondant à une lecture en mode Monocoup avec comme adresse la localisation du défaut et comme donnée un code décrivant le défaut. Ce mode peut également servir à synchroniser le processeur sur un rythme connu seulement du Module, par exemple en traitement vidéo, le rythme trame. Les figures 3 à 10 suivantes servent à illustrer les différents chronogrammes respectifs à un échange de données sur un lien de communication en fonction des bits de mode Lecture/Ecriture, Séquentiel et Rebouclage du mot de commande. Dans ces différents chromogrammes, la même lexicographie suivante est utilisée: Cmd: mot de commande Hmon: "Header" Monocoup Hseq: "Header"' Séquentiel Dseq: Donnée séquentielle Cksm: "Checksum" message Figure 3, en mode Lecture Monocoup Cmd, le Module inhibe la réception sur le lien, fait la demande de jeton à la réception de la commande, attend le basculement et accède au périphérique à l'adresse contenue dans le Champ adresse de la commande. Quand le périphérique a positionné sa donnée, le Module émet sur le lien la donnée de type Monocoup, contenant la donnée, puis réautorise la réception. Figure 4, en mode Lecture Séquentielle, le processeur lit une zone périphérique, I'adresse de base et la longueur de la séquence étant contenues dans la commande. La "Checksum" est calculée uniquement sur les données. Figure 5, en mode Ecriture Monocoup, la donnée est écrite dans le périphérique à l'adresse qui continue dans la commande. Figure 6, en mode Ecriture Monocoup avec Rebouclage, le processeur vérifie qu'il a bien écrit la donnée dans le périphérique. A la fin de l'écriture, le Module évalue le paramètre Rebouclage et relance un mode Lecture (demande de jeton...). Figure 7, en mode Ecriture Séquentielle, le processeur écrit un bloc de données dans un périphérique, I'adresse de base et la longueur étant contenues dans la commande. Figure 8, en mode Ecriture Séquentielle avec Rebouclage, le processeur vérifie qu'il a bien écrit les données dans le périphérique. A la fin de l'écriture, le Module évalue le paramètre Rebouclage et relance un mode Lecture (demande de jeton...). Figure 9, en mode Interruption (type Monocoup), le Module émet sur le lien de sa propre initiative avec un "header" défini par l'utilisateur. Figure 10, en mode Interruption (type Séquentiel), le Module émet (sur le lien de sa propre initiative avec un "header" défini par l'utilisateur). Un synoptique du Module mettant en oeuvre les fonctions 1o précédemment décrites est illustré à la figure 11. Il comporte deux blocs principaux: un premier bloc IntProc A et un deuxième bloc IntPer B. Le premier bloc IntProc A, interface avec le lien de communication, assure la réception et l'émission des mots sur le lien en gérant les échanges de jetons (CAckB, CReqB) et le "handshake" sur les données (CStrB, CRdyB), terminologie anglo-saxonne signifiant "échange". Le deuxième bloc IntPer B, interface avec les périphériques, interprète le mot de commande pour gérer les accès aux périphériques d'une part et les accès au premier bloc A d'autre part. CRdyB, CStrB, CData (7...0), CReqB et CAckB sont les signaux bidirectionnels d'échanges sur le lien. Leur description est faite dans la notice d'utilisation du processeur 320C4x. Si le Module possède le jeton (sens=1), CReqB est une entrée (Req_in) pour permettre au processeur de réclamer le jeton, et CackB est une sortie (Ackout) pour lui signifier que le jeton lui a été accordé. Les données étant émises sur le lien par IntProc A, CstrB est une sortie (Strout) pour signifier au processeur la présence de données et CrdyB est une entrée (Rdy_in) indiquant la prise en compte de l'octet par le processeur. Si le Module n'a pas le jeton (sens=0), il y a inversion des rôles et des E/S entre le processeur et le Module. Une architecture du bloc IntProc A illustré à la figure 12 est composé de trois sous-blocs: - un premier sous-bloc Gest_tok A1 assurant la gestion du jeton, - un deuxième sous-bloc Rec A2 assurant la réception sur le lien, et, - un troisième sous-bloc Trx A3 assurant l'émission sur le lien. Les différentes entrées/sorties des sous-blocs A1 à A3 sont définies ciaprès: Pour le sous-bloc Gest_tok A1, les entrées/sorties sont définies ci-après: Entrées: SensProc: discret fourni par le processeur sur son propre sens. Dem_tok: demande de jeton par le Module pour transmettre sur le lien. Req_out: si le Module n'a pas le jeton, Dem_tok provoque cette requête. Ackin: réponse du processeur à Reqout quand il rend le jeton. Reqin: requête du processeur pour récupérer le jeton. Inh_rec: inhibition de Reqin par le Module. Ack_out: réponse du Module à un Rein quand il rend le jeton. Inh_wdog: inhibition de la surveillance du temps de réponse du processeur à une demande de jeton. Sorties: Sens: indique, à 0, que le processeur possède le jeton et à 1 que le Module possède ce jeton. Il commande la puissance sur les sorties bidirectionnelles. Le processeur génère son propre signal SensProc; la comparaison des deux sens permet de s'assurer qu'un seul équipement a le jeton à un moment donné. Pb_tok: si Sens est égal à SensProc, indique un problème. Ack_tok: la demande de jeton a abouti, sens=1. Ack_out: réponse du Module à Req-in quand il rend le jeton. Err_tok: sur une demande de jeton du Module, le processeur n'a pas répondu assez vite. Pour le sous-bloc Rec A2, les entrées/sorties sont définies ci-après: Entrées: Inh_Rec: inhibition de la réception. Ce signal est généré par le no bloc IntPer B afin d'interdire la prise en compte d'un nouveau mot. Tfr_cmd: indique que le mot transmis vers le bloc IntPer B sur Mot_rec a effectivement été pris en compte. StrB_in: à 0, indique que le processeur a positionné un octet sur le lien. CData_in [7:0]: lien data en écriture. Sens: assure l'inhibition de la réception quand le bloc IntProc A a le jeton. Sorties: Mot_Rec: indique la réception d'un mot sur le lien. Ce signal est le "strobe", terminologie anglo-saxonne pour "signal de validation", permettant au bloc IntPer B d'échantillonner le mot reçu sur le bus Datarec [31:0]. Datarec [31:0]: mot reçu. RdyB_out: indique au processeur que le mot présenté sur StrB-in a été pris en compte. Pour le sous-bloc Trx A3, les entrées/sorties sont définies ci-après: Entrées: Mat: signal généré par le bloc IntPer B signifiant qu'un mot à transmettre est disponible sur le bus DataEm [31:0]. Data_Em [31:0]: mot à émettre sur le lien en provenance du bloc IntPer B. RdyB_in: indique au bloc IntProc A que le processeur a échantillonné l'octet présenté. Sorties: Fin_Mat: indique au bloc IntPer B que le mot Data_Em [31:0] a été mis sur le lien (le registre d'émission est libre). StrB_out: à 0, indique au processeur qu'un octet est présent sur le lien data. CDataout [7:0]: lien data en lecture. Le bloc IntPer B gère les échanges sur le lien et les accès aux périphériques. Les différents modes supportés par cet interface sont: Ecriture processeur Monocoup, - Ecriture processeur Monocoup et Rebouclage, - Ecriture processeur Séquentielle, - Ecriture processeur Séquentielle et Rebouclage, - Lecture processeur Monocoup, et - Lecture processeur Séquentielle. Ces six modes sont initialisés par la réception par le bloc IntPer B d'un mot de commande Cmd. Deux autres modes permettent à cette interface d'émettre sur le lien de sa propre initiative: - Lecture processeur Monocoup de type Interruption (dloc), et - Lecture processeur Séquentielle de type Interruption (dloc). Une architecture du bloc IntPer B est illustrée par la figure 13. Ce bloc met en oeuvre deux fonctions principales: une première fonction assurant la supervision des accès au processeur et une deuxième fonction assurant la supervision des accès aux périphériques. La première fonction de supervision est mise en oeuvre par les sous-blocs: Supervision Accès Processeur B1, Génération "Header" B2, Génération "Checksum" B3, Registre Cmd B4 et un sous-bloc B5 fournissant une logique combinatoire et un multiplexage sur les données rentrantes io issues du Registre Cmd B4. Le sous-bloc Supervision Accès Processeur B1 génère tous les signaux de contrôle interne du bloc B. Un schéma fonctionnel du sous-bloc B5 est illustré à la figure 14. Il comporte une machine d'état B51, qui réalise la logique combinatoire assurant le séquencement des messages sur le lien, et une série de i5 multiplexeurs B52 et B53 réalisant le multiplexage. Deux modes principaux sont implantés dans le bloc B: - mode Lecture Séquentielle et, - mode Ecriture Séquentielle Le mode Monocoup, en Lecture ou en Ecriture, est obtenu en forçant à 1 la longueur de l'accès dans le compteur de séquence B6. La fonction Rebouclage est obtenue en lançant une phase de LectureSéquentielle après avoir terminé l'accès Ecriture demandé. A la fin de l'accès Ecriture, le paramètre Rebouclage de Cmd est évalué et, si le Rebouclage est demandé, le bloc IntPer B modifie le bit Lecture/Ecriture (RwB) dans Cmd et lance la phase de lecture comme si cette nouvelle commande lui était arrivée par le lien. Dans le mode déclenchement local, le mot Cmd est fourni en local, validé par un signal savCMD pris en compte par la machine d'état B51 pendant l'état de repos, la phase de Lecture est alors lancée de la même façon que dans la fonction Rebouclage (Mot_rec composite). La deuxième fonction de supervision est mise en oeuvre par les sousblocs: Supervision accès Périphériques B6, Compteur de séquence B7, Compteur d'adresse B8 et des registres de données DATA en Lecture et en Ecriture B9. Le bloc B gère les accès aux périphériques. A l'entrée dans les états Lecture ou Ecriture (Top_Seq) de la machine état B51 décrite ci-dessus, il génère le Deb_accès et attend en retour le Fin_accès puis il incrémente le compteur d'adresse B8 et le compteur de séquence B7. Quand le bloc compteur de séquence B7 déclenche sur le dernier accès, il renvoie vers la machine d'état B51 un signal Finseq qui la fait sortir de l'état Lecture ou Ecriture. Le sous-bloc B8 gère également l'inhibition de la réception en écriture et l'attente de la fin de l'émission sur le lien en Lecture pour assurer le "handshake" avec le bloc IntProc A. Le bloc IntPer B présente aux périphériques: - Un bus d'adresse, Adr [12:0], - Un bus de données en écriture, Data_Ecr [15:0], - Un bus de données en lecture, Data_Lec [15:0], - Un signal d'Ecriture/Lecture, RwB, - Un signal de lancement d'accès, Deb_acc, - Un signal de fin d'accès, Fin_acc retourné par le périphérique concerné, et - Dloc et Cmdloc permettant d'imposer une émission sur le lien. Suivant le type de périphériques, ces signaux permettent de reconstituer les "Chip Select" (CsB), les "Output Enable" (Oeb) et les 'Write Enable" (WeB) d'accès aux périphériques accédés. Chaque périphérique possède une entrée d'activation, "ET' logique entre Deb_acc et son décodage d'adresse associé, et une sortie Finacc. L'impulsion retournée Fin_acc, est le "OU" logique de tous les Fin_acc. Les figures 15 à 19, illustrent le format utilisé pour un échange des mots sur le lien mis en oeuvre par le procédé selon l'invention, respectivement pour un mot de commande Cmd, un "header"' en mode Monocoup Hmon et en mode Séquentiel Hseq, un "data" en mode Séquentiel Dseq, et un "checksum" Cksm. Un exemple de commande en Ecriture Séquentielle Rebouclée dans une RAM, abréviation anglo-saxonne pour "Read Only Memory", (longueur de séquence = 4 données 16 bits; à partir de l'adresse 0f) par l'intermédiaire du lien de communication est donné ci-après: Le processeur doit envoyer la commande suivante: Mot | Poids (31:29) | Poids (28:24) | Poids (23:16) | Poids (15:0) Mottransmis 110 00100 Of 0003 suivi de mots de 32 bits contenant les données: |I Mot Poids (31:16) Poids (15:0) Mot transmis Donnée (adresse=10) Donnée (adresse=0) [I Mot Poids (31:16) Poids (15:0) Mot transmis Donnée (adresse=12) Donnée (adresse=11) Le processeur reçoit alors une demande de jeton, qu'il satisfait, puis reçoit les mots suivants: un "header"': Mot Poids(31:29) Poids(28:24) Poids(23:16) Poids(15:0) Mottransmis 011 00100 Of 0003 suivi de deux mots de 32 bits contenant les données: Mot Poids (31:16) i Poids (15:0) Mot transmis Donnée (adresse=10) Donnée (adresse=0 Mot Poids (31:16) Poids (15:0) Mot transmis Donnée (adresse=12) Donnée (adresse=11) suivi d'une somme de contrôle calculée uniquement sur les données sur 32 bits (sur les deux mots ci-dessus): Mot Poids (31:0) Mot transmis somme de contrôle Le ou les Modules peuvent être mis en oeuvre à l'aide de circuits spécialisés, notamment des FPGA, abréviation anglo-saxonne pour "Field Programmable Gate Array". L'invention n'est pas limitée aux processeurs 320C4x de Texas Instrument mais s'applique à tout processeur possédant le même type de liens de communication. REVENDICATIONS 1. Procédé de codage de données numériques échangées sous la forme de mots de format déterminé, entre un processeur et au moins un périphérique quelconque, caractérisé en ce qu'il consiste, en utilisant un lien de communication asynchrone du processeur, lien destiné à l'interconnexion de plusieurs processeurs du même type entre eux, pour échanger des données numériques entre le processeur et le périphérique: - à identifier le ou les périphériques, connecter au processeur, l0 - à optimiser la vitesse de transmission des données transitant sur le lien, - a différencier l'interprétation des données et de leur application sur le périphérique, et - a tester les échanges de donnée sur le lien. 2. Procédé selon la revendication 1, caractérisé en ce qu'il consiste, pour optimiser la vitesse de transmission, à effectuer une concaténation des données dans les mots échangés sur le lien, sans répétition d'informations superflues, pour former un seul message de format déterminé. 3. Procédé selon la revendication 2, caractérisé en ce que l'échange des mots sur le lien est effectué suivant deux sens d'accès, Lecture/Ecriture, et deux types d'accès, Séquentiel/Monocoup, avec une fonction de Rebouclage ou non, la fonction de Rebouclage définissant la succession d'un échange sur le lien dans le sens Ecriture et dans le sens Lecture. 4. Procédé selon la revendication 3, caractérisé en ce que les mots sont différenciés en deux types de mots: un mot de Donnée échangé uniquement en accès Séquentiel et un mot de Commande comportant des informations sur le sens et le type d'accès, sur l'activation de la fonction de Rebouclage et sur l'adresse du ou des périphériques connectés sur le lien. 5. Procédé selon la revendication 4, caractérisé en ce que dans un mode d'Interruption, une demande de Lecture est générée par le lien, en mode Monocoup/Séquentiel permettant de détecter un éventuel défaut sur le dernier échange effectué sur le lien. 6. Dispositif de codage de données numériques échangées, sous forme de mots de donnée et de commande à un format déterminé, entre un processeur et au moins un périphérique quelconque, caractérisé en ce qu'il comporte un Module connecté entre le port de communication asynchrone du processeur, destiné à la connexion de plusieurs processeurs du même type entre eux, et le périphérique, et en ce que le Module comporte: - un premier bloc (A) couplé au port de communication du processeur, assurant la réception et l'émission des mots échangés entre le processeur et le périphérique en gérant les échanges de jetons et les échanges sur les données (CStrB, CRdyB), et - un deuxième bloc (B) couplé au périphérique, interprétant le mot de commande pour gérer les accès au périphérique d'une part et les accès au premier bloc (A) d'autre part. 7. Dispositif de codage selon la revendication 6, caractérisé en ce que le premier bloc (A) comporte: - un premier sous-bloc (A1) assurant la gestion du jeton échangé sur le lien entre le processeur et le Module (A, B), - un deuxième sous-bloc (A2) gérant la réception des mots échangés sur le lien entre le processeur et le périphérique en fonction d'informations qui lui sont transmises par le deuxième bloc (B), et indiquant au processeur que le mot reçu a été pris en compte par le Module (A, B), et - un troisième sous-bloc (A3) gérant l'émission des mots échangés sur le lien entre le processeur et le périphérique, en fonction d'informations transmises par le deuxième bloc (B) et indiquant au processeur que le mot émis a été pris en compte par le Module (A, B). 8. Dispositif de codage selon la revendication 6, caractérisé en ce que le deuxième bloc (B), comporte: - un premier ensemble de sous-blocs (B1 à B5) assurant une première fonction de supervision des accès au processeur, et - un deuxième ensemble de sous-blocs (B6 à B9) assurant une deuxième fonction de supervision des acces au périphérique. 9. Dispositif de codage selon la revendication 8, caractérisé en ce le premier ensemble de sous-blocs (B1 à B5) comporte une machine d'état (B51) assurant le séquencement des messages échangés entre le processeur et le périphérique, et une série de multiplexeurs (B52 et B53) assurant le multiplexage des données rentrantes issues du sous-bloc Registre Cmd (B4).