Brevet FR2818774A1 — publié le 20020628

ARCHITECTURE ELECTRONIQUE PARALLELE COMPORTANT UNE PLURALITE D'UNITES DE TRAITEMENT CONNECTEES A UN BUS DE COMMUNICATION, ET ADRESSABLES PAR LEURS FONCTIONNALITES La présente invention concerne le domaine des architectures électroniques parallèles (multiprocesseurs et multitâches). Elle a pour objet une architecture comportant une pluralité d'unités de traitement connectées à un bus de communication et dialoguant entre elles selon un nouveau protocole. Dans le présent texte, on désigne par unité de traitement , toute machine qui est conçue pour exécuter automatiquement une ou plusieurs tâches distinctes. Il peut s'agir d'une unité de traitement de type câblée. De préférence, il s'agit d'une unité de traitement programmable comportant un processeur (microprocesseur, microcontrôleur,...) qui est programmé pour exécuter automatiquement une ou plusieurs tâches distinctes. De manière non exhaustive, l'unité de traitement peut être une machine programmable, tel que par exemple un micro-ordinateur, un périphérique d'une machine, une carte fille montée sur une carte mère fond de panier, etc. A ce jour, dans les architectures électroniques comportant plusieurs unités de traitement reliées par un bus de communication, chaque unité de traitement est repérée sur le bus par une adresse physique qui lui est propre. Les protocoles de communication connus à ce jour permettent de faire dialoguer une première unité de traitement (dite par la suite unité émettrice) avec une seconde unité de traitement (dite par la suite unité cible). Ainsi, lorsque l'unité émettrice envoie un message à l'unité cible, en vue par exemple de déclencher l'exécution par l'unité cible d'une tâche prédéfinie, l'unité émettrice émet sur le bus l'adresse de l'unité cible. Chaque unité de traitement est apte à décoder une adresse émise sur le bus, et lorsqu'une unité cible reconnaît son adresse, elle r charge en mémoire locale le message associé et exécute la tâche pour laquelle elle est programmée. L'unité cible et émettrice ont généralement des bus d'adresses et de données similaires et de taille fixée. Avec ce type d'architecture et de protocole de communication connus, il est difficile de réaliser un système muti-tâches dans lequel plusieurs unités de traitement réalisent en parallèle une même tâche (ou fonctionnalité), car ce parallélisme des unités de traitement nécessite une gestion compliquée de l'adressage des unités de traitement. La présente invention vise a proposer une nouvelle architecture parallèle qui permet de pallier cet inconvénient et qui de surcroît est plus facilement évolutive et modulable, par ajout d'une nouvelle unité de traitement, remplacement ou suppression d'une unité de traitement. Ce but est atteint par l'architecture parallèle de l'invention qui est connue en ce qu'elle comporte une pluralité d'unités de traitement connectées à un bus de communication, chaque unité de traitement étant conçue pour exécuter automatiquement une ou plusieurs tâches prédéfinies. 1. De manière caractéristique et nouvelle selon l'invention, chaque unité de traitement est configurée de telle sorte que chacune de ses tâches est associée à un en-tête ; chaque unité de traitement est conçue pour communiquer avec les autres unités de traitement selon le protocole suivant : envoi sur le bus d'un message comportant au moins un en-tête caractérisant une fonctionnalité, et éventuellement une trame constituée d'un ou plusieurs mots, et en ce que chaque unité de traitement est conçue pour décoder chaque en-tête transitant sur le bus, et pour, en fonction de la valeur de cet en-tête, soit ignorer le message émis sur le bus, soit exécuter la tâche associée à l'en-tête de ce message. Ainsi, le fonctionnement de l'architecture de l'invention repose sur un principe nouveau qui est l'adressage d'une fonctionnalité sur le bus de communication, plutôt qu'un adressage d'une unité de traitement cible r donnée. Dans l'invention, l'en-tête qui caractérise une fonctionnalité permet ainsi de réveiller toutes les unités de traitement connectées qui reconnaissent cette fonctionnalité, afin que ces unités de traitement exécutent parallèlement la tâche associée à cette fonctionnalité. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description ci-après d'un exemple préféré de réalisation de l'invention, laquelle description est donnée à titre d'exemple non limitatif, et en référence au dessin annexé sur lequel : la figure 1 est un synoptique général d'un exemple d'architecture selon l'invention, de type multi-maîtres/multi-esclaves, avec plusieurs unités de traitement connectées à un bus parallèle 16 bits (DO-D15), désigné plus généralement bus a, la figure 2 représente un schéma électrique détaillé pour la réalisation de la mémoire FIFO et de la mémoire de validation d'une unité de traitement, la figure 3 représente un chronogramme des principaux signaux mis en oeuvre lors d'une opération d'écriture d'un en-tête sur le bus a par une unité de traitement maître, la figure 4 représente un chronogramme des principaux signaux mis en oeuvre lors d'une opération d'écriture sur le bus a, par l'unité de traitement maître, d'un mot d'une trame. la figure 5 représente un chronogramme des principaux signaux mis en oeuvre lors d'une opération de lecture, par une unité de traitement esclave, d'un en-tête valide présent sur le bus a, la figure 6 représente un chronogramme des principaux signaux mis en oeuvre par une unité de traitement esclave, après réception par cet unité de traitement esclave d'un en-tête valide, et écriture sur le bus a, d'une trame de mots par l'unité de traitement maître, et la figure 7 représente un chronogramme des principaux signaux mis en oeuvre par une unité de traitement esclave, après réception d'un entête non valide et écriture sur le bus ex d'un mot d'une trame par l'unité de traitement maître. r En référence au synoptique général de la figure 1, une architecture conforme à l'invention comprend plusieurs unités de traitement 1a, 1b,..., 1n, qui sont connectées à un bus de données parallèle dit par la suite bus ex. L'architecture de la figure 1 est avantageusement de type multi- maîtres/multi-esclaves. Lorsque l'une des unités de traitement 1a, 1b,.... ou 1n veut émettre un message sur le bus a, elle prend la direction du bus et devient unité maître, les autre unités devenant esclaves. Une fois son message émis sur le bus, l'unité de traitement maître libère le bus, une autre unité de traitement pouvant à son tour prendre la direction du bus a, pour émettre un message. Ce mode de fonctionnement implique la mise en oeuvre de moyens d'arbitrage de l'accès en écriture au bus, lesquels moyens reçoivent en entrée en provenance de chaque unité de traitement des signaux de demande d'accès en écriture au bus, et délivrent en sortie pour chaque unité de traitement des signaux d'autorisation d'accès au bus en écriture. Ces moyens d'arbitrage étant par ailleurs connus de l'homme du métier, ils ne sont pas représentés sur la figure 1 et ne seront pas plus amplement décrits dans le présent texte. L'invention n'est par ailleurs pas limitée à une architecture de type multi-maîtres/multi-esclaves, mais peut par exemple également s'appliquer à la réalisation d'une architecture avec une seule unité de traitement maître apte à écrire sur le bus, les autres unités de traitement étant toujours esclaves, et pouvant accéder au bus uniquement en lecture. Définitions des principaux termes : Bus c : Le bus ex est un bus de données qui est d'une manière générale composé de (q) conducteurs électriques parallèles, q étant un entier supérieur ou égal à 1. Dans l'exemple particulier illustré sur les figures 1 et 2, le bus a est un bus constitué de seize conducteurs électriques parallèles (bus 16 bits (DO-D15)). --------------------- Atome de granularité (AG) L'atome de granularité désigné ci après (AG) correspond à la plus petite taille d'unité de traitement pouvant dialoguer sur le bus ex (voir ciaprès la définition de couleur ). Si on considère que le bus ex est d'une manière générale composé de q conducteurs électriques parallèles, (q étant un entier supérieur ou égal à un), alors : q= AG. 2P. AG est nécessairement une puissance de deux. Couleur d'une unité de traitement La couleur d'une unité de traitement est définie par la taille (nombre de bits) de son bus de données. Dans l'exemple particulier de la figure 1, l'unité de traitement ta est une machine 16 bits (bus de données DO- D15), l'unité de traitement 1b est une machine 4 bits (bus de données DO- D3),..., l'unité de traitement 1n est une machine 8 bits (bus de données DO-D7). Par la suite, les couleurs d'unité de traitement seront notées A, B, C, D,... selon la convention suivante : une unité de traitement capable de ne communiquer que sur un (AG) sera de couleur A ; une unité de traitement capable de communiquer au maximum sur deux (AG) sera de couleur B ; une unité de traitement capable communiquer au maximum quatre (AG) sera de couleur C ; une unité de traitement capable communiquer au maximum sur huit (AG) sera de couleur D, etc... Mot Un mot correspond à la valeur du bus ex à un instant donné. La taille maximale d'un mot est limitée par le nombre de conducteurs parallèles du bus a. Message Un message correspond à la succession de mots qui sont écrits en série sur le bus ex par une unité de traitement. Un message est composé d'un premier mot qui est un en-tête (Function Key), suivi d'une trame qui est, selon le format série utilisé, composée d'un ou plusieurs mots successifs. Format série (fis) Le format série permet de définir tous les mots qui composent un message transitant sur le bus. Les formats séries utilisables sur le bus ex peuvent être très différents, et ont nécessairement pour caractéristique commune que le premier mot d'un message est un en-tête. Un exemple de format série standard, et non limitatif de l'invention, est donné ci-après : En-tête (FunctionKey) (voir définition ci-après) (Taille du message) (suivant FunctionKey), un numéro (Signature) (suivant FunctionKey), explique quel est le type du maître qui émet ainsi que sa place sur le bus (Type) (suivant FunctionKey), un numéro (Taille trame) (suivant FunctionKey), un nombre Trame (suivant FunctionKey) N mots qui se suivent Sentinelle bits de contrôle sur tous les mots du message, permettant de savoir si une erreur a eu lieu sur l'un des bits de transmission Suivant la fonctionnalité, codée par l'en-tête, d'autres formats série peuvent être dérivés de ce format standard ; le format série le plus simple avec contrôle de la transmission étant : en-tête/sentinelle. Dans une variante de réalisation encore plus simple (sans contrôle de l'intégrité des données transmises), il est envisageable qu'un message puisse être constitué uniquement d'un entête. Format parallèle (FP) On associe à chaque couleur (A, B, C, D,...) d'unité de traitement un formatage particulier des messages qui transitent sur le bus ex. v Un exemple de codage du format parallèle (FP) est donné dans le tableau ci-après : 1 1 En-tête sur le bus Format parallèle 1er 2ème 3ème 4ème 5ème 6ème 7ème 8ème AG AG AG AG AG AG AG AG XXXX 0 0 0 0 0 0 0 FP-A:2AG Fonctionnalités 0 XXXX 0 0 0 0 0 FP-B 2AG Fonctionnalités 0 XXXX 0 0 0 0 FP-B : 2AG Fonctionnalités 0 0 XXXX XXXX 0 0 0 0 FP-C : 2 AG Fonctionnalités 0 0 00XXXX XXXX XXXX XXXX FP-D : 24AG (Fonctionnalités XXXX XXXX 0 0 0 0 0 0 FP-AB XXXX 0 XXXX XXXX 0 0 0 0 FP-AC XXXX 0 0 0 XXXX XXXX XXXX XXXX FP-AD XXXX 0 XXXX XXXX XXXX XXXX XXXX XXXX FP-ACD ... XXXX désigne qu'il est possible de prendre n'importe quelle valeur possible. Le 0 désigne que tous les conducteurs de cet AG sont mis à zéro. Forme de chacun des FP- Le FP-A : on utilise les AG premiers conducteurs du bus pour tous les autres mots qui composeront la trame du message par la suite. On s'adresse donc à toutes les unités de traitement connectées au bus et ayant la fonctionnalité recherchée, puisque par définition même la plus petite unité de traitement peut communiquer sur un AG. Le FP-B : on utilise les 2AG premiers conducteurs du bus pour tous les autres mots qui composeront la trame du message par la suite. r Par définition, on exclut les unités de traitement qui ne sont pas capables d'y accéder, puisque de toute façon elles n'auront pu décoder le XXXX qui était sur le 2 me AG. On s'adresse forcément aux seules machines capables de communiquer sur 2 AG. Le FP-C : on utilise les 4AG premiers conducteurs du bus pour tous les autres mots qui composeront la trame du message par la suite. Le FP-D : on utilise les 8AG premiers conducteurs du bus pour tous les autres mots qui composeront la trame du message par la suite. Les formats mixtes (FP-AB, FP-AC, FP-AD, FP-ACD,...) permettent de fournir une donnée plus raffinée (plus de détails) si les processeurs auxquels on s'adresse ont les moyens de lire la donnée sur plusieurs AG. Exemple d'utilisation des formats mixtes FP-AB et FP-AD : Le format FP-AB s'adresse à la fois aux unités de traitement pouvant lire sur 1 AG et à celles pouvant lire sur 2 AG. Celles qui lisent sur 1 AG ont une information suffisante pour remplir la fonctionnalité mais n'ont pas forcément tous les détails. Celles qui lisent sur 2 AG peuvent par exemple avoir un code correcteur d'erreur sur le 2 ème AG pour vérifier l'information qui a transité sur le 1 er AG. Le format FP-AD est un format qui peut par exemple être intéressant pour la transmission de petites images sur le bus ex. Le premier AG peut servir à coder le niveau moyen de gris (ou de couleur) d'un pavé de 9 pixels. Les unités de traitement ayant accès uniquement à cette information bénéficie quand même de la donnée : une image trois fois plus petite. Pour les unités de traitement ayant également accès au format FP-D, elles pourront bénéficier de la lecture de 8 AG en tout, les autres AG lui permettant par exemple de rajouter la différence par rapport à la moyenne pour connaître la valeur des pixels du pavé (principe des odelettes de Haar). En-tête (FunctionKey) Selon une caractéristique essentielle de l'invention, l'en-tête est le premier r mot de tout message transitant sur le bus a, et il définit principalement quelle est la fonctionnalité qui est adressée. De préférence, mais non nécessairement, cet en-tête permet également de définir : - le format parallèle du message, - le format série du message, - la couleur de l'unité de traitement qui a généré le message (unité de traitement maître) - une information qualitative sur la longueur du message. Fonctionnalité On appelle fonctionnalité toute fonction (ou tâche) qui peut être exécutée automatiquement par une unité de traitement connectée au bus a. Table des fonctionnalités Chaque unité de traitement est configurée en sorte de comporter une table des fonctionnalités, qui lui est propre, et qui associe chaque tâche exécutable par l'unité de traitement, à une valeur d'en-tête. De préférence, cette table des fonctionnalités définit également pour chaque fonctionnalité, le format série (FS) associé à cette fonctionnalité, ainsi que la longueur d'un message associé à cette fonctionnalité. Pour une unité de traitement donnée, le nombre de fonctionnalités possibles dépend uniquement du nombre d'AG qu'elle peut atteindre sur le bus et de la valeur de l'AG. Généralités sur le protocole de communication de l'invention L'échange de messages sur le bus ex est réalisé entre une unité de traitement maître qui a pris la direction du bus, et qui de ce fait est la seule unité de traitement autorisée à écrire des données sur le bus a, et les autres unités de traitement esclaves, qui peuvent accéder uniquement en lecture au bus a. Lorsqu'une unité de traitement 1a, 1b,.... ou 1n a pris la direction du bus a, elle commence par écrire sur le bus a un en-tête (FunctionKey), puis écrit ensuite sur le bus ex une trame (un ou plusieurs mots en r fonction du format série (FS) utilisé). L'en-tête est lu par chaque unité de traitement esclave. L'en-tête permet principalement à chaque unité de traitement esclave de déterminer si la trame émise sur le bus a lui est destinée, et dans l'affirmative, quelle est la tâche qu'elle doit exécuter. Lorsque l'en-tête émis sur le bus ne fait pas partie de la table des fonctionnalités d'une unité de traitement esclave, cette dernière ignore la trame émise sur le bus a consécutivement à l'en-tête. Dans le cas contraire, l'unité de traitement esclave lit également la trame émise sur le bus après l'en-tête, et exécute automatiquement la tâche qui est associée à cet en-tête dans sa table des fonctionnalités. Ainsi, la nouveauté du protocole de communication de l'invention découle du fait que lors de l'écriture d'un message sur le bus par une unité de traitement maître, on ne réalise pas un adressage d'une unité de traitement esclave donnée localisée sur le bus par une adresse (physique ou logique), mais on réalise un adressage des fonctionnalités (tâches) des unités de traitement esclaves, le message étant traité en parallèle par toutes les unités de traitement possédant une fonctionnalité associée à l'en-tête émis sur le bus. Exemple de structure d'une unité de traitement (la,.... 1n) En référence à la figure 1, une unité de traitement 1a,..., 1n comporte essentiellement : - un microprocesseur 2, - une mémoire de validation 3, - une mémoire 4 de type FIFO, - une unité logique 5 permettant le séquencement du fonctionnement de la mémoire de validation 3 et de la mémoire FIFO 4, à partir de signaux horloges CLKA et CLKD, - un bus de données 6, dit par la suite bus interface, - un bus interne 7, sur lequel le microprocesseur 2, peut lire ou écrire des données, - des registres trois états 6a, qui sous la commande du microprocesseur 2 (signal 8) permettent l'écriture sur le bus interface 6 (DO-D15) des données présentes sur le bus interne 7. Bus interface (6) Ce bus interface est un bus de données (n) bits [ (DO-Dn-1)] constitué d'une manière générale de (n) conducteurs électriques parallèles, [n entier inférieur ou égal à q (taille du bus &alpha;)], reliés en parallèle aux n premiers conducteurs du bus a. Microprocesseur (2)/bus interne (7) Le microprocesseur est de manière usuelle associé à une mémoire vive (RAM), qui par soucis de simplification n'a pas été représentée sur cette figure 1, et à laquelle le microprocesseur 2 peut de manière usuelle accéder en lecture et en écriture. Cette mémoire vive comporte la table des fonctionnalités de l'unité de traitement, ainsi que le programme de fonctionnement du microprocesseur, qui sera détaillé ultérieurement. Le bus interne 7 est un bus ISA qui comporte de manière usuelle : - un bus de données [bus de donnés 16bits/DJSAO à DOSA15 dans le cas de l'unité de traitement 1a au format 16 bits], - un bus d'adresse non représenté sur le synoptique général de la figure 1, et dont les deux bits d'adresse de poids faible sont référencés respectivement AOJSA et A1JSA sur les chronogrammes des figures 3 et 4, et - un bus de contrôle constitué par les signaux d'écriture WrJSA et de lecture RdJSA (signaux délivrés par le microprocesseur 2) et par le signal de sélection CsJSA, issu du décodage des signaux de lecture et d'écriture ; ces signaux WCISA, RdJSA, et CsJSA ne sont pas représentés sur le synoptique de la figure 1, et apparaissent uniquement sur les chronogrammes des figures 3 et 4. Mémoire de validation (Es) La mémoire de validation 3 peut indifféremment être une mémoire vive ou r une mémoire morte. De préférence, il s'agit d'une mémoire de type EEPROM. Cette mémoire de validation fonctionne en table de correspondance de façon à lister les en-têtes valides, le port d'adresse de cette mémoire de validation 3 étant relié au bus a. Le port de sortie de cette mémoire de validation 3 est relié (signaux 9) au microprocesseur 2, sur un port de ce microprocesseur dédié au traitement des interruptions. L'accès en lecture à la mémoire de validation 3 est séquencé par le signal 5a, délivré par l'unité logique 5, à partir des signaux horloge CLKA et CLKD. Tel que cela apparaîtra plus clairement ultérieurement dans la description, la mémoire de validation 3 a pour fonction de valider ou non (signaux 9), pour le microprocesseur 2, un en-tête présent sur le bus a. A cet effet, à chaque adresse de la mémoire de validation (correspondant à une valeur d'en-tête pouvant être émise par une unité de traitement sur le bus a) est stockée une donnée qui est reconnue par le microprocesseur 2 comme étant une donnée, soit de validation, soit de non validation de l'entête. Lorsque la donnée délivrée en sortie par la mémoire de validation 3 (signaux 9) est une donnée de validation, le microprocesseur 2 est informé qu'il doit charger la trame qui est émise sur le bus a après l'entête qui a été validé. A l'inverse, lorsque la donnée issue de la mémoire de validation est une donnée qui ne valide pas l'en-tête, le microprocesseur 2 ignore la trame qui est émise sur le bus ex après cet en-tête. Ces données de validation ou de non validation pour chaque adresse de la mémoire 3 sont propres à chaque unité de traitement ta, 1b,.... 1n, et permettent de personnaliser le fonctionnement de l'unité de traitement. En référence à la figure 2, dans un exemple particulier de réalisation, la mémoire de validation 3 est réalisée au moyen d'un circuit intégré Cil tel que par exemple le circuit intégré commercialisé sous la référence AM29FO10. Dans cette réalisation, le port d'adresse de la mémoire correspond aux entrées AO à A15, lesquelles sont raccordées r respectivement en parallèle aux conducteurs électriques du bus a (DOD15). Le signal Ecriture Ad correspond au signal 5a de la figure 1, et les signaux Adresserejetée, ) RQ#5, ) RQ#4 ! RQ#3 IRQ#2 ! RQ#P sur le port de sortie de la mémoire correspondent aux signaux 9 précités du synoptique de la figure 1. Dans cette réalisation, la validation de la mémoire est répartie sur plusieurs niveaux, mais la validation utile est codée sur le signal IRQ #P. Lorsque ce signal IRQ #P est par exemple à l'état bas (respectivement à l'état haut), l'en-tête qui est présent sur le bus a est validé (respectivement non validé) pour le microprocesseur 2. Mémoire FIFO (4) En référence à la figure 1, la mémoire FIFO 4 est raccordée en entrée au bus a via le bus interface 6, et en sortie au bus de données du bus interne 7. Le microprocesseur 2 peut commander le chargement, dans la mémoire FIFO 4, d'un mot présent sur le bus ex, au moyen du signal d'écriture 10, ainsi que la sortie d'un mot stocké dans la mémoire FIFO 4, et son écriture sur le bus de données du bus interne 7, au moyen du signal de lecture 11. Le séquencement du chargement d'un mot dans la mémoire FIFO 4, ou d'une lecture d'un mot en mémoire FIFO 4 est synchronisé par un signal de cadencement 5b, délivré par l'unité logique 5 à partir des signaux horloges CLKA et CLKD. La mémoire FIFO 4 délivre également en sortie pour le microprocesseur 2 des signaux d'état 12 permettant d'indiquer au microprocesseur 2 son niveau de remplissage. En référence à la figure 2, dans un exemple particulier de réalisation, la mémoire FIFO 4 est réalisée à partir de deux circuits intégrés 8 bits CI2 et Cul3, et par exemple à partir de circuits intégrés commercialisés sous la référence IDT7200, chaque circuit intégré CI2 et CI3 étant dédié respectivement au stockage des bits de poids fort (D8 à D15) et de poids faible (DO à D7) du bus Dans cette variante de réalisation, les signaux référencés sur la figure 2 Empty~flag~H , FuitflagH , Halffull~H , Empty~flag~B Fullflag~B, Halffull B , correspondent aux signaux d'état 12 précités du synoptique de la figure 1, et permettent le codage de l'état de remplissage de chaque registre FIFO (C12 et CI3). Le signal référencé Ecriture~FIFO~OK correspond au signal d'écriture 10 précité de la figure 1. Les signaux "Lecture~FIFO~ B~"~et ~FIFO H correspondent au signal de lecture 11 précité de la figure 1. Le signal Reset~FIFO est un signal de remise à zéro de la mémoire FIFO qui est délivré par le microprocesseur 2, et qui est utilisé pour initialiser la mémoire 4. Registres trois états (Ra) Le bus de données du bus interne 7 d'une unité de traitement est connecté en parallèle au bus interface 6, via un ou plusieurs registres trois états 6a. Dans le cas par exemple de l'unité de traitement 1 a mettant en oeuvre un bus interne 16 bits (DJSAO-DJSA15), on pourra utiliser deux registres huit bits dédiés à l'écriture en parallèle sur le bus interface 6, et par là-même sur le bus a, respectivement des huit bits de poids faible (D- ISAO-D-ISA7) et des huit bits de poids forts (D~ISA8-D~ISA15) du bus de données du bus interne 7. Le transfert sur le bus&alpha; (D0-D15) d'une donnée présente sur le bus de données (D~ISAO-D~ISA15) du bus interne 7 est commandé par le microprocesseur au moyen du signal d'écriture 8 (figure 1). Signaux horloge CLKA et CLKD En référence à la figure 1, chaque microprocesseur 2 d'une unité de traitement délivre en sortie deux signaux horloge 2a et 2h, qui sont connectés, via des portes 13 à collecteur ouvert, à un bus horloge (CLKA, CLKD) commun à toutes les unités de traitement. Lorsqu'une unité de traitement prend la direction du bus a (unité de traitement maître), les signaux horloges CLKA et CLKD correspondent respectivement aux signaux horloge 2a et 2b du microprocesseur 2 de cette unité de traitement maître ; les signaux horloges 2a et 2b des autres unités de traitement esclaves sont quant à eux flottants et isolés du bus horloge r CLKA et CLKD. L'échange de données sur le bus ex est ainsi cadencé par l'unité de traitement maître, les unités de traitement esclaves assurant le chargement des messages écrits sur le bus ex (mémoire de validation 3/ signal 5a ; mémoire FIFO 4/signal 512) quelle que soit leur vitesse d'horloge propre (fréquence propre de fonctionnement de leur microprocesseur 2). Des unités de traitement possédant des vitesses d'horloge propres différentes peuvent donc avantageusement dialoguer entre elles. Fonctionnement du microprocesseur (2) d'une unité de traitement Programme principal Le microprocesseur 2 d'une unité de traitement est programmé pour exécuter en boucle le programme principal ci-après : a) lecture en mémoire FIFO 4 d'un message (en-tête et trame), b) décodage de la fonctionnalité associée à cette en-tête dans la table des fonctionnalités ; c) exécution automatique de la routine (tâche) correspondant à cette fonctionnalité. Ecriture d'un message sur le bus &alpha;(figure 3 et 4) Au cours de l'exécution de la routine de l'étape c) précitée, il peut arriver que le microprocesseur 2 soit amené à écrire sur le bus a un message, afin d'activer une fonctionnalité gérée par une ou plusieurs autres unités de traitement connectées au bus a. Dans ce cas, après avoir pris la direction du bus a, l'unité de traitement écrit sur le bus a l'en-tête codant cette fonctionnalité, et la trame des mots du message, puis libère le bus ex. Les chronogrammes des principaux signaux mis en oeuvre lors d'une telle opération d'écriture sont représentés respectivement sur les figures 3 et 4. Sur ces figures 3 et 4, les signaux Data-isba zu correspondent au bus de données du bus interne 7, c'est-à-dire par exemple aux bits D ISAO à DOSA15 (figure 2) du bus interne 7 de l'unité de traitement 1a. Les signaux ComCLKA et ComCLKB correspondent aux signaux 2a et r 21 précités. L'écriture d'un en-tête sur le bus de données du bus interne 7 se fait à l'adresse de base +2 d'offset ; ensuite l'écriture de la donnée sur le bus de donnée du bus interne 7 se fait à l'adresse de base +3 d'offset (cf. signaux AVISA et A1JSA). Chargement d'un message présent sur le bus a (figures 5 et 6) En cas de présence d'un en-tête valide sur le bus a, l'exécution du programme principal précité est interrompu par la donnée de validation qui est issue de la mémoire de validation (le signal IRQ #P change d'état). Le microprocesseur exécute alors une routine secondaire de chargement en mémoire FIFO 4 de l'en-tête et de la trame de mots émise sur le bus ex à la suite de cet entête, l'unité de traitement correspondante fonctionnant en esclave. Les chronogrammes des principaux signaux mis en oeuvre lors d'une opération de lecture sur le bus a, par une unité de traitement esclave, d'un en-tête valide sont représentés sur la figure 5. La figure 6 représente les chronogrammes des principaux signaux mis en oeuvre lors d'une opération de lecture sur le bus a, par une unité de traitement esclave, d'une trame de mots (figure 6/ Donnée n > Donnée nez écrite le bus a par une unité de traitement maître, en relation avec un entête valide précédemment écrit sur le bus En référence à la figure 5, s'agissant d'un en-tête valide pour l'unité de traitement esclave, en sortie de la mémoire validation 3, l'interruption IRQ#P change momentanément d'état. La capture de cet entête valide dans la mémoire FIFO 4 (signal 10/Ecriture-FIFO-OK) se fait par l'action simultanée des signaux CLKA et CLKD. En référence à la figure 6, la capture d'une donnée dans la mémoire FIFO 4 est cadencée uniquement par le signal CLKD. Réception d'un en-tête non valide/figure 7 En référence à la figure 7, lorsque l'en-tête présent sur le bus ex n'est pas valide pour une unité de traitement esclave, le signal d'interruption IRQ#P ne change pas d'état, et le programme principal précité du r microprocesseur 2 n'est pas interrompu. Le microprocesseur 2 ne commande pas le chargement de l'en-tête présent sur le bus ex dans la mémoire FIFO 4 (signal Ecriture~FIFO~OK ne change pas d'état), ni ultérieurement le chargement en mémoire FIFO 4 de la trame de mots transitant sur le bus après cet en-tête. Le message transitant sur le bus ex est ainsi ignoré par l'unité de traitement esclave. L'architecture multi processeurs qui a été décrite en référence aux figures 1 à 7 présente les principaux avantages ci-après : le principe d'adressage des unités de traitement par leurs fonctionnalités au moyen de l'en-tête (FunctionKey) permet de simplifier la gestion du parallélisme des tâches exécutées par les unités de traitement, et par làmême simplifie la programmation des unités de traitement ; en outre, il permet de réaliser à moindre coût une architecture puissante, à partir d'unités de traitement de faible puissance. - Cette architecture est avantageusement modulaire, et très facilement évolutive ; elle est en outre très robuste : on peut lui changer sa forme à chaud" (en fonctionnement) par ajout, suppression ou remplacement d'une unité de traitement, sans perturber grandement l'exécution du programme général de fonctionnement de l'architecture ; certaines unités de traitement qui constituent cette architecture peuvent donc tomber en panne sans qu'il soit nécessaire de réaliser un arrêt général du fonctionnement de l'architecture. - Cette architecture parallèle est universelle : elle permet de faire dialoguer entre elles des unités de traitement différentes, et en particulier des unités de traitement ayant des bus de données (bus interface 6) de tailles différentes ; la seule limitation sur la taille des unités de traitement pouvant être connectées est le nombre de bits en parallèle du bus a ; cette architecture ne fonctionne pas avec un format unique de données, mais fonctionne avec tout format de données, supérieur ou égal à la taille de l'atome de granularité (AG). l'échange de données sur le bus de communication (bus a) étant r cadencé par l'unité de traitement maître qui a pris la direction du bus (signaux CLK et CLD), les unités de traitement peuvent dialoguer entre elles quels que soient leurs processeurs, et surtout quelle que soit la cadence d'horloge de leurs processeurs. Exemple d'application On réalise un robot comportant une carte mère fond de panier sur laquelle sont montées cinq cartes filles (une carte fille correspondant à une unité de traitement) : une carte de propulsion pour commander le déplacement du robot, une carte sonore, une carte caméra, et une carte de décision comportementale (calculateur) pour gérer le comportement du robot. Les tableaux 1,2, 3,4 ci-après donnent un exemple d'implémentation d'en-têtes et de fonctionnalité associées. 1 TABLEAU 1 En-tête Fonctionnalité Carte propulsion & données 0 Réservé Jamais #:Jamais Arrêt d'urgence # : surchauffe moteur Toujours 2 Demande de déplacement en Jamais vitesse avant Toujours 3 Demande de déplacement en # :jamais vitesse arrière #:toujours 4 Demande de transmission #:Jamais numéro d'une image Jamais 5 Transmission d'une image Jamais image Jamais 6 Reconnaissance d'un humain #:Jamais nom toujours (ralentir) 7 Emettre un son #:Jamais numéro Jamais 8 Transmission d'un son # :jamais son jamais 9 Extinction carte Plus de batterie/défaut identifiant raison jamais 10 Demande d'identification des #:Jamais cartes présentes # :toujours 11 Déclaration de sa présence et #:sur demande (10) identifiant fonction sa fonction jamais TABLEAU 2 En-tête Fonctionnalité Carte caméra & données 0 Réservé J. : Jamais jamais 1 Arrêt d'urgence # :détection d'obstacle jamais 2 Demande de déplacement #:jamais vitesse en avant #:jamais 3 Demande de déplacement U jamais vitesse en arrière #:jamais 4 Demande de transmission : possible numéro d'une image #:toujours 5 Transmission d'une image #:sur demande (4) image fit # :toujours 6 Reconnaissance d'un # : sur reconnaissance nom humain toujours 7 Emettre un son # :jamais numéro # :jamais 8 Transmission d'un son jamais son jamais 9 Extinction carte plus de batterie/défaut identifiant raison jamais 10 Demande d'identification jamais des cartes présentes toujours 11 Déclaration de sa présence sur demande (10) identifiant fonction et sa fonction # :jamais , -- 1 TABLEAU 3 1 1 En-tête Fonctionnalité Carte sonore (micro/HP) & données 0 Réservé Jamais #:jamais 1 Arrêt d'urgence #:Jamais Toujours (son d'alerte) 2 Demande de déplacement J. : jamais vitesse en avant # :jamais 3 Demande de déplacement #:jamais vitesse en arrière #:jamais 4 Demande de transmission #:jamais numéro d'une image #:jamais 5 Transmission d'une image u. : jamais image jamais 6 Reconnaissance d'un sur reconnaissance nom humain toujours 7 Emettre un son # :jamais numéro # :toujours 8 Transmission d'un son possible son toujours 9 Extinction carte plus de batterie/défaut identifiant raison jamais 10 Demande d'identification #:jamais des cartes présentes #:toujours 11 Déclaration de sa présence #:sur demande (10) identifiant fonction et sa fonction #:jamais TABLEAU 4 En-tête & données Fonctionnalité Carte de décision comportementale 0 Réservé t. : Jamais jamais 1 Arrêt d'urgence #:choix de s'arrêter d'urgence t : Toujours 2 Demande de déplacement # : choix d'avancer vitesse en avant jamais 3 Demande de déplacement # : choix de reculer vitesse en arrière jamais 4 Demande de transmission # :demande numéro d'une image toujours 5 Transmission d'une image choix de s'arrêter d'urgence image toujours 6 Reconnaissance d'un : jamais nom humain toujours 7 Emettre un son choix d'émettre un son numéro jamais 8 Transmission d'un son # :demande son toujours 9 Extinction carte plus de batterie/défaut identifiant raison toujours 10 Demande d'identification #:demande des cartes présentes toujours 11 Déclaration de sa présence # :jamais identifiant fonction et sa fonction # :toujours ,------------------------ : Ll : aptitude de la carte à écrire l'en-tête sur le bus a ! 11 : aptitude de la carte à charger l'en-tête présente sur le bus ex en 1 : mémoire FIFO (validité de l'en-tête). 1 r Dans cette application, au moins deux unités de traitement (cartes filles) sont configurées avec un même en-tête, c'est-à-dire comportent dans leur table des fonctionnalités à une même valeur d'en-tête (voir ci-après la fonctionnalité arrêt d'urgence / carte propulsion, carte sonore et carte de décision comportementale configurées avec la même valeur d'en-tête '1'). Egalement, dans cette application, au moins une unité de traitement est conçue pour exécuter plusieurs tâches, et est configurée de telle sorte que chaque tâche est associée à un en-tête différent. Par exemple, la carte propulsion comporte dans sa table des fonctionnalités les valeurs d'en-tête'1','2','3','6'et'10'associées respectivement aux fonctionnalités suivantes : arrêt d'urgence , demande de déplacement en avant , demande de déplacement en arrière , reconnaissance d'un humain > demande d'identification des cartes présentes . Afin de mieux comprendre les tableaux ci-dessus, la fonctionnalité arrêt d'urgence va être plus particulièrement commentée. Fonctionnalité arrêt d'urgence L'en-tête de va) eur'1'codant ! a fonctionnaiité arrêt d'urgence est toujours valide pour la carte propulsion, la carte sonore, et la carte de décision comportementale. La carte propulsion comporte dans sa table des fonctionnalités cette valeur d'en-tête associée à la fonctionnalité arrêt d'urgence , et la routine (tâche) associée est l'arrêt du moteur de déplacement du robot. La carte sonore comporte dans sa table des fonctionnalités cette valeur d'en-tête'l'associée à la fonctionnalité arrêt d'urgence , et la routine associée est l'émission d'un son d'alerte par la carte. La carte de décision comportementale comporte dans sa table des fonctionnalités cette valeur d'en-tête associée à la fonctionnalité arrêt d'urgence , et la routine associée est de mémoriser et dater l'événement tout en vérifiant : que l'arrêt d'urgence à bien eu lieu en vérifiant que la caméra observe une r image fixe. Lorsque l'en-tête de valeur'1'transite sur le bus a, les routines (tâches) de chacune de ces cartes correspondant à cette fonctionnalité sont activées en parallèle. A l'inverse, l'en-tête de va ! eur'1'codant ta fonctionna ! ité arrêt d'urgence zu n'est jamais valide pour la carte caméra. Lorsque cet en-tête est présent sur le bus ex, le message correspondant est ignoré par la carte caméra qui continue a fonctionner normalement. L'activation de la fonctionnalité arrêt d'urgence par écriture de la valeur d'en-tête'1'sur le bus a peut être réalisée à l'initiative soit de la carte propulsion (en cas de surchauffe moteur détectée par cette carte), soit de la carte caméra (en cas de détection d'une obstacle par cette carte), soit de la carte de décision comportementale. Cette fonctionnalité arrêt d'urgence n'est jamais déclenchée à l'initiative de la carte sonore. Les tableaux ci-dessus permettent à l'homme du métier de définir, pour chaque carte, sa table des fonctionnalités, ainsi que le contenu de sa mémoire de validation 3 qui assure le décodage des en-têtes. Dans la variante la variante de réalisation particulière de la figure 1, une unité de traitement est conçue pour, après reconnaissance d'un en-tête valide, charger en mémoire FIFO 4 le message transitant sur le bus a, et ce préalablement à l'exécution de la tâche associée à l'entête du message. Dans une variante de réalisation plus simple, il est toutefois envisageable de concevoir une unité de traitement qui exécute une tâche associée à un en-tête après reconnaissance de cet en-tête sur le bus a, sans chargement préalable du message en mémoire locale. Dans ce cas, l'unité de traitement ne comportera pas nécessairement de mémoire FIFO 4. Egalement, dans une autre variante, la mémoire de validation 3 pourrait être remplacée par tout autre moyen de décodage des en-têtes transitant sur le bus, et par exemple par une table de décodage réalisée en logique combinatoire. v------ 1 REVENDICATIONS 1 r 1. Architecture électronique parallèle comportant une pluralité d'unités de traitement (1a, 1b,... 1n) connectées à un bus de communication, chaque unité de traitement étant conçue pour exécuter automatiquement une ou plusieurs tâches prédéfinies, caractérisée en ce que chaque unité de traitement est configurée de telle sorte que chacune de ses tâches est associée à un en-tête, en ce que chaque unité de traitement est conçue pour communiquer avec les autres unités de traitement selon le protocole suivant : envoi sur le bus d'un message comportant au moins un en-tête caractérisant une fonctionnalité, et éventuellement une trame constituée d'un ou plusieurs mots, et en ce que chaque unité de traitement est conçue pour décoder chaque en-tête transitant sur le bus, et pour, en fonction de la valeur de cet en-tête, soit ignorer le message émis sur le bus, soit exécuter la tâche associée à l'en-tête de ce message. 2. Architecture selon la revendication 1 caractérisée en ce qu'au moins une unité de traitement est conçue pour charger en mémoire le message transitant sur le bus préalablement à l'exécution d'une tâche. 3. Architecture selon la revendication 1 ou 2 caractérisée en ce que qu'au moins deux unités de traitement sont configurées avec un même en- tête. 4. Architecture selon la revendication 1 ou 2 caractérisée en ce qu'au moins une unité de traitement est conçue pour exécuter plusieurs tâches, et est configurée de telle sorte que chaque tâche est associée à un en-tête différent. 5. Architecture selon l'une des revendications 1 à 4 caractérisée en ce que le bus de communication est un bus de données composé de (q) conducteurs parallèles (q entier supérieur ou égal à 1), en ce que chaque unité de traitement comporte un bus (6) de données (n) bits [ (n entier inférieur ou égal à q)] qui est connecté en parallèle aux (n) r premiers conducteurs du bus de communication. 6. Architecture selon la revendication 5 caractérisée en ce qu'au moins une unité de traitement est conçue pour émettre sur le bus un message selon le format série suivant : écriture sur le bus d'un premier mot correspondant à l'en-tête, puis écriture successivement de chaque mot constituant la trame du message. 7. Architecture selon l'une des revendications 1 à 6 caractérisé en ce qu'au moins une unité de traitement comporte : un processeur (2) programmé pour exécuter une ou plusieurs tâche distinctes, des moyens de décodage conçus pour valider ou non pour le processeur (2) un en-tête transitant sur le bus de communication, une mémoire (4) connectée au bus de communication, accessible en lecture par le processeur (2), et permettant sous la commande du processeur (2) le chargement d'un message transitant sur le bus de communication. 8. Architecture selon la revendication 7 caractérisée en ce que les moyens de décodage comportent une mémoire de validation (3) dont le port d'adresse est connecté au bus de communication, en ce que chaque valeur d'en-tête pouvant transiter sur le bus de communication correspond à une adresse de cette mémoire de validation (3), et en ce qu'à chaque adresse de cette mémoire de validation correspondant à un en-tête est stockée une donnée de validation ou de non validation de l'en-tête. 9. Architecture selon la revendication 8 caractérisée en ce que le port de sortie de la mémoire de validation (3) est connecté à un port du processeur (2) dédié au traitement des interruptions. 10. Architecture selon l'une quelconque des revendication 1 à 9 caractérisée en ce qu'elle est de type multi-maîtres/multi-esclaves, et en ce que l'échange de données sur le bus de communication est cadencé par l'unité de traitement maître qui a émis le message.