FR3090924A1 - Échange de données dans un ordinateur - Google Patents

Abstract

ÉCHANGE DE DONNÉES DANS UN ORDINATEUR Un ordinateur déterministe dans le temps a une architecture telle que du code d’échange compilé pour un ensemble donné de pavés peut être réutilisé pour d’autres ensembles. L’ordinateur comprend une pluralité d’unités de traitement connectées par l’intermédiaire d’un tissu de commutation. Les unités de traitement sont agencées en colonnes, chaque colonne comportant de multiples unités de traitement adjacentes les unes aux autres dans des positions respectives dans la direction de la colonne. Une unité de traitement est agencée pour émettre un paquet de données sur son ensemble de fils de connexion de sortie sans identifiant de destination. Le paquet de données arrive au niveau du destinataire avec un délai prédéterminé qui dépend d’un chemin d’échange entre les unités de traitement émettrice et destinataire. Le chemin d’échange entre toute paire d’unités de traitement émettrice et destinataire à des positions respectives dans une colonne donnée a le même délai que le chemin échange entre chaque paire d’unités de traitement émettrice et destinataire à des positions respectives correspondantes dans d’autres colonnes. Figure pour l’abrégé : Fig. 1

Description

Description

Titre de l’invention : ÉCHANGE DE DONNÉES DANS UN ORDINATEUR

Domaine technique

[0001] La présente description concerne des échanges de données dans un ordinateur. En particulier, la description concerne un ordinateur comportant de multiples unités de traitement, dans lequel des données sont échangées entre les unités de traitement par l’intermédiaire de chemins d’échange entre des unités de traitement émettrices et destinataires. En particulier, mais de manière non exclusive, la description concerne un ordinateur qui utilise un protocole informatique parallèle synchrone massif (BSP) dans lequel chaque groupe d’unités de traitement doit achever une phase de calcul avant que toute autre unité de traitement du groupe puisse procéder à une phase d’échange, phase dans laquelle des données sont échangées sur les chemins d’échange.

Technique antérieure

[0002] Le parallélisme en informatique prend différentes formes. Des fragments de programme peuvent être organisés pour s’exécuter simultanément (cas dans lequel ils se chevauchent dans le temps mais peuvent partager des ressources d’exécution), ou en parallèle, cas dans lequel ils s’exécutent sur des ressources différentes éventuellement en même temps.

[0003] Le parallélisme en informatique peut être obtenu d’un certain nombre de manières, comme au moyen d’une matrice de multiples pavés processeurs interconnectés, ou d’une unité de traitement à fils d’exécution multiples, ou même d’une matrice multipavé dans laquelle chaque pavé comprend une unité de traitement à fils d’exécution multiples.

[0004] Lorsque le parallélisme est obtenu au moyen d’un processeur comprenant une matrice de multiples pavés sur la même puce (ou des puces dans le même boîtier de circuit intégré), chaque pavé comprend sa propre unité de traitement respective séparée munie d’une mémoire locale (comprenant une mémoire de programme et une mémoire de données). Ainsi des portions séparées de code de programme peuvent être exécutées simultanément sur des pavés différents. Les pavés sont connectés entre eux par l’intermédiaire d’une interconnexion sur la puce qui permet au code exécuté sur les différents pavés de communiquer entre les pavés. Dans certains cas l’unité de traitement sur chaque pavé peut prendre la forme d’une unité de traitement à fils en barillet (ou d’une autre unité de traitement multi-fil). Chaque pavé peut comporter un ensemble de contextes et un pipeline d’exécution de sorte que chaque pavé peut exécuter de multiple fils entrelacés simultanément.

[0005] En général, il peut y avoir des dépendances entre les portions d’un programme s’exécutant sur différents pavés dans la matrice. Une technique est par conséquent nécessaire pour empêcher qu’un morceau de code sur un pavé s’exécute en avance sur des données dont il dépend qui sont mise à disposition par un autre morceau de code sur un autre pavé. Il existe un certain nombre de schémas possibles pour obtenir cela, mais le schéma qui nous intéresse ici est connu sous le nom de parallèle synchrone massif (BSP). Selon le schéma BSP, chaque pavé réalise une phase de calcul et une phase d’échange de manière alternée. Pendant la phase de calcul chaque pavé effectue une ou plusieurs tâches de calcul localement sur le pavé, mais ne communique aucun résultat de ses calculs à aucun autre des pavés. Dans la phase d’échange chaque pavé est autorisé à échanger un ou plusieurs résultats des calculs provenant de la phase de calcul précédente vers et/ou à partir d’un ou plusieurs autres des pavés du groupe, mais ne commence pas de nouvelle phase de calcul avant que le pavé ait terminé sa phase d’échange. En outre, selon cette forme de principe BSP, une synchronisation à barrière est placée à la jointure faisant la transition entre la phase de calcul et la phase d’échange, ou la transition entre les phases d’échange et la phase de calcul, ou les deux. C’est-à-dire que soit : (a) tous les pavés doivent achever leurs phases de calcul respectives avant que l’un quelconque du groupe soit autorisé à procéder à la phase d’échange suivante, soit (b) tous les pavés du groupe doivent achever leurs phases d’échanges respectives avant qu’un pavé du groupe soit autorisé à procéder à la phase de calcul suivante, soit (c) les deux. Lorsqu’on utilise ici la phrase entre une phase de calcul et une phase d’échange on englobe toutes ces options.

[0006] Un exemple d’utilisation de traitement parallèle multi-fil et/ou multi-pavé peut être trouvé dans l’intelligence artificielle. Comme cela sera familier pour l’homme de l’art dans l’intelligence artificielle, les algorithmes d’intelligence artificielle sont capables de produire des modèles de connaissance et d’utiliser le modèle de connaissance pour exécuter des algorithmes d’apprentissage et d’inférence. Un modèle d’intelligence artificielle incorporant le modèle de connaissance et des algorithmes peut être représenté sous forme d’un graphe de multiples nœuds interconnectés. Chaque nœud représente une fonction de ses entrées. Certains nœuds reçoivent les entrées du graphe et certains nœuds reçoivent des entrées provenant d’un ou plusieurs autres nœuds. L’activation de la sortie de certains nœuds forme les entrées d’autres nœuds, et la sortie de certains nœuds fournit la sortie du graphe, et les entrées du graphe fournissent les entrées à certains nœuds. En outre, la fonction se trouvant au niveau de chaque nœud est paramétrée par un ou plusieurs paramètres respectifs, par exemple des poids. Pendant une phase d’apprentissage le but est, sur la base d’un ensemble de données d’entrée expérimentales, de trouver des valeurs pour les divers paramètres de telle sorte que le graphe dans son ensemble génère une sortie souhaitée pour une plage d’entrées possible.

Divers algorithmes pour réaliser cela sont connus dans la technique, comme un algorithme à rétro-propagation basé sur une descente de gradient stochastique. Sur de multiples itérations les paramètres sont progressivement ajustés pour diminuer leurs erreurs, et ainsi le graphe converge vers une solution. Dans un étage suivant, le modèle appris peut alors être utilisé pour faire des prédictions de sorties étant donné un ensemble spécifié d’entrées ou pour faire des inférences en ce qui concerne des entrées (causes) étant donné un ensemble spécifié de sorties, ou d’autres formes introspectives d’analyse peuvent être réalisées sur celui-ci.

[0007] La mise en œuvre de chaque nœud va impliquer le traitement de données, et les interconnexions du graphe correspondent à des données à échanger entre les nœuds. Typiquement, au moins une partie du traitement de chaque nœud peut être réalisée indépendamment de certains ou de tous les autres nœuds du graphe, et par conséquent de grands graphes présentent des opportunités pour un parallélisme massif.

Résumé de l’invention

[0008] Une machine parallèle fortement répartie est une structure de machine appropriée pour des calculs de tels modèles d’intelligence artificielle.

[0009] Un facteur de modèles de connaissance qui est exploité dans la présente description est la nature généralement statique du graphe. C’est-à-dire que la structure des nœuds et du graphe comprenant les nœuds ne change pas habituellement pendant l’exécution d’algorithmes d’intelligence artificielle. Les inventeurs ont réalisé une machine qui donne certaines garanties de déterminisme temporel pour optimiser les calculs sur des modèles d’intelligence artificielle. Cela permet à un compilateur de partitionner et de planifier le travail dans l’ensemble des nœuds de manière déterministe dans le temps. C’est ce déterminisme temporel qui est utilisé dans les modes de réalisation décrits dans la suite pour des optimisations significatives dans l’utilisation du code dans un ordinateur optimisé pour traiter des charges de travail sur la base de modèles de connaissance.

[0010] Un aspect de la présente description prévoit un ordinateur comprenant : une pluralité d’unités de traitement ayant chacune une interface d’entrée munie d’un ensemble de fils d’entrée, et une interface de sortie munie d’un ensemble de fils de sortie ; un tissu de commutation connecté à chacune des unité de traitement par l’ensemble respectif de fils de sortie et connectable à chacune des unités de traitement par l’ensemble respectif de fils de sortie et connectable à chacune des unité de traitement par les fils d’entrée respectifs par l’intermédiaire de circuits de commutation contrôlables par son unité de traitement associée ; les unités de traitement étant agencées en colonnes, chaque colonne ayant une unité de traitement de base à proximité du tissu de commutation et de multiples unité de traitement adjacentes les unes aux autres dans des positions res pectives dans la direction de la colonne, dans lequel pour mettre en œuvre un échange de données entre les unités de traitement au moins une unité de traitement est agencée pour émettre à un instant d’émission un paquet de données destiné à une unité de traitement destinataire sur son ensemble de fils de connexion de sortie, le paquet de données n’ayant aucun identifiant de destination de l’unité de traitement destinataire mais étant destiné à être reçu au niveau de l’unité de traitement destinataire avec un délai prédéterminé par rapport à l’instant d’émission, dans lequel le délai prédéterminé dépend d’un chemin d’échange entre les unités de traitement émettrice et destinataire, dans lequel le chemin d’échange entre une paire quelconque d’unités de traitement émettrice et destinataire se trouvant à des positions respectives dans une colonne donnée a le même délai que le chemin d’échange entre chaque paire d’unités de traitement émettrice et destinataire se trouvant à des positions respectives correspondantes dans les autres colonnes.

[0011] Le chemin d’échange physique peut inclure une composante de chemin qui s’étend à partir d’une unité de traitement respective dans la colonne jusqu’à la base de la colonne.

[0012] Le tissu de commutation peut comprendre une pluralité de groupes de fils d’échange, chaque groupe ayant des fils connectés aux fils de sortie d’unités de traitement se trouvant dans chaque colonne respective.

[0013] Dans un mode de réalisation, une première des colonnes est éloignée de son groupe de fils respectif d’une première distance physique, et une deuxième des colonnes est éloignée de son groupe de fils correspondant d’une deuxième distance physique, la deuxième distance physique étant supérieure à la première distance physique. Un délai de compensation peut être prévu dans une composante de chemin entre colonne et tissu de commutation, entre la première colonne et le premier groupe de fils correspondant, d’où il résulte que le délai de chemin entre colonne et tissu de commutation de la première colonne est le même que le délai de chemin entre colonne et tissu de commutation de la deuxième colonne.

[0014] Le délai de compensation peut comprendre un circuit de retard de compensation de sortie agencé dans l’ensemble de fils de connexion de sortie de chaque unité de traitement se trouvant dans la première colonne.

[0015] Le délai de compensation peut additionnellement ou en variante comprendre un circuit de retard de compensation d’entrée agencé dans l’ensemble de fils d’entrée pour chaque pavé se trouvant dans la première colonne.

[0016] L’ordinateur peut en outre comprendre un délai de compensation de commutation dans un ensemble de fils de commande de commutation qui s’étend à partir de chaque unité de traitement jusqu’à son circuit de commutation correspondant, la compensation de délai de commutation étant déterminée de telle sorte que la somme du circuit de compensation de délai d’entrée et de la compensation de délai de commande de commutation soit la même pour chaque colonne.

[0017] Dans certains modes de réalisation, le tissu de commutation s’étend dans une première direction, et chaque colonne s’étend dans une deuxième direction perpendiculaire à la première direction.

[0018] L’ordinateur peut comprendre n colonnes situées sur un côté du tissu de commutation et n colonnes situées sur l’autre côté du tissu de commutation et s’étendant en s’écartant du tissu de commutation dans une direction inverse. Dans une architecture n est égal à 8.

[0019] Chacune des n colonnes situées sur le premier côté du tissu de commutation peut être associée à des groupes respectifs de fils dans une première moitié du tissu de commutation, et chacune des n colonnes situées sur l’autre côté du tissu de commutation peut être associée à des groupes de fils respectifs dans l’autre moitié du tissu de commutation.

[0020] Le chemin d’échange peut comprendre une composante de chemin entre base de colonne et pavé, basée sur la distance le long de la colonne de l’unité de traitement respective à partir de l’unité de traitement de base.

[0021] Chaque unité de traitement peut être agencée pour comporter un stockage d’instructions contenant un programme local comprenant du code d’échange, une unité d’exécution agencée pour exécuter le programme local et un stockage de données pour contenir des données, le code d’échange d’une unité de traitement à une première position dans l’une des colonnes étant le même que le code d’échange d’une unité de traitement dans la même position respective d’une autre colonne.

[0022] Dans certains modes de réalisation, le code d’échange comprend une instruction SEND qui provoque l’émission du paquet de données à l’instant d’émission vers une unité de traitement destinataire dans la même colonne.

[0023] L’ordinateur peut comprendre un module de synchronisation actionnable pour générer un signal de synchronisation pour contrôler l’ordinateur pour commuter entre une phase de calcul et une phase d’échange, dans lequel les unités de traitement sont agencées pour exécuter leur programmes locaux en accord avec une horloge commune, les programmes locaux étant tels que ladite au moins une unité de traitement est agencée pour émettre le paquet de données dans la phase d’échange.

[0024] Le signal de synchronisation peut être reçu au niveau de chaque colonne par l’intermédiaire d’un étage de retard de synchronisation respectif de telle sorte que le signal de synchronisation soit reçu au niveau de chaque unité de traitement dans l’ordinateur en même temps. Cela peut être utile lors de la relocalisation de code d’échange généré pour n groupes de colonnes vers un autre groupe similaire ayant le pôle opposé (nord ou sud). Une variante d’approche pour obtenir un retard dans le signal de synchronisation consiste à ajouter des instructions de retard juste avant le code d’échange.

[0025] En s’assurant que le chemin d’échange a la même latence pour des unités de traitement positionnées respectivement dans n’importe quelle colonne, le même code d’échange peut être utilisé pour des échanges intra-colonnes similaires dans une colonne quelconque. Dans ce contexte, le code d’échange comprend la séquence d’instructions qui provoque l’émission de données à partir d’une unité de traitement, et qui gère la réception de données au niveau d’une unité de traitement destinataire. Ces instructions comprennent une instruction SEND au niveau du pavé émetteur, et une instruction de commande pour le circuit de commutation au niveau du pavé destinataire. En plus, il peut y avoir une instruction de pointeur mémoire au niveau du pavé destinataire. Cette instruction de pointeur mémoire ne donne pas effectivement l’instruction d’un chargement en mémoire (qui survient sans instruction explicite), mais peut mettre en place l’adresse en mémoire à laquelle les données doivent être chargées à la réception.

[0026] En outre, une compensation de délai supplémentaire peut être introduite pour permettre au même code d’échange d’être utilisé pour certains échanges de données inter-colonnes. Il est possible de sélectionner un ensemble de compensations de délai pour les différentes composantes de chemin de telle sorte que certaines combinaisons de pavé d’envoi et de réception dans l’ordinateur présentent la même latence sur leurs chemins d’échange.

[0027] On notera la difficulté ici en ce que du code d’échange pour des pavés dans une colonne est compilé de manière à comprendre des latences entre le pavé émetteur et chaque pavé destinataire pour chaque message. Le même code peut seulement être utilisé dans d’autres échanges intra- ou inter-colonnes si les latences sont les mêmes pour des paires de pavés correspondantes. Dans ce contexte correspondante désigne des pavés disposés de manière correspondante dans d’autres colonnes.

[0028] Dans un autre agencement, un tissu de commutation s’étend à travers une puce dans laquelle l’ordinateur est incorporé, et un ensemble de colonnes est agencé côte à côte en s’étendant perpendiculairement à partir d’un côté du tissu de commutation, et un autre ensemble de colonnes est agencé côte à côte en s’étendant perpendiculairement (mais dans une direction inverse) par rapport à l’autre côté de la colonne. De cette manière, une matrice de colonnes est formée. Pour faciliter la référence, on désigne les colonnes situées sur un côté donné du tissu de commutation comme étant dans la partie nord de la matrice (les colonnes au nord), et les colonnes se trouvant de l’autre côté du tissu sont désignées comme étant dans la partie sud de la matrice (les colonnes au sud). Il est possible d’introduire une compensation de délai telle que des unités de traitement se trouvant dans des positions respectives dans certaines paires de colonnes sur l’une ou l’autre de la partie nord ou de la partie sud de la matrice peuvent utiliser le même code d’échange.

[0029] Dans un autre exemple, lorsqu’une unité de traitement émettrice est dans une colonne dans la partie nord de la matrice, et l’unité de traitement destinataire est dans une colonne dans la partie sud de la matrice (ou vice versa) certaines paires de colonnes peuvent partager le même code d’échange, grâce à l’utilisation de la compensation de délai.

Brève description des dessins

[0030] Pour faciliter la compréhension de la présente description et pour montrer comment celle-ci peut être mise en œuvre, on va faire maintenant référence à titre d’exemple aux dessins joints.

[0031] [fig-1] La figure 1 illustre schématiquement l’architecture d’un processeur en une seule puce ;

[0032] [fig.2] la figure 2 est un schéma blocs d’un pavé connecté au tissu de commutation ;

[0033] [fig.3] la figure 3 est un schéma illustrant un protocole BSP ;

[0034] [fig.4] la figure 4 est un schéma représentant deux pavés dans un échange déterministe dans le temps ;

[0035] [fig.5] la figure 5 est un chronogramme schématique illustrant un échange déterministe dans le temps ;

[0036] [fig.6] la figure 6 est un exemple de graphe d’intelligence artificielle;

[0037] [fig.7] la figure 7 est une architecture schématique illustrant le fonctionnement d’un compilateur pour générer des programmes déterministes dans le temps ;

[0038] [fig.8] les figures8,

[0039] [fig.9]9,

[0040] [fig.10] 10, et

[0041] [fig.ll] 11 illustrent des formats d’instructions de différentes instructions utilisables dans une architecture déterministe dans le temps ;

[0042] [fig. 12] la figure 12 illustre un exemple de champs de commande utilisables dans une instruction d’envoi ;

[0043] [fig. 13] la figure 13 illustre un exemple de communication entre deux pavés sur un tissu de commutation ;

[0044] [fig. 14] les figures 14 et

[0045] [fig. 15] 15 sont des représentations schématiques de l’architecture ;

[0046] [fig. 16] la figure 16 représente les bits dans un identifiant de pavé ;

[0047] [fig. 17] la figure 17 est une table représentant un exemple d’ensemble de délais de compensation ;

[0048] [fig. 18] la figure 18 est une table représentant un exemple de délai de pavé à pavé ;

[0049] [fig. 19] les figures 19 et 19A représentent des exemples de réutilisation du code d’échange ; et

[0050] [fig.20] les figures 20 et 20A représentent un autre exemple de réutilisation de code d’échange.

Description des modes de réalisation

[0051] La présente description expose un mécanisme de compensation de délai qui peut être utilisé pour permettre d’utiliser du code d’échange commun dans de multiples parties d’un processeur déterministe dans le temps.

[0052] La figure 1 illustre schématiquement l’architecture d’un processeur en une seule puce 2. Le processeur est appelé ici IPU (de l’anglais Intelligence Processing Unit - Unité de Traitement pour Intelligence) pour indiquer sa capacité d’adaptation à des applications d’intelligence artificielle. Dans un ordinateur, les processeurs en une seule puce peuvent être connectés entre eux, comme cela va être décrit dans la suite, en utilisant des liaisons sur la puce, pour former un ordinateur. La présente description se concentre sur l’architecture d’un processeur en une seule puce 2. Le processeur 2 comprend de multiples unités de traitement appelées pavés. Dans un mode de réalisation, il y a 1216 pavés organisés en matrices 6a, 6b, 6c, 6d. Le processeur peut être considéré comme ayant des régions Est et Ouest, et des régions Nord et Sud. 6a peut être appelée matrice Nord-Est, 6b peut être appelée matrice Sud-Est, 6c peut être appelée matrice Sud-Ouest, et 6d peut être appelée matrice Nord-Ouest. Dans l’exemple décrit, chaque matrice comporte quatre colonnes de 76 pavés (en fait il y aura en général 80 pavés, dans un but de redondance). On remarquera que les concepts décrits ici s’étendent à un certain nombre d’architectures physiques différentes, un exemple étant donné ici pour faciliter la compréhension. La puce 2 comporte deux liaisons de puce à hôte 8a, 8b et 4 liaisons de puce à puce 30a, 30b agencées sur le bord Ouest de la puce 2. La puce 2 reçoit du travail d’un hôte (non représenté) qui est connecté à la puce par l’intermédiaire de l’une des liaisons de carte à hôte sous la forme de données d’entrée à traiter par la puce 2. Les puces peuvent être connectées entre elles dans des cartes par 6 autres liaisons de puce à puce 30a, 30b agencées le long du côté Est de la puce. Un hôte peut accéder à un ordinateur qui est architecture sous forme d’un processeur en une seule puce 2 comme cela est décrit ici ou d’un groupe de multiples processeurs en une seule puce 2 interconnectés en fonction de la charge de travail fournie par l’application hôte.

[0053] La puce 2 comporte une horloge 3 qui contrôle l’activité temporelle de la puce. L’horloge est connectée à la totalité des circuits et composants de la puce. La puce 2 comprend un tissu de commutation déterministe dans le temps 34 auquel tous les pavés et toutes les liaisons sont connectés par des ensembles de fils de connexion, le tissu de commutation étant sans état, c’est-à-dire n’ayant aucun état de programme visible. Chaque ensemble de fils de connexion est fixe de bout en bout. Les fils sont en pipeline. Dans ce mode de réalisation, un ensemble comprend 32 fils de données plus des fils de contrôle, par exemple un bit de validité. Chaque ensemble peut transporter un paquet de données de 32 bits, mais on notera ici que le mot paquet désigne un ensemble de bits représentant une donnée (parfois appelée ici élément de données), peut-être avec un ou plusieurs bits de validité. Les paquets ne comportent pas d’en-têtes munis d’identifiants de destination qui permettent à un destinataire visé d’être identifié de manière unique, et ne comportent pas non plus d’informations de fin de paquet. A la place, chacun d’eux représente une valeur numérique ou logique qui est fournie en entrée ou obtenue en sortie d’un pavé. Toutefois, les paquets peuvent inclure des en-têtes indiquant au moins une direction de déplacement dans le tissu de commutation 34. Chaque pavé a sa propre mémoire locale (décrite dans la suite). Les pavés ne partagent pas de mémoire. Le tissu de commutation constitue un ensemble croisé de fils de connexion connectés seulement à des multiplexeurs et des pavés comme cela est décrit dans la suite et ne contient aucun état de programme visible. Le tissu de commutation est considéré comme étant sans état et n’utilise pas de mémoire. L’échange de données entre pavés est conduit de manière déterministe dans le temps comme cela est décrit ici. Un fil de connexion en pipeline comprend une série de stockages temporaires, par exemple des verrous ou des bascules qui maintiennent une donnée pendant un cycle d’horloge avant de la libérer vers le stockage suivant. Le temps de déplacement le long du fil est déterminé par ces stockages temporaires, chacun utilisant jusqu’à un temps de cycle d’horloge dans un chemin entre deux points quelconques.

[0054] Chaque colonne est associée à un groupe respectif de fils d’échange, comme cela sera décrit dans la suite. Des colonnes utilisant des groupes de fils physiquement plus proches d’elles ont des latences inférieures pour des échanges inter-colonnes qu’une colonne utilisant un groupe de fils qui est situé plus loin.

[0055] La figure 2 illustre un exemple de pavé 4 selon des modes de réalisation de la présente description. Dans le pavé, de multiples fils d’exécution sont entrelacés dans un seul pipeline d’exécution. Le pavé 4 comprend : une pluralité de contextes 26 dont chacun est agencé pour représenter l’état d’un fil respectif différent parmi une pluralité de fils ; une mémoire d’instructions partagée 12 commune à la pluralité de fils ; une mémoire de données partagée 22 qui est aussi commune à la pluralité de fils ; un pipeline d’exécution partagé 14, 16, 18 qui est de nouveau commun à la pluralité de fils ; et un ordonnanceur de fils 24 pour planifier la pluralité de fils pour leur exécution dans le pipeline partagé de manière entrelacée. L’ordonnanceur de fils 24 est schématiquement représenté dans le schéma par une séquence de créneaux temporels SO.. .S5, mais en pratique c’est un mécanisme matériel gérant des compteurs de programme des fils en relation avec leurs créneaux temporels. Le pipeline d’exécution comprend un étage d’extraction 14, un étage de décodage 16 et un étage d’exécution 18 comprenant une unité d’exécution (EXU) et une unité de chargement/stockage (LSU). Chacun des contextes 26 comprend un ensemble respectif de registres R_o, Ri... pour représenter l’état de programme du fil respectif.

[0056] L’étage d’extraction 14 est connecté de manière à extraire des instructions à exécuter à partir de la mémoire d’instructions 12, sous le contrôle de l’ordonnanceur de fils 24. L’ordonnanceur de fils 24 est agencé pour contrôler l’étage d’extraction 14 pour extraire des instructions du programme local pour exécution dans chaque créneau temporel comme on va le décrire plus en détail ci-après.

[0057] L’étage d’extraction 14 a accès à un compteur de programme (PC) de chacun des fils qui est actuellement alloué à un créneau temporel. Pour un fil donné, l’étage d’extraction 14 extrait l’instruction suivante de ce fil de l’adresse suivante dans la mémoire d’instructions 12, comme cela est indiqué par le compteur de programme du fil. On notera qu’en faisant référence à une instruction ici, on désigne une instruction de code machine, c’est-à-dire une instance de l’une des instructions fondamentales du jeu d’instructions de l’ordinateur, constituée d’un code opération et de zéro, ou plus, opérandes. On notera aussi que le programme chargé dans chaque pavé est déterminé par un processeur ou un compilateur pour allouer du travail sur la base du graphe du modèle d’intelligence artificielle qui est supporté.

[0058] L’étage d’extraction 14 passe ensuite l’instruction extraite à l’étage de décodage 16 pour la décoder, et l’étage de décodage 16 passe ensuite une indication de l’instruction décodée à l’étage d’exécution 18 accompagnée des adresses décodées des éventuels registres d’opérandes du contexte courant spécifiés dans l’instruction, afin que l’instruction soit exécutée.

[0059] Dans cet exemple, l’ordonnanceur de fils 24 entrelace des fils selon un schéma de tour de rôle dans lequel, dans chaque tour du schéma, le tour est divisé en une séquence de créneaux temporels S_o, Si, S₂, S₃, chacun étant destiné à exécuter un fil respectif. Typiquement chaque créneau a une longueur d’un cycle de processeur et les différents créneaux ont des dimensions égales (bien que ce ne soit pas nécessairement le cas dans tous les modes de réalisation possibles). Ce motif se répète ensuite, chaque tour comprenant une instance respective de chacun des créneaux temporels (dans des modes de réalisation dans le même ordre à chaque fois, bien qu’ici encore cela ne soit pas nécessaire dans tous les modes de réalisation possibles). On notera par conséquent qu’un créneau temporel tel que désigné ici désigne la place allouée de façon répétitive dans la séquence, pas une instance particulière du créneau temporel dans une répétition donnée de la séquence. Dans le mode de réalisation illustré, il y a huit créneaux, mais d’autres nombres sont possibles. Chaque créneau temporel est associé à une ressource matérielle, par exemple un registre, pour gérer le contexte d’un fil d’exécution.

[0060] L’un des contextes 26, noté SV, est réservé à une fonction spéciale, pour représenter l’état d’un superviseur (SV) dont le travail est de coordonner l’exécution de fils de travail. Le superviseur peut être mis en œuvre sous forme d’un programme organisé sous forme d’un ou plusieurs fils superviseurs qui peuvent s’exécuter simultanément. Le fil superviseur peut aussi être responsable de la réalisation de synchronisations à barrière décrites dans la suite ou peut être responsable d’un échange de données sur le pavé et hors du pavé, aussi bien que dans et hors de la mémoire locale afin qu’elles puissent être partagées entre les fils de travail entre des calculs. Le fil superviseur met en œuvre du code d’échange, qui est constitué des instructions impliquées dans l’échange de données dans et hors du pavé. L’ordonnanceur de fils 24 est agencé de telle sorte que, lorsque le programme dans son ensemble démarre, il commence par allouer le fil superviseur à tous les créneaux temporels, c’est-à-dire qu’ainsi le superviseur SV démarre en s’exécutant dans tous les créneaux temporels S₀...S₅. Cependant, le fil superviseur est muni d’un mécanisme pour, à un certain point ultérieur (soit immédiatement soit après avoir réalisé une ou plusieurs tâches de supervision), abandonner temporairement chacun des créneaux dans lesquels il s’exécute à l’un respectif des fils de travail. C_o, Ci représentent des créneaux dans lesquels des fils de travail ont été alloués. Cela est obtenu par le fait que le fil superviseur exécute une instruction d’abandon, appelée RUN à titre d’exemple ici. Dans des modes de réalisation, cette instruction prend deux opérandes : une adresse d’un fil de travail dans la mémoire d’instructions 12 et une adresse de certaines données pour ce fil de travail dans la mémoire de données 22 :

[0061] RUN task_addr, data_addr

[0062] Chaque fil de travail est un codelet destiné à représenter un sommet dans le graphe et à s’exécuter de façon atomique. C’est-à-dire que toutes les données qu’il consomme sont disponibles au lancement et toutes les données qu’il produit ne sont pas visibles par d’autres fils avant qu’il sorte. Il s’exécute jusqu’à son achèvement (excepté dans des conditions d’erreur). L’adresse de données peut spécifier certaines données sur lesquelles le codelet doit agir. En variante, l’instruction d’abandon peut prendre un seul opérande spécifiant l’adresse du codelet, et l’adresse de données pourrait être incluse dans le code du codelet ; ou l’unique opérande pourrait pointer vers une structure de données spécifiant l’adresse du codelet et des données. Les codelets peuvent être exécutés simultanément et indépendamment les uns des autres.

[0063] Dans tous les cas, l’instruction d’abandon (RUN) agit sur l’ordonnanceur de fils 24 de manière à abandonner le créneau temporel courant, c’est-à-dire le créneau temporel dans lequel cette instruction est exécutée, au fil de travail spécifié par l’opérande. On notera qu’il est implicite dans l’instruction d’abandon que c’est le créneau temporel dans lequel cette instruction est exécutée qui est abandonné (implicite dans le contexte d’instructions de code machine signifie qu’il n’y a pas besoin d’un opérande pour spécifier cela - c’est implicite à partir du code opération lui-même). Ainsi le créneau qui est abandonné est le créneau dans lequel le superviseur exécute l’instruction d’abandon. Dit d’une autre manière, le superviseur s’exécute dans le même espace que celui qu’il abandonne. Le superviseur dit exécuter ce codelet dans ce créneau temporel, puis à partir de ce point le créneau est la propriété (temporairement) du fil de travail concerné. On notera que lorsqu’un superviseur utilise un créneau, il n’utilise pas le contexte associé à ce créneau mais utilise son propre contexte SV.

[0064] Le fil superviseur SV réalise une opération similaire dans chacun des créneaux temporels, pour abandonner tous ses créneaux C_o, Ci à différents fils respectifs parmi les fils de travail. Une fois qu’il a effectué cela pour le dernier créneau, le superviseur met son exécution en pause, puisqu’il n’a pas de créneaux dans lesquels s’exécuter. On notera que le superviseur peut ne pas abandonner tous ses créneaux, il peut retenir certains créneaux pour s’exécuter lui-même.

[0065] Lorsque le fil superviseur détermine qu’il est temps d’exécuter un codelet, il utilise l’instruction d’abandon (RUN) pour allouer ce codelet au créneau dans lequel il exécute l’instruction RUN.

[0066] Chacun des fils de travail dans les créneaux C_o, Ci procède à la réalisation de sa ou de ses tâches de calcul. A la fin de sa ou de ses taches, le fil de travail rend le créneau temporel dans lequel il s’exécute au fil superviseur.

[0067] Cela est obtenu par le fil de travail en exécutant une instruction de sortie (EXIT). Dans un mode de réalisation, l’instruction EXIT prend au moins un opérande et de préférence un seul opérande, exit_state (par exemple une valeur binaire), à utiliser dans tout but souhaité par le programmeur pour indiquer un état du codelet respectif lors de sa terminaison.

[0068] EXIT exit_state

[0069] Dans un mode de réalisation, l’instruction EXIT agit sur l’ordonnanceur 24 afin que le créneau temporel dans lequel elle est exécutée soit rendu au fil superviseur. Le fil superviseur peut alors réaliser une ou plusieurs tâches de superviseur suivantes (par exemple une barrière de synchronisation et/un mouvement de données en mémoire pour faciliter l’échange de données entre des fils de travail), et/ou continuer à exécuter une autre instruction d’abandon pour allouer un nouveau fil de travail (W4, etc.) au créneau en question. On notera encore que par conséquent le nombre total de fils d’exécution dans la mémoire d’instructions 12 peut être supérieur au nombre que l’unité de traitement à fils en barillet 10 peut entrelacer à un instant donné. C’est le rôle du fil superviseur SV de planifier lesquels des fils de travail W0.. .Wj provenant de la mémoire d’instructions 12, à quelle étape dans le programme global, doivent être exécutés.

[0070] Dans un autre mode de réalisation, l’instruction EXIT n’a pas besoin de définir un état de sortie.

[0071] Cette instruction agit sur l’ordonnanceur de fils 24 afin que le créneau temporel dans lequel elle est exécutée soit rendu au fil superviseur. Le fil superviseur peut alors réaliser une ou plusieurs tâches suivantes de superviseur (par exemple une synchronisation à barrière et/ou un échange de données), et/ou continuer à exécuter une autre instruction d’abandon, et ainsi de suite.

[0072] Comme cela a été brièvement mentionné précédemment, des données sont échangées entre des pavés dans la puce. Chaque puce opère un protocole Parallèle Synchrone Massif, comprenant une phase de calcul et une phase d’échange. Le protocole est illustré par exemple en figure 3. Le schéma du côté gauche en figure 3 représente une phase de calcul dans laquelle chaque pavé 4 est dans une phase où les codelets dynamiques s’exécutent sur la mémoire locale (12, 22). Bien qu’en figure 3 les pavés 4 soient représentés agencés en cercle, cela est fait seulement dans un but d’explication et ne reflète pas l’architecture effective.

[0073] Après la phase de calcul, il y a une synchronisation indiquée par une flèche 30. Pour réaliser cela, une instruction SYNC (synchronisation) est prévue dans le jeu d’instructions du processeur. L’instruction SYNC a pour effet d’amener le fil superviseur SV à attendre que tous les fils de travail en cours d’exécution W soient sortis au moyen d’une instruction EXIT. Dans des modes de réalisation, l’instruction SYNC prend un mode comme opérande (dans des modes de réalisation c’est seulement l’opérande), le mode spécifiant si l’instruction SYNC doit agir seulement localement en relation avec seulement les fils de travail s’exécutant localement sur le même module processeur 4, par exemple le même pavé, ou si au lieu de cela elle doit s’appliquer dans de multiples pavés ou même dans de multiples puces.

[0074] SYNC mode // mode e {tile, chip, zone_l, zone_2}.

[0075] Le schéma BSP en lui-même est connu dans la technique. Selon le schéma BSP, chaque pavé 4 réalise une phase de calcul 52 et une phase d’échange 50 (parfois appelée communication ou passage de messages) dans un cycle alternatif. La phase de calcul et la phase d’échange sont réalisées par des exécutions d’instructions sur le pavé. Pendant la phase de calcul 52 chaque pavé 4 réalise une ou plusieurs tâches de calcul localement sur un pavé, mais ne communique pas de résultats de ces calculs avec d’autres pavés 4. Dans la phase d’échange 50, chaque pavé 4 est autorisé à échanger (communiquer) un ou plusieurs résultats des calculs provenant de la phase de calcul précédente vers et/ou à partir d’un ou plusieurs autres des pavés du groupe, mais ne réalise pas encore de nouveaux calculs qui potentiellement peuvent dépendre d’une tâche réalisée sur un autre pavé 4, ou desquels une tâche sur un autre pavé 4 pourrait potentiellement dépendre (il n’est pas exclu que d’autres opérations comme des opérations associées au contrôle interne puissent être réalisées dans la phase d’échange). En outre, selon le principe BSP, une synchronisation à barrière est placée à la jointure faisant la transition des phases de calcul 52 à la phase d’échange 50, ou à la jointure faisant la transition des phases d’échange 50 à la phase de calcul 52, ou les 2. C’est-à-dire que : soit (a) tous les pavés 4 doivent achever leurs phases de calcul respectives 52 avant que l’un quelconque des pavés du groupe soit autorisé à procéder à la phase d’échange 50 suivante, soit (b) tous les pavés 4 du groupe doivent achever leurs phases d’échange respectives 50 avant que l’un quelconque des pavés du groupe soit autorisé à procéder à la phase de calcul 52 suivante, soit (c) ces deux conditions sont imposées. Cette séquence de phases d’échange et de phases de calcul peut ensuite se répéter dans de multiples répétitions. Dans la terminologie BSP, chaque répétition de phase d’échange et de phase de calcul est appelée ici super-étape, ce qui est cohérent avec l’utilisation de certaines descriptions précédentes du BSP. On notera ici que le terme super-étape est parfois utilisé dans la technique pour désigner chacune de la phase d’échange et de la phase de calcul.

[0076] L’unité d’exécution (EXU) de l’étage d’exécution 18 est agencée de telle sorte que, en réponse au code opération de l’instruction de synchronisation SYNC, lorsqu’elle est qualifiée par un opérande sur la puce (inter-pavé), elle amène le fil superviseur dans lequel le SYNC chip a été exécuté à être mis en pause jusqu’à ce que tous les pavés 4 de la matrice 6 aient terminé d’exécuter les fils de travail. Cela peut être utilisé pour mettre en œuvre une barrière vers la super-étape BSP suivante, c’est-à-dire qu’après que tous les pavés 4 sur la puce 2 ont passé la barrière, le programme entre pavés dans son ensemble peut progresser vers la phase d’échange 50 suivante.

[0077] Chaque pavé indique son état de synchronisation à un module de synchronisation 36. Une fois qu’il a été établi que chaque pavé est prêt à envoyer des données, le processus de synchronisation 30 amène le système à rentrer dans une phase d’échange qui est représentée sur le côté droit de la figure 3. Dans cette phase d’échange, des valeurs de données se déplacent entre les pavés (en fait entre les mémoires des pavés dans un mouvement de données de mémoire à mémoire). Dans la phase d’échange, il n’y a pas de calculs qui puissent induire des risques de simultanéité entre des programmes de pavés. Dans la phase d’échange, chaque donnée se déplace le long de fils de connexion sur lesquels elle sort d’un pavé à partir d’un pavé émetteur vers un ou plusieurs pavés destinataires. A chaque cycle d’horloge, une donnée se déplace d’une certaine distance sur son chemin (de stockage à stockage), en pipeline. Lorsqu’une donnée est émise à partir d’un pavé, elle n’est pas émise avec un en-tête identifiant un pavé destinataire (bien que la donnée puisse inclure un en-tête indiquant au moins une direction de dé15 placement à travers le tissu de commutation 34). Au lieu de cela, le pavé destinataire sait qu’il va attendre une donnée provenant d’un certain pavé émetteur à un certain instant. Ainsi, l’ordinateur décrit ici est déterministe dans le temps. Chaque pavé actionne un programme qui lui a été alloué par le programmeur ou par un exercice de compilateur, le programmeur ou la fonction de compilateur ayant connaissance de ce qui va être émis par un pavé particulier à un certain instant et de ce qui doit être reçu par un pavé destinataire à un certain instant. Afin d’obtenir cela, des instructions SEND sont incluses dans les programmes locaux exécutés par le processeur sur chaque pavé, le temps d’exécution de l’instruction SEND étant prédéterminé par rapport à la position temporelle d’autres instructions qui sont exécutées sur d’autres pavés dans l’ordinateur. Cela sera décrit plus en détail dans la suite, mais premièrement on va décrire le mécanisme par lequel un pavé destinataire peut recevoir une donnée à un instant prédéterminé. Chaque pavé 4 est associé à son propre multiplexeur 210 et ainsi la puce comporte 1216 multiplexeurs. Chaque multiplexeur comporte 1216 entrées, chacune ayant une largeur de 32 bits (plus optionnellement certains bits de commande). Chaque entrée est connectée à un ensemble respectif de fils de connexion 140_x dans le tissu de commutation 34. Les fils de connexion du tissu de commutation sont aussi connectés à un ensemble de fils de connexion 218 de sortie de données provenant de chaque pavé (un bus d’échange à diffusion, décrit dans la suite), et ainsi il y a 1216 ensembles de fils de connexion qui dans ce mode de réalisation s’étendent dans une direction à travers la puce. Pour faciliter l’illustration, un seul ensemble de fils 140_sc en trait gras est représenté connecté aux fils de sortie de données 218_S, provenant d’un pavé non représenté en figure 2, dans la matrice sud 6b. Cet ensemble de fils est noté 140_x pour indiquer qu’il s’agit de l’un d’un certain nombre d’ensembles de fils croisés 14O_o- 140i₂i₅. Comme on peut maintenant le voir dans la figure 2, on notera que lorsque le multiplexeur 210 est commuté sur l’entrée notée 220_x, alors cela va la connecter aux fils croisés 140_x et ainsi aux fils de données de sortie 218_S du pavé (non représenté en figure 2) à partir du pavé sud 6b. Si le multiplexeur est contrôlé de manière à commuter sur cette entrée (220_sc) à un certain instant, alors la donnée reçue sur les fils de sortie de données qui sont connectés à l’ensemble de fils de connexion 140_x va apparaître au niveau de la sortie 230 du multiplexeur 210 à un certain instant. Elle va arriver au niveau du pavé 4 avec un certain délai par rapport à cela, le délai dépendant de la distance entre le multiplexeur et le pavé. Puisque les multiplexeurs font partie du tissu de commutation, le délai entre le pavé et le multiplexeur peut varier en fonction de l’emplacement du pavé. Pour mettre en œuvre la commutation, les programmes locaux exécutés sur les pavés comprennent des instructions de contrôle de commutation (PUTi) qui provoquent l’émission d’un signal de commande de multiplexeur 214 pour contrôler le multiplexeur associé à ce pavé pour commuter son entrée un certain temps avant l’instant où une donnée particulière est attendue pour être reçue au niveau du pavé. Dans la phase d’échange, des multiplexeurs sont commutés et des paquets (données) sont échangés entre pavés en utilisant le tissu de commutation. Avec cette explication, il est clair que le tissu de commutation n’a pas d’état - le mouvement de chaque donnée est prédéterminé par l’ensemble particulier de fils sur lequel l’entrée de chaque multiplexeur est commutée.

[0078] L’instruction SEND comprend une indication d’au moins une direction dans laquelle une donnée va se déplacer dans le tissu de commutation 34 à partir du pavé émetteur vers un ou plusieurs pavés récepteurs. Des données émises à partir d’un seul pavé T vers un seul pavé T peuvent se déplacer dans l’une de deux directions fixes dans le tissu d’échange 34, la direction dépendant des identifiants de ces deux instances de pavés en communication. L’architecture de pavés décrit la direction d’échange telle qu’observée par l’émetteur et chaque instruction d’envoi utilise une paire de drapeaux de configuration pour indiquer la direction de déplacement (Est et/ou Ouest). Elle est fonctionnellement valide pour positionner les drapeaux East-Valid et West-Valid pour chaque instruction SEND exécutée (et effectivement nécessaire lorsqu’il y a 2, ou plus, pavés destinataires et ces destinataires nécessitent une direction de transfert différente). Toutefois, dans les cas où tous les pavés destinataires sont strictement à l’est ou à l’ouest du pavé d’envoi, le fait de positionner seulement le drapeau de direction pertinent va permettre l’utilisation d’optimisations d’énergie.

[0079] On va faire référence à la figure 13, qui illustre comment l’indication d’au moins une direction peut être utilisée pour contrôler la direction de déplacement d’une donnée dans le tissu de commutation 34.

[0080] Lorsque le processeur du pavé d’envoi 1310 exécute une instruction d’envoi, une indication de ladite au moins une direction fournie par l’instruction d’envoi peut être insérée dans une donnée à émettre sur le tissu de commutation. L’indication peut être insérée dans un en-tête de la donnée. Dans cet exemple, le pavé récepteur 1320 est représenté situé dans une deuxième direction par rapport au pavé d’envoi 1310. Par conséquent, l’indication de ladite au moins une direction comprend une indication indiquant que la donnée doit être émise dans la deuxième direction dans le tissu de commutation 34. Puisque, dans cet exemple, il n’y a pas de pavé récepteur positionné dans la première direction dans le tissu de commutation 34 en partant du pavé d’envoi 1310, l’indication de ladite au moins une direction comprend une indication indiquant que la donnée ne doit pas être émise dans la première direction dans le tissu de commutation 34. Le processeur du pavé émetteur 1310 peut être agencé pour, en réponse à l’exécution de l’instruction d’envoi, émettre à un instant d’émission, la donnée sur un fil de connexion 1330 du tissu de commutation 34. Sur le fil de connexion 1330 se trouve une série de stockages temporaires 1340a, 1340b, 1340c, 1340d, 1340e, 1340f, par exemple des verrous ou des bascules qui maintiennent la donnée pendant un cycle d’horloge avant de la libérer vers le stockage suivant. Chacun des stockages temporaires peut inclure ou être associé à un circuit de traitement approprié pour déterminer si la donnée doit ou non être émise sur le fil de connexion 1330 au-delà du stockage temporaire.

[0081] Lorsque la donnée atteint l’un des stockages temporaires, l’indication de ladite au moins une direction est évaluée pour déterminer si la donnée est autorisée à être transmise à travers le stockage temporaire ou si elle doit être bloquée/empêchée d’être transmise plus loin dans tissu de commutation. Par exemple, lorsque la donnée sur le fil de connexion 1330 atteint le stockage temporaire 1340a, l’indication indiquant si la donnée doit être transmise ou non dans la première direction est vérifiée. Puisque, dans cet exemple, la donnée est destinée à être transmise dans la deuxième direction seulement pour fourniture au pavé récepteur 1320, on empêche la donnée de passer audelà du stockage temporaire 1340a.

[0082] Par contre, lorsque la donnée atteint le stockage temporaire 1340c, l’indication indiquant si la donnée doit ou non être transmise dans la deuxième direction est vérifiée. Dans ce cas, puisque cette indication est positive, la donnée est transmise à travers le stockage temporaire 1340c le long du fil de connexion 1330. La même vérification peut être réalisée et on peut atteindre la même conclusion au niveau des stockages temporaires 1340d, 1340e, et 1340f. Cela assure que la donnée va atteindre le pavé récepteur 1320 par l’intermédiaire du multiplexeur d’entrée 1350 de ce pavé 1320.

[0083] Par conséquent, l’agencement du tissu de commutation est configuré pour laisser passer les données seulement suivant lesdites une ou plusieurs directions indiquées pour transmission dans la donnée et pour empêcher la transmission de la donnée dans le tissu de commutation dans des directions non indiquées pour transmission dans la donnée. Cela présente l’avantage de permettre une optimisation de l’énergie en réduisant les transmissions de données vers des parties du tissu de commutation où il n’y a pas de pavés destinés à recevoir ces données particulières. Des opposés directionnels ne s’appliquent pas aux directions d’échange entre pavés. Par exemple, si le pavé 1310 envoie toutes ses données à fournir au pavé 1320 avec des indicateurs indiquant que la transmission est autorisée dans la deuxième direction, mais pas autorisée dans la première direction, cela n’implique pas que, lorsque le pavé 1320 envoie des données à fournir au pavé 1310, ces données doivent inclure des indicateurs indiquant que la transmission est autorisée dans la première direction, mais pas autorisée dans la deuxième direction. Cela pourrait être par exemple un cas où le pavé 1320 émet vers le pavé 1310 des données comportant des indicateurs indiquant que la transmission doit avoir lieu à la fois dans la deuxième direction et dans la première direction sur le tissu de commutation.

[0084] Dans la phase d’échange, une communication de tous les pavés vers tous les pavés est activée. La phase d’échange peut avoir de multiples cycles. Chaque pavé 4 a le contrôle de son propre et unique multiplexeur d’entrée 210. Le trafic entrant provenant de n’importe quel autre pavé dans la puce, ou provenant de l’une des liaisons de connexion, peut être sélectionné. On notera qu’il est possible qu’un multiplexeur soit réglé pour recevoir une entrée ‘nulle’ - c’est-à-dire aucune entrée provenant d’aucun autre pavé dans cette phase d’échange particulière. La sélection peut changer cycle par cycle dans une phase d’échange ; elle ne doit pas être constante partout. Des données peuvent être échangées sur une puce, ou de puce à puce ou de puce à hôte en fonction de la liaison qui est sélectionnée. La présente application est concernée principalement par des communications entre pavés sur une puce. Pour réaliser une synchronisation sur la puce, un petit nombre de signaux en pipeline sont prévus à partir de tous les pavés vers un contrôleur de synchronisation 36 sur la puce et un signal sync-ack en pipeline est diffusé à partir du contrôleur de synchronisation pour revenir vers tous les pavés. Dans un mode de réalisation, les signaux en pipeline sont des signaux ET/OU reliés en guirlande d’une largeur d’un bit. Un mécanisme par lequel une synchronisation entre pavés est obtenue est l’instruction SYNC mentionnée précédemment, ou décrite dans la suite. D’autres mécanismes peuvent être utilisés : ce qui est important c’est que tous les pavés puissent être synchronisés entre une phase de calcul de la puce et une phase d’échange de la puce (figure 3). L’instruction SYNC déclenche la fonctionnalité suivante dans de la logique de synchronisation dédiée sur le pavé 4, et dans le contrôleur de synchronisation 36. Le contrôleur de synchronisation 36 peut être mis en œuvre dans l’interconnexion matérielle 34 ou, comme cela est représenté, dans un module séparé sur la puce. Cette fonctionnalité à la fois de la logique de synchronisation sur les pavés et du contrôleur de synchronisation 36 est mise en œuvre dans des circuits matériels dédiés de telle sorte que, une fois que l’instruction SYNC est exécutée, le reste de la fonctionnalité procède sans que d’autres instructions soient exécutées pour le faire.

[0085] Premièrement, la logique de synchronisation sur chaque pavé amène l’émission d’instructions du superviseur sur le pavé 4 en question à se mettre automatiquement en pause (elle amène l’étage d’extraction 14 et l’ordonnanceur 24 à suspendre l’émission d’instructions du superviseur). Une fois que tous les fils de travail en cours sur le pavé 4 local ont exécuté un EXIT, alors la logique de synchronisation envoie automatiquement une demande de synchronisation “sync_req” au contrôleur de synchronisation 36. Le pavé local 4 continue ensuite à attendre avec l’émission d’instructions du superviseur en pause. Un processus similaire est aussi mis en œuvre sur chacun des autres pavés 4 dans la matrice 6 (chacun comprenant sa propre instance de la logique de synchronisation). Ainsi à un certain point, une fois que tous les fils de travail finaux dans la phase de calcul courante 52 ont fait un EXIT sur tous les pavés 4 dans la matrice 6, le contrôleur de synchronisation 36 aura reçu une demande de synchronisation (sync_req) respective à partir de tous les pavés 4 de la matrice 6. C’est seulement alors, en réponse à la réception du sync_req provenant de chaque pavé 4 de la matrice 6 sur la même puce 2, que le contrôleur de synchronisation 36 renvoie un signal d’accusé de réception de synchronisation “sync_ack” à la logique de synchronisation sur chacun des pavés 4. Jusqu’à atteindre ce point, chacun des pavés 4 a eu son émission d’instructions de superviseur mise en pause en attente du signal d’accusé de réception de synchronisation (sync_ack). A la réception du signal sync_ack, la logique de synchronisation se trouvant dans le pavé 4 retire automatiquement la pause de l’émission d’instructions du superviseur pour le fil superviseur respectif sur ce pavé 4. Le superviseur est alors libre de procéder à un échange de données avec d’autre pavés 4 via l’interconnexion 34 dans une phase d’échange ultérieure 50.

[0086] De préférence les signaux sync_req et sync_ack sont émis et reçus vers et à partir du contrôleur de synchronisation, respectivement, par l’intermédiaire d’un ou plusieurs fils de synchronisation dédiés connectant chaque pavé 4 au contrôleur de synchronisation 36 dans l’interconnexion 34.

[0087] La structure de connexion du pavé va maintenant être décrite plus en détail.

[0088] Chaque pavé comporte trois interfaces :

- une interface exin 224 qui passe des données à partir du tissu de commutation 34 au pavé 4 ;

- une interface exout 226 qui passe des données à partir du pavé au tissu de commutation sur le bus d’échange à diffusion 218 ; et

- une interface exmux 228 qui passe le signal de contrôle de multiplexeur 214 (mux-select) du pavé 4 à son multiplexeur 210.

[0089] Afin de s’assurer que chaque pavé individuel exécute des instructions SEND et des instructions de commande de commutateurs à des instants appropriés pour émettre et recevoir les données correctes, des exigences de planification d’échanges doivent être satisfaites par le programmeur ou le compilateur qui alloue des programmes individuels aux pavés individuels dans l’ordinateur. Cette fonction est réalisée par un planificateur d’échanges qui a besoin d’être conscient des paramètres temporels d’échange (BNET) suivants. Afin de comprendre les paramètres, une version simplifiée de la figure 2 est représentée en figure 4. La figure 4 représente aussi un pavé destinataire ainsi qu’un pavé émetteur.

[0090] I. Le délai d’accusé de réception de SYNC relatif de chaque pavé, BNET_RSAK (TID). TID est l’identifiant de pavé contenu dans un registre TILE_ID décrit dans la suite. C’est un nombre de cycles toujours supérieur ou égal à 0 indiquant le moment où chaque pavé reçoit le signal d’accusé de réception à partir du contrôleur de synchronisation 36 par rapport au pavé récepteur le plus en avance. Il peut être calculé à partir de l’ID de pavé, en notant que l’ID de pavé indique remplacement particulier de la puce sur ce pavé, et par conséquent reflète les distances physiques. La figure 4 représente un pavé émetteur 4_T, et un pavé destinataire 4_R. Bien que cela soit représenté seulement schématiquement et pas à l’échelle, le pavé 4_T est représenté plus près du contrôleur de synchronisation et le pavé 4_R est représenté plus loin, avec comme conséquence que le délai d’accusé de réception de synchronisation va être plus court pour le pavé 4_T que pour le pavé 4_R. Une valeur particulière va être associée à chaque pavé pour le délai d’accusé de réception de synchronisation. Ces valeurs peuvent être maintenues par exemple dans une table de délais, ou peuvent être calculées au vol à chaque fois sur la base de l’ID de pavé.

[0091] II. Le délai de boucle de contrôle de multiplexeur d’échange, BNET_MXP (TID de pavé récepteur). C’est le nombre de cycles entre l’émission d’une instruction (PUTi-MUXptr) qui modifie une sélection de multiplexeur d’entrée du pavé et le point le plus en avance où le même pavé pourrait émettre une instruction de chargement (hypothétique) pour échanger des données stockées en mémoire en résultat de la nouvelle sélection de multiplexeur. En regardant la figure 4, ce délai comprend le délai pour que le signal de commande arrive à partir de l’interface exmux 228_R du pavé destinataire 4_r à son multiplexeur 210_R et la longueur de la ligne entre la sortie du multiplexeur et l’interface exin d’entrée de données 224.

[0092] III. Le délai d’échange de pavé à pavé, BNET_TT (TID de pavé d’envoi, TID de pavé de réception). C’est le nombre de cycles entre l’émission d’une instruction SEND émise sur un pavé et le point le plus en avance où le pavé récepteur pourrait émettre une instruction de chargement (hypothétique) pointant vers la valeur envoyée dans sa propre mémoire. Cela a été déterminé à partir des ID des pavés émetteur et récepteur, soit en accédant à une table comme cela a déjà été décrit, soit par calcul. Si on regarde de nouveau la figure 4, on voit que ce délai comprend le temps pour que des données se déplacent du pavé émetteur 4_T à partir de son interface ex_out 226_T jusqu’au tissu de commutation 14 le long de son bus d’échange 218_T puis via le multiplexeur d’entrée 210_r au niveau du pavé récepteur 4_R jusqu’à l’interface ex_in 224_R du pavé récepteur.

[0093] IV. Le délai de mise à jour de pointeur mémoire de trafic d’échange, BNET_MMP(). C’est le nombre de cycles entre l’émission d’une instruction (PUTi-MEMptr) qui modifie un pointeur en mémoire de trafic d’entrée d’échange du pavé et le point le plus en avance où ce même pavé pourrait émettre une instruction de chargement (hypothétique) pour un échange de données stockées en mémoire comme résultat du nouveau pointeur. C’est un petit nombre fixe de cycles. Le pointeur mémoire n’a pas encore été décrit, mais il est représenté en figure 2 avec la référence 232. Il agit comme pointeur dans la mémoire de données 202 et indique où des données entrantes provenant de l’interface ex_in 224 doivent être mémorisées. Cela est décrit plus en détail dans la suite.

[0094] Le délai vers l’est suivant le bus d’échange BNET_EAST (TIDs, TIDr). C’est le délai dans le tissu d’échange à partir du pavé d’envoi jusqu’au pavé destinataire.

[0095] Dans la suite, on fait référence à des super-pavés. Chaque super-pavé comprend quatre pavés, chacun muni d’un identifiant comme cela est représenté en figure 16. Comme cela est expliqué ici, l’identifiant de pavé a la forme d’un ID de super-pavé à 5 bits, d’un ID de colonne à 4 bits et d’un ID de pavé à 2 bits. [Math.l]

TID,tile_sub_id[IsO]

TID.colunm_id[3:0]

TID.5upertile_id[4:0]

TileID[1:0];

TxleXDf5:2];

TiielD]10:6];

[0096] Les composantes de chemin et leurs définitions qui contribuent à ces délais sont données ci-dessous.

[Math.2]

BSET_RSAK(TÏD)

BKET_TT(TIDO, TID1)

BNET_EAST(TIDO, TIDI )

Sack_Delay_To_Reach_Other_Side_Of _Exchan.ge( TID ) +

Sack_Delay_Along_EKchange_To_Column_Ba.se {TID ) +

Column_Base_To_Tile_Delay(TID) +

Sack_Delay_Normalization_Adder;

Send_To_Exchange_Output_Delay +

Tiie_To_Column_Base_Deiay{ TIDO ) + (Column_Base_Compensation_Delay(TIDO)}/2 +

Column_Base_To_Excharige_Bus_Delay(TIDO) +

ABS (Easterly_Delay_Along_Exchange(TIDO,TIDi)) -r

Exchange_Bus_To_Column_Base_Delay{TIDO,TIDI) +

Column Base Compensation Delay(TIDI ) +

Column_B a s e_To_Ti1e_Delay{TID1) +

MininiuiB_Exchange_Ir.put_To_DepeBdent_LD_Delay ;

Easterly_Delay_Along_Exchange(TIDO,TIDi) > 0;

BMET_MXP(TID}

Puti_TG>_Exchange_Control_Output_Delay +

T1 le_To_Column_Ba se_De 1 ay (TID) + (7 - colwnn_Base_Compensation_Delay(TID)) +

Column_Base_To_Opp©site_Side_Of_Exchange_Delay +

Oppcsite_Side_Of_Exchaïige_To_Coluinn_Base_Delay +

Column_Ba&e_Coæpen.sation_Delay {TID} +

Column_Base_To_Tile_Delay(TID) +

Minimum Exchange Input To Dependent LD Delay;

ENET MMP

7; #From EO ->EO,E1,E2,E3,E4,XO,X2, (LD EO}

[Math.3]

Colunui_Position_Ess v <’ TID ) = (TIE. co-iumn_id[ 3 j ==1 j ? 15-TID, ç'olumn_idî TID. colurnn_id;

.Send_Tc_Ezchange_ûUvpu-t_Delay = 8? #frara EO -> EO _r El _f Ξ2 , E3 ,E4_t E5 ! E6 , E7-> outTile_Tc_Coiumn_Base_Delay(TID) = TID.supertile_ic + 3γ

Cclu:Tu‘i_Ease_Cou\per.sation_delay ( TIE ) = ( 7-(TID . cclumri—id MOD 3 > } ;

Col.UK!n_Base_’?o_Exehange_Eus_Delay ( TID ) = < TID ccolumn._id MOD 8)/2 + 2 ;

Easter ly_Delay_Along_Exchance < TXDO ,TXD1 =

4* ( Colu,mr._Positian_Ea5t ( TÎD1 ) -Colu’.t<n._Posi t ion_East < TIDO ) } 6* (TIDO_Ύ tile_sub_id{ 0 ] ~ TIDw »coluiiw._id{ 3 } ) + (T.ID1. tile_Su.O_id<2 ) 1 (TID1. colunu*_id{ 3 } == TID1. t ile_sub_id[ υ J ) ? 1: 5 ) j (TÎD1. coluirùï_id[ 3 ]== TID1.tile_sub_id(O])?2s4) ?

Exchange_Bus_'Tc_Column_Base_Delay ( TIDC, TIDl ) = ( TXDO . ccluian_id [ 3 ·== TID1. σο1ιικίη_ϊά{ 3 ] )?

{(TIDO.coluran_id MOD 8) + 1}:

7 -· { ( TIDO . column_id MOD 8) + ljj

Οο1ΜΓΛΓ._Εθ5β_ΊΌ_Τί1β_Ββίβν(ΤΧΒ_; = TID. supertile_id + 3;

Xinx:uuiii_Ezchange_lnp«t:_ⁱro_DeperLdent._LD_Delay = 3} #X0, X2, ( Txlemeiu El == LD E0> Puti_To_Ezchange_Corjtrol_Output_Delay = 8; #.froiu EO — >E'O _f.El, E2 , E3 , Ξ4 _rE5 _f Ξ6:/S7->out

Ccluxui-Base-TO-Opposite-Side-Df-ExcTiange _Delay = 17 ?

Opposite_Side_Of_Exchangs_To_Caluir!n__Base_Delay = 197#(A^?ote.· IB if. e.Ytra decode stage is included)

Saek—DelaV—TO—Reach—Other—Side—Of—Exchange (TID ) - TIE. ccIukîïï_id[ 3 ] * 8 ; Sack_Delay_Along_ExGhar.ge_To_Column_Ease (TID) = Column_Eosition_Eastu TID) *4 * 2 ;

Sacji_Delay_Nora;alization_Adder = -5;

[0097] La figure 5 représente plus en détail le déroulement temporel des échanges. Sur le côté gauche de la figure 4 se trouvent les cycles d’horloge IPU allant de 0 à 30. L’action sur le pavé d’envoi 4_T survient entre les cycles d’horloge IPU 0 et 9, en commençant par l’émission d’une instruction d’envoi (SEND F₃). Dans les cycles d’horloge IPU 10 à 24, la donnée suit son chemin en pipeline dans le tissu de commutation 34.

[0098] En regardant le pavé de réception 4_R dans le cycle d’horloge IPU 11 on voit qu’une instruction PUTi est exécutée pour changer la sélection de multiplexeur d’entrée de pavé : PUTi-MXptr (F₃). En figure 5, cette instructions PUTi est nommée “PUTi INCOMING MUX (F3)”.

[0099] Dans le cycle 18, l’instruction de pointeur mémoire est exécutée, PUTi-MEMptr (F₃), permettant une instruction de chargement dans le cycle d’horloge ITU 25. En figure 5, cette instructions PUTi est notée “PUTi INCOMING ADR (F3)”.

[0100] Sur le pavé d’envoi 4_t, les cycles d’horloge IPU 1, 3 et 5 sont notés “Transport ( )”. Cela est un délai de pavé interne entre l’émission d’une instruction SEND et la manifestation des données de l’instruction SEND sur l’interface exout. F4, El, E3, etc. représentent des données provenant d’instructions SEND antérieures dans le transport vers l’interface exout. Le cycle d’horloge IPU 2 est alloué à la formation d’une adresse EO pour une instruction SEND. On notera que c’est l’adresse d’où EO doit être extrait, pas son adresse de destination. Dans le cycle d’horloge IPU 4, un macro de mémoire est exécuté pour extraire E2 de la mémoire. Dans le cycle d’horloge IPU 6 un contrôle de parité est réalisé sur E4. Dans le cycle d’horloge IPU 7 une instruction de sortie MUX est exécutée pour envoyer E5. Dans le cycle d’horloge IPU 8, E6 est codé et dans le cycle d’horloge IPU E7 est fourni en sortie.

[0101] Dans le tissu d’échange 34, les cycles d’horloge IPU 10 à 24 sont notés étage de pipeline d’échange. Dans chaque cycle, une donnée se déplace d’un pas suivant le pipeline (entre des stockages temporaires).

[0102] Les cycles 25 à 28 représentent le délai sur le pavé récepteur 4_R entre la réception d’une donnée au niveau de l’interface exin (voir Mem Macro (E2) pour Exe), tandis que les cycles 25 à 29 représentent le délai entre la réception d’une donnée au niveau de l’interface exin et son chargement en mémoire (voir Mem Macro (E2)) pour LD. D’autres fonctions peuvent être réalisées dans ce délai - voir Earliest LD (F3), Reg file rd (F4), form adds (EO), Transport (El).

[0103] En termes simples, si le processeur du pavé de réception 4_R veut agir sur une donnée (par exemple F3) qui était la sortie d’un processus sur le pavé émetteur 4_T, alors le pavé émetteur 4_T doit exécuter une instruction SEND [SEND F3)] à un certain instant (par exemple le cycle d’horloge IPU 0 en figure 5), et le pavé récepteur doit exécuter une instruction de contrôle de commutateur PUTi EXCH MXptr (comme dans le cycle d’horloge IPU 11) un certain temps après l’exécution de l’instruction SEND [SEND (F3)] sur le pavé émetteur. Cela va assurer que les données arrivent au niveau du pavé récepteur à temps pour être chargées [earliest LD (F3)] dans le cycle IPU 25 pour utilisation dans un codelet qui est exécuté au niveau du pavé récepteur.

[0104] On notera que le processus de réception au niveau d’un pavé récepteur n’a pas besoin d’impliquer le réglage du pointeur mémoire comme avec l’instruction PUTi MEMptr. Au lieu de cela, le pointeur mémoire 232 (figure 2) s’incrémente automatiquement après la réception de chaque donnée au niveau de l’interface exin 224. Les données reçues sont ensuite juste chargées dans l’emplacement mémoire disponible suivant. Cependant, la capacité à changer le pointeur mémoire permet au pavé récepteur d’altérer l’emplacement mémoire où la donnée est écrite. Tout cela peut être déterminé par le compilateur ou le programmeur qui écrit les programmes individuels dans les pavés individuels afin qu’ils communiquent correctement. Cela amène les caractéristiques temporelles d’un échange interne (les échanges internes sur la puce) à être complètement déterministes dans le temps. Ce déterminisme temporel peut être utilisé par l’ordonnanceur d’échange pour optimiser fortement des séquences d’échange.

[0105] On va faire référence aux figures 14 et 15, qui illustrent un exemple de la disposition de colonnes sur la puce de processeur 2, illustrant l’agencement de pavés 4 sur la puce plus en détail. Chaque pavé 4 fait partie d’un ensemble de 4 pavés, appelé super-pavé 61. Chaque super-pavé 61 comprend quatre pavés 4. Pour simplifier, seuls quelquesuns des super-pavés 61 représentés en figure 15 sont représentés divisés en leurs pavés constituants.

[0106] Chaque super-pavé 61 fait partie d’un sous-système de pavés appelé colonne 62_n. Par conséquent, chaque pavé 4 fait aussi partie d’une colonne 62_n. Dans un mode de réa lisation, chaque colonne 62 comprend vingt super-pavés 61, numérotées ST₀ à St_i9 (80 pavés au total).

[0107] Comme cela a été décrit précédemment, chaque pavé 4 comporte une connexion d’entrée 217 de 32 bits, et une connexion de sortie 218 de 32 bits. Comme cela a été mentionné, le pavé 4 sait (puisque cela est défini dans la séquence d’instructions compilée pour le pavé) qu’il va attendre une donnée provenant d’un certain pavé émetteur à un certain instant, et il exécute une instruction PUTi-MUXptr, pour contrôler le multiplexeur pour commuter à un certain instant sur l’entrée connectée à l’ensemble de fils de connexion 140 qui est connecté à la sortie 218 du pavé d’envoi. Cela assure que la donnée va apparaître au niveau de la sortie 230 du multiplexeur de 210 à l’instant où le pavé récepteur s’attend à le recevoir.

[0108] Le multiplexeur de 210 reçoit un signal de commande de multiplexeur sur la ligne de commande 214 qui identifie un identifiant de pavé unique indiquant où ce multiplexeur doit ‘pointer’. C’est-à-dire, à quel ensemble de fils croisés sur le bus d’échange 34 doit se connecter ce multiplexeur afin ‘d’écouter’ le pavé à partir duquel une transmission est attendue à cet instant.

[0109] Dans l’agencement décrit ici, le multiplexeur pour les pavés se trouvant dans chaque colonne est connecté à un groupement de 40 ensembles des fils croisés d’échange. Chaque ensemble permet de transporter une donnée de 32 bits sur le bus d’échange. Comme cela est également représenté en figure 14, les ensembles sont divisés en deux, qui sont appelés Est et Ouest (en fonction du côté de la colonne auquel les multiplexeurs seraient connectés). La figure 14 représente deux multiplexeurs connectés à un super-pavé ST2 de sur le côté est de la colonne, et deux multiplexeurs connecté à un super-pavé ST3 sur le côté est de la colonne. Sur le côté ouest de la colonne, deux multiplexeurs sont représentés connectés à deux pavés dans le super-pavé ST2. Dans un but de clarté, aucun autre multiplexeur ni aucune autre ligne de connexion ne sont représentés en figure 14, mais on remarquera qu’il y a deux multiplexeurs pour chaque super-pavé sur chaque côté de la colonne, ce qui donne un total de vingt multiplexeurs sur le côté est et vingt multiplexeurs sur le côté ouest. Chaque multiplexeur devrait être capable de connecter l’un quelconque des 1280 ensembles de fils croisés d’échange se trouvant dans le tissu d’échange 34. Dans certaines puces, seuls 1216 fils croisés d’échange sont nécessaires, mais dans d’autres tous les 1280 ensembles peuvent être actifs. Afin de mettre en œuvre un multiplexeur à 1216 voies, de telle sorte qu’une réparation puisse être effectuée efficacement, chaque multiplexeur 210 comprend 32 tranches de multiplexeur à 40 voies qui sont illustrées en figure 12. Les tranches de multiplexeur sont référencées 1210-0, 1210-1... 1210-31. Le nombre de 32 a été choisi pour concorder avec le nombre de demi-colonnes dans la matrice qui sont connectées à chaque bus d’échange. On notera que ce nombre peut varier puisque le nombre de colonnes varie en fonction de chaque architecture de processeur particulière. Toutefois, dans des modes de réalisation préférés, il y a une tranche de multiplexeur à n voies par demi-colonne. Le multiplexeur 210 comprend un bloc de décodage 1220 qui reçoit le signal de commande MUX sur une ligne 214. Comme cela a été mentionné, le bloc de décodage reçoit l’identifiant de pavé unique du pavé émetteur sur la ligne de commande de MUX 214. Le bloc de code 1220 sélectionne l’une des 32 tranches de multiplexeur sur la base des bits d’identifiant de colonne dans l’identifiant de pavé. Ensuite, le bit le moins significatif de l’identifiant de pavé indique si un ensemble d’entrées côté est ou un ensemble d’entrés côté ouest de cette tranche de multiplexeur doit être sélectionné (en fonction du fait que le pavé émetteur est sur le côté est ou ouest de la colonne émettrice). Ensuite, les bits d’identifiant de super-pavé de l’identifiant de pavé sont utilisés pour sélectionner l’une de 20 entrées dans la tranche est ou ouest du multiplexeur 1210. De cette manière, une entrée particulière est sélectionnée à l’instant où un message provenant du pavé émetteur est attendu en réception au niveau du pavé récepteur d’une manière déterministe dans le temps comme cela a été décrit précédemment.

[0110] Comme cela est également illustré en figure 15, un délai de compensation en fonction de la colonne peut être introduit pour permettre d’utiliser un code d’échange identique pour des échanges intra-colonnes similaires et pour certains motifs d’échanges inter-colonnes similaires. Dans ce contexte, le code d’échange comprend la séquence d’instructions impliquée dans la phase d’échange et qui gère l’échange de données entre pavés. Le code d’échange comprend au moins l’instruction SEND et l’instruction de commande de commutateur. En outre, le code d’échange peut comprendre l’instruction de pointeur mémoire qui peut déterminer l’adresse à laquelle des données entrantes sont chargées. Un délai de compensation en fonction de la colonne peut être introduit en sélectionnant un certain nombre d’étages de retard pour former un circuit de retard introduit dans chacune des composantes de chemin concernées d’un chemin d’échange entre pavés. Comme cela apparaîtra évident d’après la discussion précédente, un chemin d’échange comprend les composantes suivantes.

[0111] Il y a un délai entre pavé et base de colonne qui est le temps pris par une donnée pour se propager d’une unité de traitement dans la colonne jusqu’à la base de la colonne. Ce délai dépend de la position du pavé dans la colonne (et est plus long pour les pavés qui sont plus loin de la base de la colonne). Le délai entre pavé et base de colonne est fixé par la position du pavé dans la colonne et est par conséquent le même pour tous les pavés disposés respectivement dans chaque colonne.

[0112] Le délai de compensation de colonne permet d’introduire une compensation dans le chemin de sortie 218 qui transporte la sortie du pavé jusqu’au bus d’échange. Cela est indiqué par un bloc 318 dans chacune des lignes de sortie illustrées. On remarquera qu’en théorie, le circuit de retard pourrait être situé n’importe où dans le chemin de sortie 218, mais qu’en pratique le délai de compensation en fonction de la colonne pour la ligne de sortie peut facilement être mis en œuvre sous forme d’un ensemble d’étages de retard dans l’espace entre la base de la colonne et le tissu de commutation sur la puce. La figure 15 est très schématisée pour illustrer les concepts sous-jacents.

[0113] Le délai entre base de colonne et bus d’échange est le temps pris pour que la donnée parcoure la distance entre la base de la colonne (à partir de l’étage de délai de compensation de base de colonne) jusqu’au groupe de fils de bus d’échange associé à cette colonne. On notera que d’après la figure 15 cette distance est plus grande pour les colonnes du côté est, puisqu’elles utilisent des fils de bus d’échange qui sont plus au sud que les colonnes du côté ouest. En fait, chaque colonne du côté nord comporte des fils de sortie connectés à un groupe adjacent respectif (se déplaçant vers le sud) de fils de bus d’échange allant vers le point milieu du bus d’échange. Inversement, chaque colonne du côté sud comporte des fils de sortie connectés à un groupe adjacent respectif se déplaçant vers le nord.

[0114] Il y a un délai dans le tissu d’échange pendant que la donnée se propage pour être prélevée à l’instant correct par le pavé destinataire (qui peut être dans la même colonne ou dans une autre colonne). On notera qu’il peut y avoir des délais de tissu d’échange horizontalement même lorsqu’un pavé s’envoie un message à lui-même.

[0115] Un autre délai de compensation de base de colonne peut ensuite être introduit sur le côté de l’entrée pour le pavé destinataire. Cela est illustré en figure 15 sous forme d’un circuit de retard 317 dans la sortie du multiplexeur 210. Une fois encore, on remarquera que le délai de chemin inhérent à partir du groupe de fils d’échange jusqu’à leurs colonnes du côté le plus à l’est est supérieur à celui sur le côté le plus à l’ouest. On notera toutefois que tout délai de compensation introduit dans le chemin d’entrée affecte aussi le délai de boucle de commande de MUX d’échange, BNT_MXP. Pour garantir que celui-ci n’est pas affecté, ce délai doit être compensé par une compensation de délai correspondante dans la ligne de commande de MUX 214, comme cela est représenté par le circuit de retard 314.

[0116] Il y a ensuite une composante de chemin pendant que la donnée se propage de la base de colonne (à partir de la sortie du délai de compensation en fonction de la colonne) jusqu’au pavé respectif dans la colonne. Celui-ci est basé sur la position du pavé dans la colonne.

[0117] Il n’y a pas d’autres délais dans le chemin d’échange, qui soient internes aux pavés eux-mêmes. Au début d’un processus de transmission, il y a un délai entre l’exécution de l’instruction SEND et l’instant où la donnée arrive au niveau de l’interface EX_OUT du pavé. Celui-ci est identique pour tous les pavés.

[0118] En plus, il y a un délai entre la réception d’une donnée au niveau d’un pavé et le premier instant où elle peut hypothétiquement être chargée. Celui-ci est identique pour tous les pavés.

[0119] Chaque délai de compensation comprend une pluralité d’étages de retard qui peuvent être sélectionnés lorsque le processeur est initialement mis en place. Selon un mode de réalisation, les retards pourraient être définis au moment de la fabrication de l’ordinateur. Dans un autre mode de réalisation, les étages de retard peuvent être sélectionnés de manière programmable (par exemple en utilisant des dérivations entre des étages de retard) avant que du code soit chargé dans les pavés respectifs de l’ordinateur.

[0120] Sans compensation, les échanges intra-colonnes de pavé à pavé dans une colonne n seraient plus longs que ceux dans les colonnes situées à l’ouest de celle-ci, en raison du temps mis pour traverser le bus d’échange dans la direction nord/sud. Selon une mise en œuvre, le but est de garantir que le délai BNET_TT d’échange intra-colonne de pavé à pavé ne dépend pas de l’identifiant de colonne. Cela signifie que des colonnes différentes peuvent toutes exécuter le même code d’échange d’une manière déterministe dans le temps.

[0121] Pour obtenir cela, lorsque le pavé émetteur et le pavé destinataire sont dans la même colonne, la somme du délai de compensation de base de colonne sur le chemin de sortie et du délai entre base de colonne et bus d’échange est réglée pour être constante. Comme cela a été expliqué précédemment, le délai entre base de colonne et bus d’échange varie en fonction de l’identifiant de colonne, mais on peut arranger cela par le délai de compensation de base de colonne.

[0122] En outre, la somme du délai entre bus d’échange et base de colonne et du délai de compensation en fonction de la colonne sur le côté d’entrée peut aussi être réglée à une valeur constante. C’est-à-dire que comme cela a été expliqué précédemment, le délai entre bus d’échange et base de colonne varie en fonction de l’identifiant de colonne, mais cela peut être compensé par le délai de compensation sur le côté d’entrée.

[0123] En utilisant les mêmes valeurs constantes pour ces deux sommes pour chaque colonne, les délais intra-colonnes inter-pavés ne dépendent pas de l’identifiant de colonne.

[0124] Dans une autre mise en œuvre (qui peut être mise en œuvre dans la même architecture que la première), des délais inter-colonnes inter-pavés ont aussi une certaine régularité et les délais de compensation peuvent être conçus de telle sorte que du code d’échange puisse être réutilisé pour certains motifs d’échange.

[0125] Dans un premier cas, lorsque les pavés émetteur et destinataire sont tous les deux situés dans des colonnes du côté nord ou tous les deux situés dans des colonnes du côté sud, le délai inter-pavé est fonction de (TIDr.column_idMOD 8) TIDs.column_id

M0D8). Par exemple, du code d’échange pour du trafic entre les colonnes 1 et 4 pourrait être réutilisé pour un motif d’échange similaire entre les colonnes 2 et 5, préservant à la fois la direction et la distance physique des transactions d’échange. [0126] Dans un deuxième cas, lorsque le pavé d’envoi est dans une colonne du côté nord et le pavé récepteur est dans une colonne du côté sud ou vice versa, alors les délais interpavés sont fonction de (TIDr.column_idMOD 8)—(TIDs.column_idMOD8). Par exemple, du code d’échange pour du trafic entre les colonnes 0 et 13 pourrait être réutilisé pour un motif d’échange similaire entre les colonnes 1 et 12, préservant à la fois la direction et la distance physique de chaque transaction d’échange.

[0127] Cela peut être obtenu en comprenant qu’il y a une composante du délai inter-pavé qui dépend des identifiants relatifs des colonnes d’envoi et de réception :

la somme de ABS (délai vers l’est dans le bus d’échange TIDs, TIDr) + délai entre bus d’échange et base de colonne (TIDs, TIDr) + délai de compensation de base de colonne (TIDr).

[0128] Le premier terme ABS est fonction de l’espace séparant les colonnes physiques : ABS (position de colonne vers l’est) TIDs - position de colonne vers l’est (TIDr)).

[0129] Cela se simplifie en :

[Math.4] ( TIDs . 3 ] == TIDr .col uïan_id [ 3 ] ') 1

ABS((TIDs.column_id MOD 8) - (TIDr.coliimn_id MOD 8)}: ABS( (TIDs.colustn_id MOD 8 J - -(TIDr.column^id MOD S ) ) ;

La somme de la deuxième paire de termes se simplifie en :

{TIDs . coluittn_id[ 3 ] == TIDr. coluifin__id [ 3 j ) 7

T ((TIDs.coluSœ_id MOD 8) - (TIDr.columrWid MOD 8}): 16 - ((TIDs.colman_id MOD 8) - -(TIDr.column_id MOD 8));

[0130] Formule simplifiée des délais :

[Math.5]

BNET_MXP(TID) = Puti_To_Exchars.ge_Control_Output_DeLay +

Til^;e_To_Column_BaBô__DeLày (T.ID.) +

Colunm_Base_To_Opposite_Side_ôf_Exchange_Delay 4Opposite_Side_Of_Excharj.ge_To_Coluran_Base_Delay + Column_B ase_To_Tile_De Lay{TID) + Miniœum_Exchange_Input_TG_Dependent_LD_Delay ;

BNET_TT(TIDC., TID1} = Ββηά_Το_Εχαύ&ηαβ_Ου£ριυ·ι_Ββ]^γ + Ti 1 e_Tô_C ο 1 uiun_B as e_t>e 1 ay ( TI D 0 ) +

ABS (Easterly_Delay_Along_Exchancfe( TID0 ) ) -r (TIDs.column_id(3]== TIDr.column_idf 3])?

+ ((TIDÛ.column_id MOD 8) - (TID1.column_id MOD 8)): 16 - ((TID0.ccLuma_id MOD 8i - ~(TID1.aolumn_id MOD 8)); Column_Base_To_Tile_DeLay(TID1) + Minimum_Exchance_Input_To_Dependent-_LD_Delay ;

[0131] Le tableau représenté en figure 17, tableau I, indique un exemple de nombre d’étages de délai de compensation. Ceux-ci sont représentés schématiquement en figure 15 par les nombres à l’intérieur des circuits de compensation de délai pour la première colonne (colonne 0), et la énième colonne dans la matrice nord (colonne n). C’est-à-dire que, selon cet exemple, pour la colonne 0 un circuit de retard 318 entre pavé et bus d’échange comprend 3 étages de retard. La compensation de délai entre bus d’échange et pavé 317 comprend 7 étages. On notera que cela reflète la différence de temps pour qu’une donnée d’entrée traverse le bus d’échange (dans ce cas dans une direction vers le nord) dans le cas de la colonne 0 et le cas de la colonne n. Il n’y a pas de délai de compensation sur la ligne 214 de commande de commutateur pour la colonne 0. Toutefois, pour les raisons expliquées précédemment afin de maintenir le délai de boucle de commande de MUX d’échange non affecté, il y a un délai de sept étages pour la ligne de commande de commutateur provenant de la colonne n.

[0132] Dans le tableau représenté en figure 18, un exemple arbitraire spécifique est donné à titre d’illustration. Dans cet exemple, le pavé d’envoi 1186 est en colonne 0, superpavé numéro 18, et le pavé récepteur 1153 est en colonne 8, super-pavé numéro 18. Dans ce cas n=7 (8 colonnes de chaque côté du tissu d’échange). Cela donne un exemple d’un délai de pavé à pavé particulièrement long. Comme on peut le voir dans l’exemple spécifique, le délai de compensation de base de colonne dans le chemin sortant comprend la compensation de délai de 3 étages qui est cohérente avec le délai de compensation entre pavé et base de colonne d’échange dans le tableau I. En outre, le délai de compensation de base de colonne au niveau du côté récepteur est égal à 7, ce qui est cohérent avec les étages de délai de compensation entre bus d’échange et pavé dans le tableau I. On remarquera facilement que le tableau I peut être utilisé pour déterminer les délais inter-pavés pour n’importe quelle paire de pavés émetteur et récepteur, en prenant en compte les délais de compensation accompagnés des autres paramètres de délai déjà décrits ici. Ce tableau peut ensuite être utilisé pour déterminer les caractéristiques temporelles des échanges déterministes dans le temps lorsque du code est compilé pour les pavés des colonnes respectives. On notera en figure 18 que les délais dans le bus d’échange sont définis vers l’est, et qu’ainsi un délai vers l’ouest est représenté négatif (par exemple - 43).

[0133] Il y a un autre facteur qui doit être pris en compte dans certains modes de réalisation pour permettre que du code compilé spécifiquement pour une colonne (ou un groupe de colonnes) soit exécuté sans modification sur les pavés respectifs se trouvant dans une colonne différente (ou un groupe de colonnes différent). Dans de tels modes de réalisation, lorsque du code d’échange est généré, les instructions utilisées pour programmer le multiplexeur entrant expriment les pointeurs (tilelD) explicitement. Ainsi (par exemple) si une séquence de code d’échange intra-colonne est exécutée sur une colonne différente, alors les paramètres du multiplexeur entrant vont pointer vers des bus d’échange provenant de la colonne d’origine au lieu des bus appartenant aux pavés respectifs dans la nouvelle colonne. Ce problème peut être résolu en pro grammant un registre COLUMN_OFFSET (qui est dans les registres de statut de contexte du pavé représentés en figure 2) à une valeur non nulle. Cela provoque une modification de tous ces pointeurs incoming_mux (implicitement) juste avant qu’ils soient envoyés au multiplexeur du pavé concerné. Par exemple, pour prendre une séquence de code d’échange intra-colonne compilée pour les pavés en colonne 0 et pour l’exécuter à la place sur les pavés en colonne 1, alors chaque pavé en colonne 1 doit programmer son registre COLUMN_OFFSET à ‘1’ avant d’exécuter sa partie du code d’échange. Pour exécuter du code compilé pour une colonne du côté nord sur une colonne du côté sud (ou vice versa) la notion de ‘est’ et ‘ouest’ est permutée en mettant en place un bit spécial dans le registre COLUMN_OFFSET. Cela s’applique à toutes les instructions d’envoi non multidiffusées et pour une réception d’une largeur de 64 bits. Le mécanisme de commande de multiplexeur destiné à faciliter la réutilisation du code d’échange entre des groupes de colonnes similaires d’un point de vue topologique est décrit ci-après.

[0134] Par exemple : quatre groupes de 3 colonnes sont représentés avec des hachures différentes en figure 19. Les quatre groupes de colonnes illustrés sont {1,2, 11], {4, 5, 8], {9, 10, 3], {12, 13, 0}. Ces groupes particuliers ont été choisis seulement pour illustrer cette flexibilité du mécanisme - d’autres options sont possibles. En supposant que du code d’échange est généré pour les pavés dans l’un des groupes - alors le même code peut être utilisé dans les autres groupes. Pour rendre cela possible - le champ column_id se trouvant dans le registre de statut de contexte $INCOMING_MUX est ajusté implicitement par un mécanisme matériel dans chaque pavé. Du matériel dans chaque processeur de pavé modifie le champ column_id dans $INCOMING_MUX (bits [5:2]) selon l’équation 1 :

modified_column_id [3:0] - MOD($INCOMING_MUX[5:2] + (($INCOMING_MUX[5:2]<8) ? $COLUMN_OFFSET[3:0]: $COLUMN_OFFSET[3:0]), 16)

[0135] Le modified_column_id est utilisé par le matériel d’échange à la place de $INCOMING_MUX[5:2], Les autres champs de $INCOMING_MUX restent non modifiés. En outre, le matériel d’échange va inverser la direction est/ouest des SEND non-multidiffusés si $COLUMN_OFFSET [4] ==1. Des paquets peuvent inclure des bits de direction EV ou WV qui indiquent la direction dans laquelle se trouve le pavé destinataire, par rapport à la colonne d’envoi. Ceux-ci peuvent être utilisés pour empêcher que des paquets ne soient transmis inutilement sur le bus d’échange comme cela a été décrit dans notre demande de brevet antérieure [PWF Ref: 409364GB]. Pour réutiliser du code d’échange, les bits EV et WV (soit à partir de bits immédiats de l’instruction soit à partir de bits d’adresse se trouvant dans un registre de statut de contexte d’adresse d’envoi) sont permutés avant qu’ils soient activés sur le bus d’échange lorsque $COLUMN_OFFSET[4]==1).

[0136] La valeur $COLUMN_OLLSET[4:0] est une valeur de registre de statut de contexte qui est écrite avant d’exécuter le code d’échange réutilisé avec les valeurs dans l’équation 2 :

$COLUMN_OEESET[3:0] - (compiled_column_id<8)? MOD(modified_column_id compiled_column_id, 16): MOD(compiled_column_id - modified_column_id, 16) [0137] Le 'compiled_column_id' est le column_id de toute colonne se trouvant dans le groupe particulier pour lequel le code d’échange a été compilé. Le 'modified_column_id' est le column_id de la colonne se trouvant dans la même position dans son groupe de colonnes que 'compiled_column_id'. (Nota bene : la valeur $COLUMN_OFFSET[4] indique si la position polaire de colonne du pavé (nord/sud) est la même que la position polaire de colonne du pavé pour lequel le code d’échange a été compilé à l’origine. Les équations 1 et 2 sont appliquées à l’exemple de la figure 19 pour obtenir le schéma représenté en figure 19A.

[0138] Un autre exemple est représenté dans les figures 20 et 20A.

[0139] La figure 6 illustre un exemple d’application de l’architecture de processeur décrite ici, à savoir une application d’intelligence artificielle.

[0140] Comme cela a été mentionné précédemment et est connu de l’homme de l’art dans le domaine de l’intelligence artificielle, l’intelligence artificielle commence par une phase d’apprentissage dans laquelle l’algorithme d’intelligence artificielle apprend un modèle de connaissance. Le modèle peut être représenté sous forme d’un graphe 60 de nœuds 102 interconnectés et de liaisons 104. Les nœuds et les liaisons peuvent être appelés sommets et arrêtes. Chaque nœud 102 du graphe a une ou plusieurs arrêtes d’entrée et une ou plusieurs arrêtes de sortie, certaines des arrêtes d’entrée de certains des nœuds 102 étant les arrêtes de sortie de certains autres des nœuds, connectant ainsi entre eux les nœuds pour former le graphe. En outre, une ou plusieurs des arrêtes d’entrée d’un ou plusieurs des nœuds 102 forment les entrées du graphe dans son ensemble, et une ou plusieurs arrêtes de sortie d’un ou plusieurs des nœuds 102 forment les sorties du graphe dans son ensemble. Chaque arrête 104 communique une valeur ayant habituellement la forme d’un tenseur (matrice à n dimensions), cela formant les entrées et les sorties fournies aux nœuds 102 et à partir des nœuds sur leurs arrêtes d’entrée et de sortie respectivement.

[0141] Chaque nœud 102 représentent une fonction de ses une ou plusieurs entrées reçues sur son ou ses arrêtes d’entrée, le résultat de cette fonction étant la ou les sorties fournies sur l’arête ou les arêtes de sortie. Ces résultats sont parfois appelés activations. Chaque fonction est paramétrée par un ou plusieurs paramètres respectifs (parfois appelés poids, bien qu’ils n’aient pas besoin d’être obligatoirement des poids multiplicateurs). En général, les fonctions représentées par les différents nœuds 102 peuvent avoir des formes de fonction différentes et/ou peuvent être paramétrées par des paramètres différents.

[0142] En outre, chacun desdits un ou plusieurs paramètres de chaque fonction d’un nœud est caractérisé par une valeur d’erreur respective. En outre, une condition d’erreur respective peut être associée à l’erreur ou aux erreurs dans le ou les paramètres de chaque nœud 102. Pour un nœud 102 représentant une fonction paramétrée par un seul paramètre d’erreur, la condition d’erreur peut être un simple seuil, c’est-à-dire que la condition d’erreur est satisfaite si l’erreur est dans les limites du seuil spécifié mais n’est pas satisfaite si l’erreur est au-delà du seuil. Pour un nœud 102 paramétré par plus qu’un seul paramètre respectif, la condition d’erreur pour ce nœud 102 peut être plus complexe. Par exemple, la condition d’erreur peut être satisfaite seulement si chacun des paramètres de ce nœud 102 se trouve dans les limites du seuil respectif. Dans un autre exemple, une métrique combinée peut être définie comme combinant les erreurs dans les différents paramètres pour le même nœud 102, et la condition d’erreur peut être satisfaite à condition que la valeur de la métrique combinée se trouve dans les limites d’un seuil spécifié, mais autrement la condition d’erreur n’est pas satisfaite si la valeur de la métrique combinée est au-delà du seuil (ou vice et versa en fonction de la définition de la métrique). Quelle que soit la condition d’erreur, cela donne une mesure indiquant si l’erreur dans le ou les paramètres du nœud tombe en dessous d’un certain niveau ou d’un certain degré d’acceptabilité.

[0143] Dans l’étage d’apprentissage, l’algorithme reçoit des données expérimentales, c’est-à-dire de multiples points de données représentant différentes combinaisons possibles d’entrées dans le graphe. Au fur et à mesure que des données expérimentales sont reçues, l’algorithme ajuste progressivement les paramètres des divers nœuds 102 du graphe sur la base des données expérimentales de façon à essayer de minimiser les erreurs dans les paramètres. Le but est de trouver des valeurs des paramètres telles que la sortie du graphe soit la plus proche possible d’un résultat souhaité. Lorsque le graphe dans son ensemble tend vers un tel état, on dit que le calcul converge.

[0144] Par exemple, dans une approche supervisée, les données expérimentales d’entrée prennent la forme de données d’apprentissage, c’est-à-dire de données qui correspondent à des sorties connues. Avec chaque point de données, l’algorithme peut ajuster les paramètres de telle sorte que la sortie concorde le plus près possible avec la sortie connue pour l’entrée donnée. Dans l’étage de prédiction qui suit, le graphe peut alors être utilisé pour mapper une interrogation d’entrée vers une sortie prédite approximative (ou vice et versa si on fait une inférence). D’autres approches sont aussi possibles. Par exemple, dans une approche non supervisée, il n’y a pas de concept de résultat de référence par donnée d’entrée, et au lieu de cela on laisse l’algorithme d’intelligence artificielle identifier sa propre structure dans les données de sortie. Ou, dans une approche de renforcement, l’algorithme essaye au moins une sortie possible pour chaque point de données dans les données expérimentales d’entrée, et on lui dit si cette sortie est positive ou négative (et potentiellement un degré avec lequel elle est positive ou négative), par exemple gagné ou perdu, récompense ou punition, ou similaire. Sur de nombreux essais l’algorithme peut progressivement ajuster les paramètres du graphe pour être capable de prédire des entrées qui vont amener une sortie positive. Les diverses approches et algorithmes pour faire l’apprentissage d’un graphe sont connus de l’homme de l’art dans le domaine de l’intelligence artificielle.

[0145] Selon un exemple d’application des techniques décrites ici, chaque fil de travail est programmé pour réaliser les calculs associés à un nœud individuel respectif parmi les nœuds 102 dans un graphe d’intelligence artificielle. Dans ce cas, les arrêtes 104 entre les nœuds 102 correspondent aux échanges de données entre les fils, dont au moins certains peuvent impliquer des échanges entre pavés.

[0146] La figure 7 est un schéma illustrant la fonction d’un compilateur 70. Le compilateur reçoit un graphe comme le graphe 60 et compile les fonctions se trouvant dans les graphes en une multitude de codelets, qui sont contenus dans des programmes locaux référencés 72 en figure 7. Chaque programme local est conçu pour être chargé dans un pavé particulier de l’ordinateur. Chaque programme comprend un ou plusieurs codelets formant des fils de travail 72a, 72b... plus un sous-programme superviseur 73, chacun étant constitué d’une séquence d’instructions. Le compilateur génère les programmes de telle sorte qu’ils soient liés entre eux dans le temps, c’est-à-dire qu’ils soient déterministes dans le temps. Afin de réaliser cela, le compilateur accède à des données de pavés 74 qui comprennent les identifiants de pavés décrits précédemment qui sont indicatifs de l’emplacement des pavés et par conséquent les délais que le compilateur doit comprendre afin de générer les programmes locaux. Les délais ont déjà été mentionnés précédemment, et peuvent être calculés sur la base des données de pavés. En variante, les données de pavés peuvent incorporer une structure de données dans laquelle ces délais sont disponibles par l’intermédiaire d’une table de correspondance. Le programme superviseur comprend du code d’échange qui gère l’échange de données dans la phase d’échange.

[0147] Va suivre maintenant une description d’instructions qui ont été développées comme faisant partie du jeu d’instructions de l’architecture informatique définie ici. La figure 8 représente une instruction SEND de 32 bits. Une instruction SEND indique une transmission de données à partir de la mémoire de pavé. Elle amène une ou plusieurs données mémorisées au niveau d’une adresse particulière dans la mémoire locale 22 d’un pavé à être émises au niveau de l’interface exout d’un pavé. Chaque donnée (appelée élément dans l’instruction) peut avoir une longueur d’un ou plusieurs mots. Une instruction SEND agit sur un ou plusieurs mots pour mettre en œuvre une fonction d’envoi. L’instruction SEND comporte un code opération 80, un champ 82 indiquant un compte de messages, le nombre d’éléments à envoyer sous la forme d’un ou plusieurs paquets à partir de l’adresse SEND indiquée dans un champ d’adresse 84. Le champ 84 définit l’adresse dans la mémoire locale à partir de laquelle les éléments doivent être envoyés sous la forme d’une valeur immédiate qui est ajoutée à une valeur de base stockée dans un registre d’adresse de base. L’instruction SEND comporte aussi un champ de commande d’envoi 86 (SCTL) qui indique la taille de mot, sélectionnée à 4 ou 8 multiplets. Le paquet ne comporte pas d’identifiant de destination en lui. En d’autres termes, le pavé récepteur qui doit recevoir les éléments n’est pas identifié de façon unique dans l’instruction. La fonction d’envoi fait en sorte que le nombre spécifié d’éléments de données provenant de l’adresse d’envoi soient accédés à partir de la mémoire locale et placés au niveau de l’interface ex_out du pavé pour être transmis au cycle d’horloge suivant. Dans une autre variante de l’instruction SEND, l’adresse à partir de laquelle des éléments doivent être envoyés pourrait être implicite, prise à partir d’une valeur de base dans le registre d’adresse de base et d’une valeur de delta dans un registre de delta sortant. La valeur de delta peut être réglée sur la base d’informations se trouvant dans une instruction SEND précédente. A la place d’un identifiant unique du pavé destinataire visé, le compilateur s’est arrangé pour que le pavé destinataire correct commute son ou ses multiplexeurs locaux à l’instant correct pour recevoir la donnée (des éléments de données) comme cela a déjà été décrit ici. On notera qu’un pavé destinataire visé pourrait être le pavé émetteur lui-même dans certains cas.

[0148] On va faire référence à la figure 12, qui montre un exemple de champ de commande d’envoi 86 (SCTL), qui peut être incorporé dans une instruction d’envoi. Le SCTL 86 peut inclure une indication de taille de mot 122, qui peut indiquer une valeur de 32 bits ou de 64 bits pour la taille de mot. Le SCTL 86 peut aussi inclure une indication 124 d’au moins une direction dans laquelle la donnée doit être passée/transmise dans le tissu de commutation 34, comme cela a été décrit précédemment. L’indication 124 de ladite au moins une direction peut comprendre une indication 126 indiquant si la donnée doit être transmis ou non dans une première direction dans le tissu de commutation 34 à partir du pavé émetteur, et une indication 128 indiquant si la donnée doit ou non être transmise dans une seconde direction dans le tissu de commutation 34 à partir du pavé émetteur. Chacune des indications 126 et 128 peut être représentée par un seul bit.

[0149] Lorsque l’instruction d’envoi est exécutée, l’indication 124 de ladite au moins une direction peut être incluse dans une donnée qui est ensuite transmise sur le tissu de commutation.

[0150] Si une instruction d’envoi est émise pour émettre une donnée vers un ou plusieurs pavés récepteurs qui sont situés dans la première direction à partir du pavé émetteur, alors l’indication 124 de ladite au moins une direction peut contenir une indication 126 indiquant que la donnée doit être transmise dans la première direction à partir du pavé émetteur. S’il n’y a pas de pavés pour recevoir la donnée qui sont situés dans la deuxième direction à partir du pavé émetteur, alors l’indication 124 de ladite au moins une direction peut contenir une indication 128 indiquant que la donnée ne doit pas être transmise dans la deuxième direction à partir du pavé émetteur. Dans ce cas, le tissu de commutation 34 laisse passer la donnée seulement dans la première direction et il l’empêche de passer dans la deuxième direction. Dans certains exemples, la donnée peut être transmises seulement aussi loin que se trouve ledit au moins un multiplexeur qui est destiné à recevoir la donnée. Dans ce cas, la donnée peut ne pas être transmise plus loin dans le tissu de commutation 34 dans la première direction au-delà dudit au moins un multiplexeur qui est destiné à recevoir la donnée.

[0151] Si une instruction d’envoi est émise pour transmettre une donnée vers un ou plusieurs pavés récepteurs qui sont situés dans une deuxième direction à partir du pavé émetteur, alors l’indication 124 de ladite au moins une direction peut contenir une indication 128 indiquant que la donnée doit être transmise dans la deuxième direction à partir du pavé émetteur. S’il n’y a pas de pavés pour recevoir la donnée qui sont situés dans la première direction 126 à partir du pavé émetteur, alors l’indication 124 de ladite au moins une direction peut contenir une indication 126 indiquant que la donnée ne doit pas être transmise dans la première direction à partir du pavé émetteur. Dans ce cas, le tissu de commutation 34 laisse passer la donnée seulement dans la deuxième direction et l’empêche de passer dans la première direction. Dans certains exemples, la donnée peut être transmise seulement aussi loin que se trouve ledit au moins un multiplexeur qui est destiné à recevoir la donnée. Dans ce cas, la donnée peut ne pas être transmise plus loin, dans le tissu de commutation 34 dans la deuxième direction, que ledit au moins un multiplexeur qui est destiné à recevoir la donnée.

[0152] Si une instruction d’envoi est émise pour émettre vers une pluralité de pavés récepteurs, dont au moins l’un est situé dans la première direction à partir du pavé émetteur et dont au moins l’un est situé dans la deuxième direction à partir du pavé émetteur, l’indication 124 de ladite au moins une direction peut contenir une indication 126 indiquant que la donnée doit être transmise dans la première direction à partir du pavé émetteur et une indication 128 indiquant que la donnée doit être transmise dans la deuxième direction à partir du pavé émetteur. Dans ce cas, la donnée est transmise dans le tissu de commutation 34 dans la première direction et dans la deuxième direction.

[0153] Dans certains cas, l’indication 124 de ladite au moins une direction peut comprendre une indication 126 indiquant que la donnée ne doit pas être transmise dans la première direction et une indication 128 indiquant que la donnée ne doit pas être transmises dans la deuxième direction. Dans ce cas, en réponse à l’exécution de l’instruction d’envoi du processeur d’un pavé, il se peut qu’aucune donnée ne soit transmise. Dans certains cas, l’exécution d’une telle instruction d’envoi peut provoquer le signalement d’une exception.

[0154] Dans le cas où l’indication de ladite au moins une direction qui est insérée dans une donnée contient des indications indiquant que la donnée doit être transmise dans la première direction et la deuxième direction, le tissu de commutation peut être configuré pour laisser passer la donnée dans les deux directions. Une fois que la donnée atteint un multiplexeur d’un pavé auquel elle doit être fournie, dans ce cas, elle continue dans le tissu de commutation sans être bloquée au niveau du multiplexeur.

[0155] Dans le cas où l’indication de ladite au moins une direction qui est insérée dans une donnée contient une indication indiquant que la donnée doit être transmise dans seulement l’une de la première direction et de la deuxième direction, le tissu de commutation peut être configuré pour laisser passer la donnée seulement dans la direction qui est indiquée, vers le premier multiplexeur d’un pavé récepteur. La donnée peut être bloquée pour l’empêcher de passer dans le tissu de commutation au-delà du premier multiplexeur.

[0156] Par conséquent, afin de transmettre une donnée à de multiples pavés récepteurs, même si ces pavés récepteurs sont tous dans la même direction à partir du pavé émetteur, le pavé émetteur peut être agencé pour insérer dans la donnée des indications indiquant que la donnée doit être transmise dans la première direction et la deuxième direction, afin que la donnée ne soit pas bloquée au niveau du premier multiplexeur de réception.

[0157] Afin d’assurer que le pavé destinataire correct va commuter son multiplexeur local à l’instant correct pour recevoir la donnée, une fonction de contrôle de commutateurs est prévue, comme cela a été décrit précédemment. La figure 9 illustre une instruction PUT-i-MUX qui réalise cette fonction. Un champ de code opération 90 définit l’instruction comme étant une instruction PUT-i-MUX. Une période de délai peut être spécifiée par une valeur immédiate de délai 92. Cette valeur de délai peut est utilisée pour remplacer les instructions ‘no op’, et est une façon d’optimiser la compression de code. Cette instruction, lorsqu’elle est exécutée, définit dans le champ incoming_mux 98 quelle entrée du multiplexeur 210 doit être sélectionnée pour ‘écouter’ des éléments qui ont été envoyés à partir d’un autre pavé. Dans un but de compacité, cette fonction de contrôle de multiplexeur pourrait être combinée dans une seule instruction avec une fonction d’envoi définie précédemment, comme cela est présenté en figure 10. On notera qu’il n’y a pas de connexion entre la fonction d’envoi, qui amène le pavé à se comporter comme un pavé émetteur, et la fonction de contrôle de commutateurs, qui est une fonction servant lorsque le pavé se comporte comme un pavé destinataire, autre que celles qui peuvent être réalisées dans un seul cycle d’exécution sur le même pavé.

[0158] La figure 10 est un exemple d’instruction à fusion. Dans ce contexte, une instruction à fusion désigne une instruction qui définit deux ou plusieurs fonctions qui peuvent être réalisées en même temps (dans un seul cycle d’exécution) sur un pavé.

[0159] Figure 10 illustre une forme d’instruction d’envoi à ‘fusion’, dans laquelle une fonction d’envoi est combinée avec une deuxième fonction qui peut modifier l’état maintenu dans des registres au niveau du pavé. Une première fonction consiste à changer le pointeur mémoire pour des données reçues au niveau de ce pavé. Une autre fonction consiste à régler le MUX entrant. La fonction PUTi_MEMptr permet d’identifier un emplacement mémoire se trouvant dans la mémoire locale, où doit être chargée la donnée suivante reçue par le pavé. Cette fonction pourrait être réalisée par une instruction de ‘réception’ dédiée, bien que sa fonction ne soit pas de permettre la réception d’une donnée mais de modifier le pointeur mémoire. En fait, aucune instruction spécifique ne doit être exécutée pour recevoir des données au niveau d’un pavé. Les données arrivant au niveau de l’interface exin vont être chargée dans l’emplacement mémoire suivant identifié par le pointeur mémoire, sous le contrôle de l’interface exin. L’instruction de la figure 10 comporte un champ de code opération 100 et un champ 102 indiquant un nombre d’éléments à envoyer. La valeur immédiate se trouvant dans le champ de modification d’état entrant 106 est écrite dans un registre d’état de configuration d’échange spécifié par le champ 104. Dans une première forme, le champ de modification d’état 106 peut écrire un delta entrant pour calculer l’adresse de réception à laquelle le pointeur mémoire doit être réglé. Dans une autre forme, l’état de configuration d’échange est écrit avec la valeur de multiplexeur MUX d’entrée qui règle l’entrée de multiplexeur.

[0160] Pour cette forme d’instructions à fusion, la fonction d’envoi utilise une adresse d’envoi, déterminée à partir de valeurs stockées dans un ou plusieurs registres, qui est implicite dans l’instruction. Par exemple, l’adresse d’envoi peut être déterminée à partir du registre de base et du registre de delta.

[0161] La figure 11 représente une instruction à double largeur, appelée instruction d’échange (EXCH). Cette instruction lance une transmission de données à partir d’une adresse indiquée dans la mémoire du pavé et règle l’état de configuration d’échange entrant (le multiplexeur et/ou le pointeur mémoire pour recevoir des données). L’instruction EXCH est unique en ce qu’elle est immédiatement suivie d’une charge utile de 32 bits en ligne, située à l’emplacement mémoire situé immédiatement après les instructions. L’instruction EXCH comporte un champ de code opération 110 qui indique une instruction d’échange EXCH. La charge utile comporte un drapeau de ‘co-émission’ 119.

[0162] L’instruction EXCH comprend un champ de format 112 qui comporte un seul bit qui spécifie la largeur de donnée du format entrant (32 bits ou 64 bits). La largeur de donnée peut avoir des implications sur la mise en place des lignes de multiplexeur (qu’elles soient réglées individuellement ou par paires). Un champ d’éléments 114 définit le nombre d’éléments dont l’instruction d’échange va provoquer l’envoi. Ces éléments sont envoyés à partir d’une adresse d’envoi calculée en utilisant la valeur immédiate dans le champ 116, comme dans l’instruction d’envoi de la figure 9. La valeur de ce champ est ajoutée à la valeur se trouvant dans le registre de base.

[0163] La référence numérique 118 désigne un champ de commande qui définit la taille de mot pour la donnée envoyée. La charge utile comprend un champ de contrôle de commutateur 120 qui agit comme contrôle de commutateur pour le multiplexeur entrant, comme cela a été décrit précédemment en relation avec la figure 9. La référence 122 indique un champ de la charge utile définissant un delta entrant pour calculer l’adresse à laquelle les données entrantes doivent être mémorisées, comme décrit précédemment en relation avec l’instruction de la figure 10. L’instruction d’échange de 64 bits de large EXCH de la figure 11 peut être exécutée à chaque cycle d’horloge et ainsi permet simultanément :

- l’envoi à partir d’une adresse particulière - la mise à jour d’un multiplexeur d’entrée - la mise à jour d’une adresse d’entrée

[0164] Ainsi, tout schéma d’échange peut être codé dans une seule instruction. Les instructions des figures 8, 9 et 10 réalisent des fonctions similaires mais puisqu’elles ont seulement une longueur de 32 bits, elles peuvent être utilisées pour minimiser la taille du code d’échange dans la mémoire locale de chaque pavé. La décision pour savoir quelle instruction utiliser dans un contexte particulier est prise au niveau du compilateur 70 lors de la construction des codelets pour le programme local 72.

[0165] Va suivre une liste de registres clés et leur signification pour prendre en charge les instructions susmentionnées. Ces registres font partie du banc de registres présent sur chaque pavé.

[0166]

[Tableaux 1]

TILEID	Contient un identifiant unique pour ce pavé.
INCOMING_MUX [INCOMING_MUXPAIR]	Contient l’ID de pavé du pavé source pour des messages entrants, qui agit pour sélectionner l’entrée ‘d’écoute’ pour le multiplexeur associé au pavé récepteur. [Lorsque les entrées sont par paires, cela implique un élément de données de 64 bits].
INCOMING_DELTA INCOMING_BASE	Contient une valeur d’auto-incrémentation pour calculer l’adresse à laquelle des données entrantes doivent être mémorisées : elle peut être écrasée par un champ explicite [voir par exemple figure 10]. Elle est ajoutée à INCOMING_BASE. Contient une adresse de base commune pour mettre à jour un pointeur mémoire (ajoutée à INCOMING_DELTA).
OUTGOING_BASE	Contient une adresse de base commune pour des instructions d’envoi.
OUTGOING_DELTA	Contient un delta pour calculer des instructions d’adresse d’envoi. Une adresse d’ ‘envoi’ est égale à base sortante + delta sortant.
INCOMING_FORMAT	Identifie une donnée entrante de 32 bits ou 64 bits.

[0167] On notera que les registres INCOMING_DELTA et INCOMING_MUX font partie de l’état d’échange du pavé.

[0168] On a décrit ici une technique pour optimiser l’utilisation d’unités de traitement dans un nouveau paradigme d’ordinateur qui est particulièrement efficace dans le contexte des modèles de connaissance pour l’apprentissage automatique. On prévoit une architecture qui utilise le déterminisme temporel comme dans une phase d’échange d’un paradigme BSP pour traiter efficacement de très grandes quantités de données. Bien qu’on ait décrit des modes de réalisation particuliers, d’autres applications et variantes des techniques décrites pourront apparaître à l’homme de l’art une fois la description faite.

Claims (1)

1. Revendications [Revendication 1] Ordinateur comprenant : - une pluralité d’unités de traitement, chacune comportant une interface d’entrée munie d’un ensemble de fils d’entrée, et une interface de sortie munie d’un ensemble de fils de sortie ; - un tissu de commutation connecté à chacune des unités de traitement par l’ensemble respectif de fils de sortie et connectable à chacune des unités de traitement par l’ensemble respectif de fils de sortie et connectable à chacune des unités de traitement par les fils d’entrée respectifs par l’intermédiaire de circuits de commutation contrôlables par son unité de traitement associée ; - les unités de traitement étant agencées en colonnes, chaque colonne comportant une unité de traitement de base à proximité du tissu de commutation et de multiples d’unités de traitement adjacentes les unes aux autres dans des positions respectives dans la direction de la colonne, dans lequel pour mettre en œuvre un échange de données entre les unités de traitement au moins une unité de traitement est agencée pour émettre à un instant d’émission un paquet de données destiné à une unité de traitement destinataire sur son ensemble de fils de connexion de sortie, le paquet de données ne comportant aucun identifiant de destination de l’unité de traitement destinataire mais étant destiné à être reçu au niveau de l’unité de traitement destinataire avec un délai prédéterminé par rapport à l’instant d’émission, dans lequel le délai prédéterminé dépend d’un chemin d’échange entre les unités de traitement émettrice et destinataire, dans lequel le chemin d’échange entre une paire quelconque d’unités de traitement émettrice et destinataire à des positions respectives dans une colonne a le même délai que le chemin d’échange entre chaque paire d’unités de traitement émettrice et destinataire situées à des positions respectives correspondantes dans les autres colonnes. [Revendication 2] Ordinateur selon la revendication 1, dans lequel le chemin d’échange physique comprend une composante de chemin qui s’étend à partir d’une unité de traitement respective dans la colonne jusqu’à la base de la colonne. [Revendication 3] Ordinateur selon la revendication 1 ou 2, dans lequel le tissu de commutation comprend une pluralité de groupes de fils d’échange, chaque groupe comportant des fils connectés aux fils de sortie d’unités de traitement se trouvant dans chaque colonne respective.

   [Revendication 4] Ordinateur selon la revendication 3, dans lequel une première des colonnes est éloignée de son groupe de fils respectif d’une première distance physique, et une deuxième des colonnes est éloignée de son groupe de fils correspondant d’une deuxième distance physique, la deuxième distance physique étant supérieure à la première distance physique, dans lequel un délai de compensation est prévu dans une composante de chemin entre colonne et tissu de commutation entre la première colonne et le premier groupe de fils correspondant, d’où il résulte que le délai de chemin entre colonne et tissu de commutation de la première colonne est le même que le délai de chemin entre colonne et tissu de commutation de la deuxième colonne. [Revendication 5] Ordinateur selon la revendication 4, dans lequel le délai de compensation comprend un circuit de retard de compensation de sortie agencé dans l’ensemble de fils de connexion de sortie de chaque unité de traitement se trouvant dans la première colonne. [Revendication 6] Ordinateur selon la revendication 4 ou 5, dans lequel le délai de compensation comprend un circuit de retard de compensation d’entrée agencé dans l’ensemble de fils d’entrée pour chaque pavé se trouvant dans la première colonne. [Revendication 7] Ordinateur selon la revendication 6, comprenant un délai de compensation de commutation dans un ensemble de fils de commande de commutation qui s’étend à partir de chaque unité de traitement jusqu’à ses circuits de commutation correspondants, la compensation de délai de commutation étant déterminée de façon à ce que la somme du circuit de compensation de délai d’entrée et de la compensation de délai de commande de commutation soit identique pour chaque colonne. [Revendication 8] Ordinateur selon l’une quelconque des revendications précédentes, dans lequel le tissu de commutation s’étend dans une première direction, et chaque colonne s’étend dans une deuxième direction perpendiculaire à la première direction. [Revendication 9] Ordinateur selon l’une quelconque des revendications précédentes, qui comprend n colonnes situées sur un côté du tissu de commutation et n colonnes située sur l’autre côté du tissu de commutation et s’éloignant du tissu de commutation dans d’une direction inverse. [Revendication 10] [Revendication 11] Ordinateur selon la revendication 9, dans lequel n est égal à 8. Ordinateur selon les revendications 3 et 9, dans lequel chacune des n colonnes situées sur le premier côté du tissu de commutation est associée à des groupes de fils respectifs dans une première moitié du

   tissu de commutation, et dans lequel chacune des n colonnes situées de l’autre côté du tissu de commutation est associée à des groupes de fils respectifs dans l’autre moitié du tissu de commutation. [Revendication 12] Ordinateur selon l’une quelconque des revendications précédentes, dans lequel le chemin d’échange comprend une composante de chemin entre base de colonne et pavé, basée sur la distance dans la colonne de l’unité de traitement respective par rapport à l’unité de traitement de base. [Revendication 13] Ordinateur selon l’une quelconque des revendications précédentes, dans lequel chaque unité de traitement comporte un stockage d’instructions contenant un programme local comprenant du code d’échange, une unité d’exécution agencée pour exécuter le programme local et un stockage de données pour contenir des données, dans lequel le code d’échange d’une unité de traitement à une première position dans l’une des colonnes est le même que le code d’échange d’une unité de traitement dans la même position respective d’une autre colonne. [Revendication 14] Ordinateur selon la revendication 13, dans lequel le code d’échange comprend une instruction SEND qui provoque l’émission du paquet de données à l’instant d’émission vers une unité de traitement destinataire dans la même colonne. [Revendication 15] Ordinateur selon la revendications 13 ou 14, comprenant un module de synchronisation actionnable pour générer un signal de synchronisation pour contrôler l’ordinateur pour commuter entre une phase de calcul et une phase d’échange, dans lequel les unités de traitement sont agencées pour exécuter leurs programmes locaux en accord avec une horloge commune, les programmes locaux étant tels que ladite au moins une unité de traitement est agencée pour émettre le paquet de données dans la phase d’échange. [Revendication 16] Ordinateur selon la revendication 15, dans lequel le signal de synchronisation est reçu au niveau de chaque colonne par l’intermédiaire d’un étage de retard de synchronisation respectif de sorte que le signal de synchronisation est reçu au niveau de chaque unité de traitement dans l’ordinateur au même instant.

   1/9