FR 3162887 A1 20251205 FR 2405726 A 20240531 L’invention concerne l’exécution d’un réseau de neurones comportant au moins N couches successives C_i, i = 1 à N, dans un accélérateur (1) comprenant : - une matrice (11) de nœuds de calcul (14) comprenant chacun un routeur ; - une ou plusieurs rangée de mémoires tampons locales (13) reliées chacune à un routeur d’un nœud de calcul qui lui est associé ; les routeurs étant adaptés pour router les données, à travers la matrice, en fonction d’un mot de contrôle associé à chaque donnée ; au cours de l’exécution de la couche C_i par l’accélérateur : - avant que lesdites données de sortie ofmap de la couche C _ i ne soient stockées dans lesdites mémoires tampons locales (13), un bloc d’emballage (16) détermine, en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour les données d’entrée ifmap de la couche C_i+1 correspondant aux données de sortie ofmap de la couche C_i ; - puis lesdites données de sortie ofmap sont insérées dans des paquets de données stockées dans lesdites mémoires tampons locales (13) avec les mots de contrôle ainsi déterminés pour la couche C_i+1. Procédé et dispositif de traitement parallèle et adaptatif de flux de données de réseaux de neurones profonds L’invention se situe dans le domaine de l’intelligence artificielle et des réseaux de neurones profonds et plus particulièrement dans le domaine de l’accélération du calcul d’inférence par les réseaux de neurones, par exemple convolutifs. Les algorithmes d'intelligence artificielle (IA) constituent actuellement un vaste domaine de recherche, car ils sont destinés à devenir des composants essentiels des applications de la prochaine génération, s'appuyant sur des processus intelligents pour prendre des décisions basées sur la connaissance de leur environnement, relativement par exemple à la détection d'objets tels que des piétons pour une voiture à conduite autonome ou la reconnaissance d'activité pour une montre intelligente de suivi de la santé. Cette connaissance est recueillie par des capteurs associés avec des algorithmes de détection et/ou de reconnaissance très performants. En particulier, les réseaux de neurones profonds (DNN pour Deep Neural Network en anglais) et parmi eux, notamment les réseaux de neurones convolutifs (CNN pour Convolutional Neural Network en anglais - voir par exemple Y. Lecun et al. 1998. Gradient-based learning applied to document recognition. Proc. IEEE 86, 11 (Nov. 1998), 2278–2324) sont de bons candidats pour être intégrés dans de tels systèmes en raison de leurs excellentes performances dans les tâches de détection et de reconnaissance. Ils sont basés sur des couches de filtres qui effectuent l'extraction de caractéristiques, puis la classification. Ces opérations nécessitent beaucoup de calculs et de mémoire, et l'intégration de tels algorithmes dans les systèmes requiert l'utilisation d'accélérateurs. Ces accélérateurs sont des dispositifs électroniques qui calculent principalement en parallèle de nombreuses opérations, par exemple de multiplication-accumulation (MAC) dans les algorithmes CNN. L'objectif de ces accélérateurs est d'améliorer les performances d'exécution des algorithmes DNN pour répondre aux contraintes applicatives et améliorer l'efficacité énergétique du système. Ils sont principalement basés sur un nombre élevé d'éléments de traitement impliquant des opérateurs optimisés pour l’exécution des opérations et une hiérarchie mémoire permettant un stockage efficace des données. Dans l’application aux CNN, la plupart des accélérateurs matériels sont basés sur un réseau de processeurs élémentaires (Processing Elements - PEs) implémentant des MAC et utilisent des mémoires tampon locales pour stocker les données qui sont fréquemment réutilisées, comme les paramètres des filtres ou les données intermédiaires. Les communications entre les PE eux-mêmes et celles entre les PEs et la mémoire sont un aspect très important à considérer lors de la conception d'un accélérateur CNN. En effet, les algorithmes CNN ont un parallélisme intrinsèque élevé ainsi que des possibilités de réutilisation des données. L'infrastructure de communication sur puce doit donc être conçue avec soin pour exploiter le nombre élevé de PEs et les particularités des algorithmes CNN, qui permettent d'améliorer à la fois les performances et l'efficacité énergétique. Par exemple, le multicast ou le broadcast de données particulières dans le réseau de communication permettra aux PEs cibles de traiter simultanément différentes données avec le même filtre en utilisant une seule lecture mémoire. Plusieurs facteurs ont contribué à limiter ou à complexifier l’évolutivité et la flexibilité des accélérateurs CNN existant sur le marché. Ces facteurs se manifestent à travers : (i) une bande passante limitée liée à l’absence d’un support de diffusion efficace, (ii) un surconsommation d’énergie lié à la taille de la mémoire (ex : 40% de la consommation d’énergie dans certaines architectures est induite par la mémoire) et au problème de mur de capacité mémoire (iii) ainsi qu’une réutilisation limitée des données et un besoin de support efficace pour le traitement des différents modes de communication. Il existe donc un besoin d’augmenter l’efficacité du traitement dans les accélérateurs de neurones des architectures DNN, tenant compte du nombre élevé de PEs et dans le cas CNN, des particularités des algorithmes CNN. A cet effet, suivant un premier aspect, la présente invention décrit un procédé de traitement pour l’exécution d’un réseau de neurones comportant au moins N couches successives de réseau de neurones C_i, i = 1 à N, avec N>1, dans un accélérateur de réseau de neurones ; l’accélérateur de réseau de neurones comprenant : - un bloc de contrôle global, - une matrice de nœuds de calcul, chaque nœud comprenant un routeur et un élément de traitement, dit encore PE associé à un ensemble de registres mémoires locaux respectifs, l’élément de traitement, permettant d’effectuer des opérations de calcul parmi des multiplications et des accumulations de données stockées dans ses registres, le routeur permettant de réaliser plusieurs routages de données indépendants en parallèle vers des sorties distinctes du routeur, les routeurs étant reliés les uns aux autres ; - au moins une rangée de mémoires tampons locales, chaque rangée de mémoire tampon locale étant positionnée sur un côté de la matrice de nœuds de calcul, et chaque mémoire tampon locale est reliée à un routeur d’un nœud de calcul qui lui est associé ; les routeurs étant adaptés pour router les données, à travers la matrice des nœuds de calcul en parallèle de l’exécution par les nœuds de calcul, en fonction d’un mot de contrôle associé à chaque donnée ; selon lequel au début de l’exécution par l’accélérateur d’une couche C_i, des données d’entrée ifmap de la couche sont extraites de certaines au moins desdites mémoires tampons locales et sont fournies, avec leur mot de contrôle associé, aux routeurs des nœuds de calcul associées ; selon lequel au cours de l’exécution de la couche C_i par l’accélérateur, des données de sortie ofmap de la couche C _i issues de données délivrées par les routeurs de nœuds de calcul associés à des mémoires tampons locales sont stockées dans lesdites mémoires tampons locales ; ledit procédé étant caractérisé en ce que l’accélérateur comporte en outre un bloc d’emballage disposé entre certaines au moins des mémoires tampons locales et les nœuds associés audites mémoires tampons locales, et ledit bloc d’emballage détermine le mot de contrôle associé aux données d’entrée ifmap de la couche C_i+1 en fonction d’un mot de configuration défini pour ladite couche C_i+1, lors de la mise en œuvre de l’une ou l’autre des dispositions suivantes i et j dans l’accélérateur : disposition i/ i1/ au cours de l’exécution de la couche C_i par l’accélérateur : - avant que lesdites données de sortie ofmap de la couche C _ i ne soient stockées dans lesdites mémoires tampons locales, ledit bloc d’emballage détermine, en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour chacune des données d’entrée ifmap de la couche C_i+1 lesquelles correspondent aux données de sortie ofmap de la couche C_i ; - puis lesdites données de sortie ofmap sont insérées dans des paquets de données stockées dans lesdites mémoires tampons locales avec les mots de contrôle associés ainsi déterminés pour la couche C_i+1 par le bloc d’emballage ; i2/ au début de l’exécution de la couche C_i+1 par l’accélérateur, lesdites données d’entrée ifmap de la couche sont extraites des mémoires tampons locales où elles étaient stockées depuis l’étape i1 et sont fournies, avec leur mot de contrôle associé pour la couche C_i+1, aux routeurs des nœuds de calcul auxquels lesdites mémoires tampons locales sont associées ; disposition j/ j1/ au début de l’exécution de la couche C_i+1 par l’accélérateur, les données de sortie ofmap de la couche C _i ayant été stockées dans lesdites mémoires tampons locales à la fin de l’exécution de la couche C_i, ledit bloc d’emballage détermine en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour la couche C_i+1, qui sont associés aux données d’entrée ifmap de la couche C_i+1, lesquelles correspondent aux données de sortie ofmap ; j2/ puis lesdites données d’entrée ifmap de la couche extraites des mémoires tampons locales où elles étaient stockées depuis la fin de l’exécution de la couche C_i sont insérées dans des paquets avec leur mot de contrôle associé déterminé pour la couche C_i+1, et sont ainsi fournies aux routeurs des nœuds de calcul auxquels lesdites mémoires tampons locales sont associées. Dans des modes de réalisation, un tel procédé comprendra en outre l’une au moins des caractéristiques suivantes : - la détermination du mot de contrôle pour une donnée pour la couche C_i+1 est effectuée en fonction au moins d’un champ du mot de configuration indiquant le type de couche C_i+1 et de la mémoire tampon locale stockant la donnée ofmap correspondant à la donnée ifmap de la couche C_i+1 ; - la détermination du mot de contrôle pour une donnée pour la couche C_i+1 est effectuée en fonction au moins d’au moins un élément parmi la position de ladite mémoire tampon locale et la position du nœud associé à ladite mémoire tampon locale ; - le mot de contrôle déterminé indique un type de communication parmi unicast, broadcast, multicast diagonal, multicast vertical, multicast horizontal et indique en outre un sens si le type de communication est multicast ; - plusieurs desdites données associés à un même mot de contrôle et délivrées par un même nœud de calcul sont insérées dans un paquet de données commun associé audit mot de contrôle déterminé par le bloc d’emballage. Suivant un autre aspect, l’invention décrit un accélérateur de réseau de neurones adapté pour l’exécution d’un réseau de neurones comportant au moins N couches successives de réseau de neurones C_i, i = 1 à N, avec N>1, l’accélérateur de réseau de neurones comprenant : - un bloc de contrôle global, - une matrice de nœuds de calcul, chaque nœud comprenant un routeur et un élément de traitement, dit encore PE associé à un ensemble de registres mémoires locaux respectifs, l’élément de traitement étant adapté pour effectuer des opérations de calcul parmi des multiplications et des accumulations de données stockées dans ses registres, le routeur étant adapté pour réaliser plusieurs routages de données indépendants en parallèle vers des sorties distinctes du routeur, les routeurs étant reliés les uns aux autres ; - au moins une rangée de mémoires tampons locales, chaque rangée de mémoire tampon locale étant positionnée sur un côté de la matrice de nœuds de calcul, et chaque mémoire tampon locale est reliée à un routeur d’un nœud de calcul qui lui est associé ; les routeurs étant adaptés pour router les données, à travers la matrice des nœuds de calcul en parallèle de l’exécution par les nœuds de calcul, en fonction d’un mot de contrôle associé à chaque donnée ; ledit accélérateur étant adapté pour que, au début de l’exécution par l’accélérateur d’une couche C_i, des données d’entrée ifmap de la couche soient extraites de certaines au moins desdites mémoires tampons locales et soient fournies, avec leur mot de contrôle associé, aux routeurs des nœuds de calcul associées et pour que au cours de l’exécution de la couche C_i par l’accélérateur, des données de sortie ofmap de la couche C _i issues de données délivrées par les routeurs de nœuds de calcul associés à des mémoires tampons locales soient stockées dans lesdites mémoires tampons locales ; ledit accélérateur étant caractérisé en ce qu’il comporte en outre un bloc d’emballage disposé entre certaines au moins des mémoires tampons locales et les nœuds associés audites mémoires tampons locales, et ledit bloc d’emballage est adapté pour déterminer le mot de contrôle associé aux données d’entrée ifmap de la couche C_i+1 en fonction d’un mot de configuration défini pour ladite couche C_i+1, lors de la mise en œuvre de l’une ou l’autre des dispositions suivantes i et j dans l’accélérateur : disposition i/ i1/ au cours de l’exécution de la couche C_i par l’accélérateur : - avant que lesdites données de sortie ofmap de la couche C _ i ne soient stockées dans lesdites mémoires tampons locales, ledit bloc d’emballage est adapté pour déterminer, en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour chacune des données d’entrée ifmap de la couche C_i+1 lesquelles correspondent aux données de sortie ofmap de la couche C_i ; - l’accélérateur étant adapté pour lesdites données de sortie ofmap soient ensuite insérées dans des paquets de données stockées dans lesdites mémoires tampons locales avec les mots de contrôle associés ainsi déterminés pour la couche C_i+1 par le bloc d’emballage ; i2/ au début de l’exécution de la couche C_i+1 par l’accélérateur, ledit accélérateur est adapté pour que lesdites données d’entrée ifmap de la couche soient extraites des mémoires tampons locales où elles étaient stockées depuis l’étape i1 et soient fournies, avec leur mot de contrôle associé pour la couche C_i+1, aux routeurs des nœuds de calcul auxquels lesdites mémoires tampons locales sont associées ; disposition j/ j1/ au début de l’exécution de la couche C_i+1 par l’accélérateur, les données de sortie ofmap de la couche C _i ayant été stockées dans lesdites mémoires tampons locales à la fin de l’exécution de la couche C_i, ledit bloc d’emballage est adapté pour déterminer en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour la couche C_i+1, qui sont associés aux données d’entrée ifmap de la couche C_i+1, lesquelles correspondent aux données de sortie ofmap ; j2/ l’accélérateur est adapté pour que lesdites données d’entrée ifmap de la couche extraites des mémoires tampons locales où elles étaient stockées depuis la fin de l’exécution de la couche C_i soient ensuite insérées dans des paquets avec leur mot de contrôle associé déterminé pour la couche C_i+1, et soient ainsi fournies aux routeurs des nœuds de calcul auxquels lesdites mémoires tampons locales sont associées. Dans des modes de réalisation, un tel accélérateur comprendra en outre l’une au moins des caractéristiques suivantes : - le bloc d’emballage est adapté pour déterminer le mot de contrôle pour une donnée pour la couche C_i+1 en fonction au moins d’un champ du mot de configuration indiquant le type de couche C_i+1 et de la mémoire tampon locale stockant la donnée ofmap correspondant à la donnée ifmap de la couche C_i+1 ; - la détermination du mot de contrôle pour une donnée pour la couche C_i+1 est effectuée par le bloc d’emballage en fonction au moins d’au moins un élément parmi la position de ladite mémoire tampon locale et la position du nœud associé à ladite mémoire tampon locale ; - le mot de contrôle déterminé indique un type de communication parmi unicast, broadcast, multicast diagonal, multicast vertical, multicast horizontal et indique en outre un sens si le type de communication est multicast ; - plusieurs desdites données associés à un même mot de contrôle et délivrées par un même nœud de calcul (14) sont insérées dans un paquet de données commun associé audit mot de contrôle déterminé par le bloc d’emballage. Dans un mode de réalisation de l’invention, ledit procédé comprend en outre la disposition suivante : - un mécanisme de communication gère la communication des données à travers la matrice des nœuds de calcul en parallèle de l’exécution par les nœuds de calcul d’opérations de calcul ; un mot de configuration respectif a été préalablement défini pour chacune des N couches, le mot de configuration comporte au moins trois champs indiquant respectivement au moins le type de la couche C_i, le nombre de filtres et le nombre d’images d’entrée impliqués par ladite couche ; un mécanisme d’envoi des données, depuis une mémoire locale vers un nœud de calcul ou inversement, définit le ou les destinataires des données en fonction du mot de configuration courant ; le bloc de contrôle global comprend une machine à états finis orchestrant l’exécution de chaque couche C_i par la grille de nœuds et chaque nœud de calcul comprend une machine à états finis orchestrant les opérations du nœud et le stockage des données dans ses registres mémoires locaux, les machines à états finis des nœuds et du bloc de contrôle global se déroulant en parallèle, avec des points de synchronisation entre elles, lors de l’exécution d’une couche lancée par le bloc de contrôle global ; et ledit procédé comprend les étapes suivantes : avant l’exécution successive de chaque couche C_i, le bloc de contrôle global obtient le mot de configuration respectif défini pour la couche C_i et configure sa machine à états finis en fonction desdits au moins trois champs dans ledit mot de configuration ; le déroulement de la machine à états finis du bloc de contrôle global comprend l’envoi aux nœuds d’au moins une partie dudit mot de configuration défini pour la couche et chaque nœud configure sa machine à états finis en fonction d’au moins ladite partie dudit mot de configuration qui lui a été envoyé. Dans des modes de réalisation, un tel procédé comprendra en outre l’une au moins des caractéristiques suivantes : - la machine à états finis du bloc de contrôle global comprend au moins les états suivants : chargement des données de filtre ; chargement des données d’une image d’entrée ; attente de la fin d’exécution des calculs fonction des données chargées de filtres et des données chargées d’une image d’entrée ; la configuration de sa machine à états finis par le bloc de contrôle global comprenant la définition des transitions entre lesdits états en fonction desdits au moins trois champs dans ledit mot de configuration ; - lesdites opérations de calcul effectuées par l’élément de traitement sont mises en œuvre par une ou plusieurs portes logiques programmables dynamiquement implémentées sur FPGA ; - le mot de configuration indique en outre un nombre d’opérateurs MAC par élément de traitement et chaque nœud, avant l’exécution de ladite couche, programme dynamiquement une ou plusieurs portes logiques en fonction dudit nombre figurant dans ladite partie dudit mot de configuration qui lui a été envoyé. Similairement, dans un mode de réalisation, dans l’accélérateur selon l’invention, un mécanisme de communication est adapté pour gérer la communication des données à travers la matrice des nœuds de calcul en parallèle de l’exécution par les nœuds de calcul d’opérations de calcul ; un mot de configuration respectif ayant été préalablement défini pour chacune des N couches, le mot de configuration comportant au moins trois champs indiquant respectivement au moins le type de la couche C_i, le nombre de filtres et le nombre d’images d’entrée impliqués par ladite couche, ledit accélérateur comprend un mécanisme d’envoi des données, depuis une mémoire locale vers un nœud de calcul ou inversement, définissant le ou les destinataires des données en fonction du mot de configuration courant ; le bloc de contrôle global comprend une machine à états finis adaptée pour orchestrer l’exécution de chaque couche C_i par la grille de nœuds et chaque nœud de calcul comprend une machine à états finis adaptée pour orchestrer les opérations du nœud et le stockage des données dans ses registres mémoires locaux, les machines à états finis des nœuds et du bloc de contrôle global se déroulant en parallèle, avec des points de synchronisation entre elles, lors de l’exécution d’une couche lancée par le bloc de contrôle global ; et le bloc de contrôle global est adapté pour, avant l’exécution successive de chaque couche C_i, obtenir le mot de configuration respectif défini pour la couche C_i et pour configurer sa machine à états finis en fonction desdits au moins trois champs dans ledit mot de configuration ; le déroulement de la machine à états finis du bloc de contrôle global comprenant l’envoi aux nœuds d’au moins une partie dudit mot de configuration défini pour la couche et chaque nœud étant adapté pour configurer sa machine à états finis en fonction d’au moins ladite partie dudit mot de configuration qui lui a été envoyé. Dans des modes de réalisation, un tel accélérateur comprendra en outre l’une au moins des caractéristiques suivantes : - la machine à états finis du bloc de contrôle global comprend au moins les états suivants : chargement des données de filtre ; chargement des données d’une image d’entrée ; attente de la fin d’exécution des calculs fonction des données chargées de filtres et des données chargées d’une image d’entrée ; la configuration de sa machine à états finis par le bloc de contrôle global comprenant la définition des transitions entre lesdits états en fonction desdits au moins trois champs dans ledit mot de configuration ; - l’élément de traitement comprend une ou plusieurs portes logiques programmables dynamiquement implémentées sur FPGA mettant en œuvre lesdites opérations de calcul effectuées par l’élément de traitement ; - le mot de configuration indique en outre un nombre d’opérateurs MAC par élément de traitement et chaque nœud, avant l’exécution de ladite couche, est adapté pour programmer dynamiquement une ou plusieurs portes logiques en fonction dudit nombre figurant dans ladite partie dudit mot de configuration qui lui a été envoyé. L’invention sera mieux comprise et d’autres caractéristiques, détails et avantages apparaîtront mieux à la lecture de la description qui suit, donnée à titre non limitatif, et grâce aux figures annexées, données à titre d’exemple. FIG. 1 La FIG. 1 représente un système de traitement de réseau de neurones dans un mode de réalisation de l’invention ; FIG. 2 La FIG. 2 représente un procédé de traitement de réseau de neurone mis en œuvre dans un mode de réalisation de l’invention ; FIG. 3 La FIG. 3 représente un contrôleur de mémoire mis en œuvre dans un mode de réalisation de l’invention ; FIG. 4 La FIG. 4 représente les états d’une machine à états finis d’un contrôleur de mémoire mis en œuvre dans un mode de réalisation de l’invention ; FIG. 5 La FIG. 5 représente une machine à états d’un bloc de contrôle global utilisée dans un mode de réalisation de l’invention ; FIG. 6 La FIG. 6 représente la structure d’un mot de configuration considéré dans un mode de réalisation de l’invention ; FIG. 7 La FIG. 7 représente un nœud de calcul considéré dans un mode de réalisation de l’invention ; FIG. 8 La FIG. 8 représente les formats des paquets de données dans un mode de réalisation de l’invention ; FIG. 9 La FIG. 9 représente un masque d’activation mis en œuvre dans un mode de réalisation de l’invention ; FIG. 10 La FIG. 10 représente un bloc Pooling dans un mode de réalisation de l’invention ; FIG. 11 La FIG. 11 illustre le fonctionnement des blocs d’activation et d’emballage dans un mode de réalisation de l’invention ; FIG. 12 La FIG. 12 illustre différents types de mouvement des données dans l’accélérateur dans un mode de réalisation de l’invention ; FIG. 13 La FIG. 13 illustre l’exécution d’une première couche de type convolution dans un mode de réalisation de l’invention ; FIG. 14 La FIG. 14 illustre l’exécution d’une couche cachée de type convolution ou depthwise dans un mode de réalisation de l’invention ; FIG. 15 La FIG. 15 illustre l’exécution d’une couche cachée de type pointwise dans un mode de réalisation de l’invention ; FIG. 16 La FIG. 16 illustre l’exécution d’une couche cachée de type entièrement connectée dans un mode de réalisation de l’invention ; FIG. 17 La FIG. 17 représente un procédé de traitement de réseau de neurones mis en œuvre dans un mode de réalisation de l’invention ; FIG. 18 La FIG. 18 illustre un mécanisme de recouvrement des communications par le calcul mis en œuvre dans un mode de réalisation de l’invention ; FIG. 19 La FIG. 19 illustre un stade de calculs de convolution ; FIG. 20 La FIG. 20 illustre un autre stade de calculs de convolution ; FIG. 21 La FIG. 21 illustre un encore autre stade de calculs de convolution. Des références identiques peuvent être utilisées dans des figures différentes lorsqu’elles désignent des éléments identiques ou comparables. Un DNN comporte des couches successives de réseau de neurones, de types variés, chaque couche étant associée à un ensemble de filtres : une couche d’entrée, suivie par une ou des couches cachées (i.e. autres que la première et la dernière couches), suivie(s) elle(s)-même(s) par une couche de sortie. Les données d'entrée sont reçues par la couche d'entrée de neurones du DNN et les données de sortie calculées par les couches cachées du réseau de neurone, sont délivrées par la couche de sortie. Des exemples de types de couches de neurones comprennent les couches d'entrée (en anglais « input layers »), les couches de sortie (en anglais « output layers»), des couches d'unités linéaires rectifiées (en anglais « rectified linear unit layers »), des couches entièrement connectées (en anglais « fully connected layers », dites fc), des couches récurrentes (en anglais « recurrent layers »), des couches de mémoire à long/court terme (en anglais «long/short-term memory layers»), des couches de convolution (en anglais « convolutional layers », dites conv), des couches profondes (en anglais « depthwise », dites dw), des couches d'abandon (en anglais « dropout layers »), des couches ponctuelles (en anglais « pointwise », dites pw), et des couches de mise en commun, dites encore couches de pooling (en anglais « pooling layers », dites pool), qui comportent les couches de mise en commun par maximum, dites « max pooling » ( la valeur maximum dans un sous-groupe de données est sélectionnée) et les couches de mise en commun par moyennage, dites d’« average pooling » (la moyenne des valeurs dans un sous-groupe de données est choisie). Une couche de convolution, par exemple, analyse par zones, à l’aide de chaque filtre (à titre d’exemple : Sobel horizontal, Sobel vertical,…ou tout autre filtre considéré, notamment issu d’un apprentissage) de l’ensemble de filtres, au moins une matrice de données, qui lui est fournie en entrée, nommée Input Feature Map (nommée aussi IN ou ifmap par la suite) et délivre en sortie au moins une matrice de données, nommée ici Output Feature Map (nommée aussi Ofmap par la suite), qui permet de ne garder que ce qui est recherché selon le filtre considéré. A titre d’illustration d’une telle couche de convolution, on considère des matrices régulières carrées bien que cela ne soit pas indispensable pour la présente invention. Dans ce cas particulier, on a une matrice Ifmap régulière de n lignes et n colonnes, une matrice filtre F régulière de f lignes et f colonnes ainsi qu’une matrice Ofmap de m lignes et m colonnes. Dans un cas simple (sans padding, et avec stride de « 1 ») on a alors : m = n – f + 1. La formule exacte, plus complexe est : m=(n-f+2p)/s +1, où m: Ofmap (mxm) n: Ifmap (nxn) f: filtre (fxf) p: marge à 0 (« 0-padding ») s : pas (stride). Par exemple, f = 3 ou 5 ou 9 ou 11. D’une manière plus générale, en considérant que : la matrice d’entrée IFMAP est caractérisée par sa hauteur (i.e. son nombre de lignes) H in , sa largeur (i.e. son nombre de colonnes) W in et son nombre de canaux C in (un canal ou « channel » en anglais définit ainsi, de manière connue, une « image » respective nommée ci-après Ifmap ; la taille de la matrice d’entrée IFMAP est donc [H in W in C in ] (par exemple [H in W in C in ] = [255 255 64] ; la taille de chaque matrice Ifmap est [H in W in ] et elle est constituée de ses coefficients nommés ifmaps, données ifmaps ou encore données Ifmaps) ; la matrice de filtres, ‘Kernel’, est caractérisée par sa hauteur H K , sa largeur W K et son nombre de canaux C K (par exemple [H K W K C K ] = [7 7 128]) ; le pas correspond à la matrice Stride, caractérisée par sa hauteur H K et sa largeur W K (par exemple, [H S W K ] = [3 4]) ; le padding est caractérisé par la matrice Padding: [P_H1, P_H2, P_W1, P_W2] (par exemple Padding = [2 2 2 2]) ; alors, la hauteur H out , la largeur W out et le nombre de canaux C out de la matrice de sortie OFMAP (chaque canal définissant ainsi une « image » respective nommée ci-après Ofmap la taille de la matrice d’entrée PFMAP est donc [H in W in C in ] (par exemple [H out W out C out ] ; la taille de chaque matrice Ofmap est [H out W out ] et elle est constituée de ses coefficients nommés ofmaps, données ofmaps ou encore données Ofmaps) vérifient : H out = (H in - H K +P_H1 +P_H2) / H S +1 ; (dans l’exemple indiqué : H out = (255 – 7 + 2 + 2) / 3 + 1 = 85) ; W out = (W in - W K + P_W1 + P_W2) / W K + 1 ; (dans l’exemple indiqué : W out = (255 – 7 + 2 + 2 ) / 4 + 1 = 64) ; Coût = CK ) ; (dans l’exemple indiqué : C out = 128). De manière connue, les convolutions effectuées correspondent par exemple au processus suivant : la matrice de filtre est disposée sur le coin haut à gauche de la matrice IN, un produit de chaque couple de coefficients ainsi superposés est effectué ; l’ensemble des produits est sommé, ce qui donne la valeur du pixel (1,1) de la matrice de sortie Ofmap. La matrice de filtre est alors décalée d’une case (stride) horizontalement vers la droite, et le processus est réitéré, fournissant la valeur du pixel (1,2) de la matrice Ofmap, etc. Une fois arrivé en fin de ligne, le filtre est descendu verticalement d’une case, le processus est réitéré en repartant ensuite de la droite, etc. jusqu’à avoir parcouru toute la matrice Ifmap. Les calculs de convolution sont généralement mis en œuvre par des unités de calcul de réseau de neurones, encore appelés accélérateur d’intelligence artificielle ou NPU (en anglais Neural Processing Unit), comprenant un réseau d’éléments processeurs PE. Dans un exemple, il est présenté ci-dessous un exemple de calcul effectué classiquement dans une couche de convolution mise en œuvre par un accélérateur. On considère le filtre F constitué des poids suivants : f 1 f 2 f 3 f 4 f 5 f 6 f 7 f 8 f 9 On considère la matrice Ifmap suivante : in 1 in 2 in 3 in 4 in 5 in 6 in 7 in 8 in 9 in 10 in 11 in 12 in 13 in 14 in 15 in 16 in 17 in 18 in 19 in 20 in 21 in 22 in 23 in 24 in 25 Et on considère la matrice Ofmap suivante : out 1 out 2 out 3 out 4 out 5 out 6 out 7 out 8 out 9 L’expression de chaque coefficient de la matrice Ofmap est une somme pondérée correspondant à une sortie d’un neurone dont des in i seraient les entrées et des f j seraient les poids appliqués aux entrées par le neurone et qui calculerait la valeur du coefficient. Considérons maintenant une grille d’éléments unitaires de calcul pe, comportant autant de lignes que le filtre F (f= 3 lignes) et autant de colonnes que la matrice Ofmap a de colonnes (m = 3) : [pei,j] i = 0 à 2 et j = 0 à 2. Ce qui suit est un exemple d’utilisation de la grille pour calculer les coefficients de la matrice Ofmap. Comme représenté en FIG. 19 , à chaque élément unitaire de calcul pe de la (i+1) ème ligne des pe, on fournit la (i+1) ème ligne de la matrice de filtre, i=0 à 2. On fournit ensuite à la grille des pe la matrice IN : ainsi la première ligne de IN est fournie à l’élément unitaire de calcul pe00 ; la deuxième ligne de Ifmap à pe10 et pe01, situés sur une même diagonale ; la troisième ligne de Ifmap est fournie aux éléments unitaires pe20, pe11 et pe02, situés sur une même diagonale ; la quatrième ligne de Ifmap est fournie aux éléments pe21 et pe12 sur une même diagonale, et la cinquième ligne de Ifmap est fournie à pe22. Dans une première salve de calcul représentée également sur la FIG. 19 , une convolution (combinaison de multiplications et de sommes) est effectuée dans chaque pe entre la rangée de filtre qui lui a été fournie et les f premiers coefficients de la rangée de la matrice Ifmap qui lui a été fournie, délivrant une somme partielle nommée (les cases grisées de la ligne de Ifmap ne sont pas utilisées pour le calcul courant). Ainsi pe00 calcule f1.in1 + f2.in2 + f3.in3 etc. Ensuite les trois sommes partielles déterminées par les pe d’une même colonne sont sommées progressivement : la somme partielle déterminée par pe2j est fournie à pe1j qui l’ajoute à la somme partielle qu’il a précédemment calculée, cette nouvelle somme partielle issue de l’accumulation est alors à son tour fournie par pe1j à pe0j qui l’ajoute à la somme partielle qu’il avait calculée, j = 0 à 2 : le total ainsi obtenu est égal au premier coefficient de la j+1 ème ligne de la matrice Ofmap. Dans une deuxième salve de calcul représentée sur la FIG. 20 , une convolution est effectuée dans chaque pe entre la rangée de filtre qui lui a été fournie et les f= 3 coefficients, à partir du 2 ème coefficient, de la rangée de la matrice IN qui lui a été fournie, délivrant une somme partielle (ainsi pe00 calcule f1.in2 + f2.in3 + f3.in4). Ensuite les trois sommes partielles déterminées par les pe d’une même colonne sont sommées progressivement comme décrit ci-dessus et le total ainsi obtenu est égal au deuxième coefficient de la j+1 ème ligne de la matrice Ofmap. Dans une troisième salve de calcul représentée en FIG. 21 , une convolution est effectuée dans chaque pe entre la rangée de filtre qui lui a été fournie et les f= 3 coefficients, à partir du 3 ème coefficient, de la rangée de la matrice Ifmap qui lui a été fournie, délivrant une somme partielle nommée. Ainsi pe00 calcule f1.in3 + f2.in4 + f3.in5 etc. Ensuite les trois sommes partielles déterminées par les pe d’une même colonne sont sommées progressivement comme décrit ci-dessus et le total ainsi obtenu est égal au troisième coefficient de la j+1 ème ligne de la matrice Ofmap. Dans le processus de calcul décrit ici à titre d’exemple, la ième colonne de pes permet ainsi de construire successivement la ième ligne de Ofmap, i = 1 à 3. Il découle de cet exemple que les lignes des données manipulées (poids des filtres, données des Input Feature Map et sommes partielles) sont réutilisées spatialement entre les éléments processeurs unitaires : ici par exemple, les mêmes données de filtres sont utilisées par les pe d’une même ligne horizontale et les mêmes données Ifmap sont utilisées par tous les pe de lignes diagonales, tandis que les sommes partielles sont transférées verticalement, puis réutilisées. D’autres types de réutilisation et d’autres sens de propagation spatiale peuvent néanmoins être considérés, en fonction du type d’opérations à réaliser. Il importe donc que, dans un accélérateur, les communications de ces données et les calculs impliqués soient réalisables de manière optimisée en terme de temps de transfert et de calcul d’accès à la mémoire centrale délivrant initialement ces données, et cela quelles que soient les dimensions des données d’entrée et données de sortie, les types de propagation qui sont mis en œuvre dans le réseau de PE, le type de couche de neurone ou les calculs mis en œuvre. A cet effet, en référence à la FIG. 1 , un système 2 de traitement de réseau de neurones comprend un accélérateur 1 de réseaux de neurones CNN. Le système 2 comprend aussi, dans l’exemple considéré, un contrôleur DMA 18 (DMA acronyme de l’anglais « Direct Memory Access ») et une mémoire DRAM 19 (DRAM acronyme de l’anglais « Dynamic Random Access Memory ») ainsi qu’un processeur principal (CPU, GPU) qui sont extérieurs à l’accélérateur 1. L’accélérateur 1, dans un mode de réalisation de l’invention, comprend un bloc de contrôle global 10, une grille 11 de nœuds de calcul 14, un contrôleur de mémoire 12, et un ensemble 13 de mémoires tampon (par exemple SRAM). Le contrôleur de mémoire 12 est adapté pour orchestrer les échanges entre l’accélérateur 1 et le monde extérieur (CTRL DMA 18, DRAM 19, et sous-système CPU/GPU) et requérir des transferts de données entre des mémoires externes (DRAM 19) et des mémoires internes à l’accélérateur (mémoires tampon 13). Le bloc de contrôle global 10 est adapté pour contrôler le déroulement du traitement dans l’accélérateur 1, notamment pour en assurer la synchronisation globale. La grille 11 de nœuds de calcul comprend des nœuds de calcul 14 disposés en réseau, par exemple selon une organisation matricielle en N lignes et M colonnes et connectés par des liens de communication horizontaux et verticaux permettant l’échange de paquets de données entre nœuds 14 (en FIG. 1 , N =3 et M = 5 uniquement à titre d’illustration). L’ensemble de mémoires tampons 13 est adapté pour stocker les données d’entrée (filtre et ifmaps) en provenance de la DRAM 19 et avant leur fourniture à la grille 11 pour l’exécution d’une couche. L’ensemble de mémoires tampons 13 est adapté également pour stocker les données de sortie (ofmaps) d’une couche. Un mécanisme d’envoi des données (de l’ensemble 13 de mémoires vers les nœuds de calcul ou inversement) définit le ou les destinataires des données à l’aide de paquets de contrôle associés aux paquets de données à envoyer. Dans l’exemple considéré, l’ensemble 13 de mémoires tampons comprend : - un premier sous-ensemble 13_1 de mémoires tampons dites IGB : IGB_i, i = 0 à N-1+M-1 (ici i = 0 à 6) (chacune de ces mémoires IGB est associée dans l’exemple considéré à un nœud de calcul respectif parmi l’ensemble 13_11 de nœuds composé des nœuds 14 de la première colonne ou parmi l’ensemble 13_12 de nœuds composé des nœuds de la dernière ligne de la grille 11 : chaque mémoire tampon locale IGB est reliée au routeur du nœud de calcul qui lui est associé) ; - un deuxième sous-ensemble 13_2 de mémoires tampons, dites OGB : OGB_j, j = 0 à M-1 (chacune de ces mémoires OGB est associée dans l’exemple considéré à un nœud de calcul respectif parmi l’ensemble de nœuds composé des nœuds 14 de la première ligne de la grille 11 : chaque mémoire tampon locale OGB est reliée au routeur du nœud de calcul qui lui est associé). La taille de l'architecture de l’accélérateur 1 minimale dépend du type d’opérations à réaliser. Ici, dans le cas d’une opération de type convolution, la taille de l’architecture de l’accélérateur 1 minimale est basée sur le nombre de lignes du filtre et le nombre de lignes du Ofmap. Par exemple, si la taille du filtre est de 6 × 6, alors le nombre de lignes dans la grille 11 de nœuds de calcul serait de 6 et le nombre de colonnes serait égal au nombre de lignes dans Ofmap. La formule générale donnant la taille ( H out , W out , C out ) de la sortie Ofmap a été donnée plus haut. Il sera question ci-après des voisins situés au Nord (N), Sud (S), Est (E) et Ouest (O) : ces directions, sont indiquées sur la FIG. 1 (par rapport à une localisation d’un nœud symbolisé par une croix). L’accélérateur 1 a par exemple une architecture basée sur un NOC (Network on Chip). Le NOC est par exemple conçu pour le transfert de données simultané (entre les routeurs des nœuds notamment) via un routage multi-chemins parallèles et paramétrique afin de garantir une bande passante élevée dans différentes topologies, par exemple comme décrit dans FR 3133936. Dans des modes de réalisation, l’accélérateur 1 comporte en outre un bloc de pooling 15 et/ou un bloc d’emballage 16 et/ou un bloc d’activation 17. Dans un mode de réalisation, chaque nœud de calcul 14 comprend, en référence à la FIG. 7 , un élément de traitement 50, un routeur 52 et un bloc de contrôle d’horloge (en anglais « clock gating ») 53. L’élément de traitement 50, dit encore PE 50 (pour « Processing Element » en anglais), comporte (et ce de manière paramétrable dans un mode de réalisation de l’invention décrit plus bas) un ou plusieurs blocs unitaires de calcul 51 comportant chacun : - des registres de mémoires (RF) notamment destinés à stocker les données de filtre (RF 510) et les données d’entrée d’Input Feature Map (RF 511) reçus par le nœud de calcul 14 et - un opérateur MAC 57 adapté pour réaliser des opérations de calcul de type MAC notamment en fonction de ces données mémorisées dans les registres 510, 511, à l’aide d’une cellule logique de multiplication 512, d’une cellule logique d’accumulation 513 et d’une cellule logique d’addition 514. L’élément de traitement 50 comporte en outre un contrôleur PE 58 et des multiplexeurs (mux) 55, 56, pilotés chacun par une logique de sélection de sortie dans ce contrôleur PE 58. Le multiplexeur 55 a par exemple comme entrées les sorties respectives des blocs unitaires de calcul 51 et une seule de ces entrées est choisie comme sortie du mux 55 (par exemple la somme partielle choisie Psum sera ensuite transmise, via le routeur 52, à un nœud de calcul voisin, par exemple celui au Nord. L’élément de traitement 50 comporte dans des modes de réalisations des registres mémoires additionnels destinés à stocker des résultats (sommes partielles, accumulations de sommes partielles) calculés par le PE 50. Le PE 50 ne comporte donc pas de processeur programmable par lecture d’instructions logicielles, il est constitué d’unités ALU (« Arithmetic Logic Unit »). Le routeur 52 est adapté pour router les communications de données entrant dans le nœud 14 ou sortant du nœud 14. Tous les routeurs de l’accélérateur 1 sont interconnectés en utilisant une parmi différentes topologies envisageables (maille, tore ou anneau) pour former le réseau NoC, qui assure la communication entre les mémoires tampons IGB 13_1/OGB 13_2 et les nœuds de calcul 14, et entre les nœuds de calcul 14 eux-mêmes. Le résultat d’un calcul effectué par un PE 50, appelé somme partielle (PSum), sera transmis au nœud de calcul 14 voisin au Nord pour in fine effectuer l'opération d'accumulation finale générant l'Ofmap. Le bloc de contrôle d’horloge 53, dans le nœud 14, est adapté pour optimiser la consommation d'énergie de l'appareil. Dans un mode de réalisation, l'architecture de l’accélérateur 1 reste fixe pour l'exécution d'un DNN donné, et comme la forme des couches d'un même DNN est variable, le mécanisme dit de clock gating fait en sorte que seuls les PE 50 des nœuds 14 alloués pour l'exécution restent actifs. Les autres seront désactivés par le mécanisme. Le bloc de contrôle d’horloge 53, comportant une porte logique "ET" alimentée par l'horloge globale et un signal "1" contrôlé par la logique de contrôle d'activation, compare un masque d'activation (cf. exemple de masque en FIG. 9 ) avec l'adresse locale du nœud et décide d'activer ou non le nœud, en fonction de la position de ce dernier. Ces masques d'activation sont stockés dans des IGB 13_1 entre les couches du réseau DNN. Une multidiffusion horizontale est effectuée dans toute la grille 11 et seuls les PE 50 des nœuds 14 avec un Y inférieur aux valeurs du masque restent actifs. Les autres seront désactivés (IF Y de PE[X, Y]>m => PE inactif). De façon à permettre le mécanisme de recouvrement des communications par le calcul décrit plus bas dans un exemple, le dispositif de routage 52 est adapté pour gérer des chemins de routage en parallèle. Pour ce faire, il comprend en référence un bloc de contrôles de routage parallèles, un bloc d’arbitres parallèles, un bloc de commutateurs parallèles et un bloc de buffers d’entrée parallèles. En effet, à travers ces différents modules de bufférisation (par exemple des FIFO, First-In-First-Out) du bloc de buffers d’entrée parallèles, différentes requêtes de communication de données (filtres, données IN ou psums) reçues en parallèle (par exemple d’un bloc 10 voisin à l’Est (e_in), à l’Ouest (o_in), au Nord (n_in), au Sud (s_in), ou en local (L_in) du PE ou des registres) peuvent être stockées sans aucune perte. Ces requêtes sont ensuite traitées simultanément dans plusieurs modules de contrôle au sein du bloc de contrôles de routage parallèles, en fonction des en-têtes Flit (Flow control unit) des paquets de données. Ces modules de contrôle de routage assurent un contrôle déterministe du transfert de données selon un algorithme de routage statique X-Y (par exemple) et une gestion de différentes sortes de communications (unicast, multicast horizontal, vertical ou diagonal et broadcast). Les requêtes résultantes émises par les modules de contrôle de routage sont fournies en entrée du bloc d’arbitres parallèles. Un arbitrage parallèle de priorité de l’ordre de traitement des paquets de données entrants selon, par exemple la politique d’arbitrage Round-Robin basée sur un accès planifié permet de mieux gérer les collisions, c’est-à-dire, une demande qui vient d’être accordée aura la priorité la plus basse sur le prochain cycle d’arbitrage. En cas de demandes simultanées d’une même sortie à l’Est, à l’Ouest, au Nord, au Sud (sachant que les sorties sont notées ainsi sur la FIG. 7 : pour l’Est (e_out), pour l’Ouest (o_out), pour le Nord (n_out), pour le Sud (s_out), ou en Local (L_out)) les requêtes sont mémorisées pour éviter l’interblocage ou la perte de données (i.e. deux requêtes simultanées sur une même sortie au sein d’un même routeur 12 ne sont pas servies sur un même cycle). L’arbitrage effectué est ensuite indiqué au bloc de commutateurs parallèles. La commutation parallèle aiguille simultanément les données aux bonnes sorties selon la règle de commutation Wormhole par exemple, c’est-à-dire que la connexion entre une des entrées et une des sorties d’un routeur est maintenue jusqu’à ce que toutes les données élémentaires d’un paquet du message soient envoyées et cela de façon simultanée à travers les différents modules de commutations pour leur direction respective Nord, Est, Sud, Ouest, Local. Le format du paquet de données est représenté en FIG. 8 . Le paquet est de taille configurable W data (sur la figure 32 bits) et se compose d’un flit d’en-tête suivi de flits de charge utile (payload). La taille du paquet dépendra de la taille du réseau d’interconnexion, puisque plus le nombre de routeurs 52 augmente, plus le nombre de bits pour coder les adresses des destinataires ou des émetteurs augmente. De même, la taille du paquet varie avec la taille des charges utiles (poids des filtres, les activations d’entrées ou les sommes partielles) à faire circuler dans la grille 11. La valeur de l’en-tête détermine la communication à assurer par le routeur 52. Il existe plusieurs types de communication possibles : unicast, multicast horizontal, multicast vertical, multicast diagonal et broadcast, accès mémoire 13. Le routeur 52 reçoit d’abord le paquet de contrôle, encore appelé mot de contrôle, contenant le type de la communication et le destinataire ou la source, identifié par ses coordonnées (Addr_source ou dest_X, Addr_source ou dest_Y,) dans la grille, de la manière représentée en FIG. 8 . Le routeur 52 décode ce mot de contrôle et alloue ensuite le chemin de communication pour transmettre le paquet de données utiles, encore nommé paquet Payload, (associé audit mot de contrôle) qui arrive au cycle suivant la réception du paquet de contrôle. Les couples de paquets correspondants sont représentés en FIG. 8 (i, ii, iii). Une fois le paquet de donnée utile transmis, le chemin alloué sera libéré pour réaliser d’autres transferts. Pour l'accès à la mémoire, la lecture de d’IGB 13_1 est une communication multicast ; l'écriture dans un OGB 13_2 est un type de communication qui traite une monodiffusion parallèle directe à partir des premières lignes de nœuds 14 vers l'OGB. L'envoi d’un mot de configuration est traité en mode diffusion. Le routeur 52 reçoit d'abord le paquet de contrôle contenant le type de communication et l'adresse source ou destination. Le système 2 utilise ainsi trois niveaux de stockage hiérarchique : - la mémoire DRAM 19 qui contient toutes les données d’entrée à fournir à l’accélérateur 1, préalablement chargées depuis un processeur central (de type CPU ou GPU) ; les données de sortie délivrées par le réseau de neurones seront transmises de l’accélérateur 1 à la DRAM 19 puis interprétées par le processeur principal ; - l’ensemble 13 de mémoires tampons qui sont distribuées sur la grille 1 de nœuds de calcul pour faciliter l’accès parallèle aux données ; la communication entre la DRAM 19 et les mémoires tampons de l’ensemble 13 est gérée par le contrôleur de mémoire 12 via le bloc de contrôle global 10 et le contrôleur DMA 18 ; comme cela sera décrit plus bas, ces mémoires tampon sont utilisables pour exploiter la réutilisation de données, masquer ainsi la latence d’accès à la DRAM 19 et stocker des données intermédiaires entre des couches distinctes du réseau de neurones en cours d’exécution sur l’accélérateur 1 ; la taille de l’ensemble 13 de mémoires tampons est par exemple égale à 1 mégaoctet ; - les registres RF (par exemple référencés 510, 511), distribués dans chaque nœud de calcul 14 qui sont directement connectés aux opérateurs MAC 57 de ce nœud de calcul ; un RF communique avec les RF des nœuds de calcul voisins 14 et mémoires tampons de l’ensemble 13 voisins via le routeur local 52 du nœud concerné ; la taille d'un RF ne dépasse pas 1 kilooctet. L’accès aux données via ces différents niveaux implique des coûts énergétiques différents. Le coût le plus élevé est la DRAM et le plus bas est le RF. Le bloc Pooling 15 est adapté pour effectuer un traitement de « pooling » classique dans les DNN, i.e. de mise en commun correspondant à une sorte de sous-échantillonnage des données qui sont fournies en entrée du bloc 15, par choix d’un maximum, d’une valeur moyenne, parmi plusieurs données voisines. Un exemple de bloc Pooling 15 est représenté en FIG. 10 . La couche de pooling applique un noyau à l'image d'entrée ifmap dans une représentation 2D. Il existe différents types de pooling, tels que le pooling maximum et le pooling moyen. Cette couche est utilisée pour rendre les cartes de caractéristiques robustes à l'emplacement des caractéristiques à détecter. Cette couche est généralement appliquée aux sorties après le calcul de convolution. Pour cette raison, ce module a été placé séparément de la grille 11 de nœuds de calcul 14 pour effectuer le pooling vers les ofmaps avant de les stocker dans les OGB 13_2. Le bloc de contrôle global 10 envoie : (i) signal "p" de 2 bits aux contrôleurs C pour les informer du type de pooling (max ou moyenne) et de la taille de pas, dit « stride » (1 ou 2), (ii) signal "sel" de 2 bits aux multiplexeurs pour sélectionner les données à envoyer aux OGB 13_2 (c'est-à-dire données sans pooling (N) ou données avec pooling avec stride de 1 (S1) ou de 2 (S2)). En fonction du type de pooling et de la taille de stride, le contrôleur C effectue une comparaison entre deux données d'entrée voisines. La sortie du contrôleur C représente le résultat (S1) du pooling avec le stride 1 pour le multiplexeur associé à ce C. Le câblage a été défini au préalable pour associer la sortie de C à un multiplexeur voisin pour représenter le résultat (S2) du pooling avec un stride 2. La FIG. 11 illustre le fonctionnement des blocs d’activation 17 et d’emballage 16 (dans un autre mode de réalisation, leur sens est inversé : l’ensemble 170 des données O1, O2, O3 qui sont des données Ofmap délivrées par la grille 11 et issues des accumulations de Psum passent alors d’abord via le bloc d’emballage 16, et ensuite via le bloc d’activation 17). Le bloc d’activation 17 est adapté pour appliquer : - une fonction mathématique (fonction dite ‘sat’, définie par exemple dans un paramètre générique lors de la génération d’une configuration de l’architecture) sur les données O1, O2, O3 qui lui sont fournies en entrée, par exemple la fonction Unité Linéaire Rectifiée, dénommée couramment ReLU qui remplace toutes les valeurs négatives reçues en entrée par des zéros (ReLU(x) = max(0,x)) (alternativement, la fonction d’activation est la fonction tangente hyperbolique (tanh(x)), la fonction tangente hyperbolique saturante (│tanh(x)│), la fonction sigmoïde (1+e -x ) -1 ) ; puis - un décalage en fonction du contenu du champ « Shift » (définissant le nombre de bits de décalage vers la droite à appliquer) du mot de configuration, Par exemple la valeur renvoyée par la fonction sat est une valeur saturée de la somme pondérée sur 8 bits. Dans le cas où la fonction d'activation est une ReLU, la fonction sat mettra la variable x à 0 si x ≤ 0 . Ensuite dans le cas d’un calcul entier de 8-bit, cette variable sera décalée vers la droite d'un certain nombre de bits définis dans le champ « Shift » du mot de configuration. Le conditionnement des données par le bloc d’emballage 16 comprend dans le mode de réalisation considéré à titre d’exemple un traitement consistant à encapsuler un ensemble 170 de plusieurs données Ofmaps, ici N PACK (ici N PACK =3) données de sortie Ofmaps (n x 8 bits) successives d’un même nœud (nommées O1, P2, O3 en FIG. 11 ) dans le même paquet de charge utile 160, puis à y ajouter le mot de contrôle associé pour préparer les données pour la couche suivante. Ces paquets sont par exemple ensuite envoyés aux OGB 13_2, en attente d'exécution par la couche suivante. Le traitement de flux de données par le système 2 se base notamment sur : - une réutilisation des données adaptative à travers des transferts de données multidirectionnels en parallèle, comme illustré en FIG. 12 notamment, qui réduit les accès coûteux aux mémoires et l’énergie électrique consommée ; - un recouvrement des communications par le calcul, en séparant le contrôle de ces deux aspects, ce qui masque le coût des transferts de données pour améliorer les performances ; - une exécution sur demande, pilotée par les blocs de contrôle d’horloge PE 53. - une synchronisation adaptée: entre Globalement Synchrone Localement Asynchrone (GSLA) et Globalement Asynchrone Localement Synchrone (GALS), qui assure un mouvement spatiotemporel des données optimal. Par exemple, en référence à la FIG. 1 , en appelant G1 le groupe de tous les nœuds 14 de la grille 11 pour le calcul de leurs sorties respectives Ofmap, en appelant G2 le groupe des nœuds N_00, N_10 et N_20 (correspondant à 1 rangée de Ofmap) et en appelant G3 le groupe constitué du nœud N_04 (pour le calcul des Psum) : : les nœuds de même colonne dans un groupe G2 assurent le calcul de façon synchrone entre eux (ils reçoivent les données au même moment : donc Localement Synchrone à l’intérieur du G2), mais les colonnes constituant le groupe G1 sont asynchrones entre eux ; ce qui fait que les nœuds appartenant à des colonnes différentes sont asynchrones (Globalement Asynchrone) ; et : chaque nœud représenté par un groupe G3 (par exemple le N_04) assure le calcul indépendamment des autres nœuds du même groupe G3 (Localement Asynchrone) ; le groupe G1 doit attendre la fin du calcul dans tous les nœuds du groupe G3 afin de déclencher une exécution de nouvelle couche d’un réseau DNN (Globalement Synchrone). Illustration, dans un exemple, du recouvrement des communications par le calcul Le mécanisme de recouvrement des communications par le calcul mis en œuvre dans l’accélérateur 1 est illustré relativement à la FIG. 18 où l’ensemble des données de la (i+1)ème ligne des poids dans la matrice de filtre est notée F rowi , i = 0 à p-1 ; l’ensemble des données de la (i+1)ème ligne de la matrice IN est notée in rowi , i = 0 à n-1 ; les données issues d’un calcul de sommes partielles réalisé par le PE ij est noté psum ij i = 0 à 3 et j = 0 à 3. Les nœuds de calcul 14 sont disposés en réseau, par exemple ici selon une organisation matricielle en N=4 lignes et M=4 colonnes. On repère, sur la FIG. 18 , un nœud de calcul 14 (et similairement son PE 50) par son rang de ligne et de colonne dans la grille. Ainsi le nœud (i,j), comprenant le PE ij , est situé sur la i+1ème ligne et j+1ème colonne de la grille 11, i = 0 à 3 et j = 0 à 3. Chaque nœud 14 non situé en bordure du réseau comporte ainsi 8 nœuds voisins, dans les directions suivantes : un au Nord (N), un au Sud (S) un à l’Ouest (O), un à l’Est (E), un au Nord-Est, un au Nord-Ouest, un au Sud-Est, et un au Sud-Ouest. Le bloc de contrôle global 10 est adapté pour synchroniser, entre eux, les traitements de calcul dans les PE et de transfert de données entre nœuds ou au sein de nœuds et mis en œuvre dans l’accélérateur 1. Tous ces traitements sont cadencés par une horloge de l’accélérateur 1. Il y aura eu une étape préalable de configuration de la grille 11 pour sélectionner l’ensemble de PE à utiliser, parmi les PE disponibles de l’architecture matérielle maximale de l’accélérateur 1, pour l’application du filtre considéré d’une couche du réseau de neurones à une matrice Ifmap. Au cours de cette configuration, le nombre de lignes « actives » de la grille 11 est fixé égal au nombre de lignes du filtre (p) et le nombre de colonnes « actives » de la grille 11 est pris égal au nombre de lignes de la matrice OUT (m). Dans le cas représenté en FIG. 18 , ces nombres p et m sont égaux à 4 et le nombre n de lignes de la matrice Ifmap est égal à 7. Les flèches en FIG. 18 représentent la façon dont les données sont réutilisées dans la grille 11. En effet, les lignes d’un même filtre, F rowi , i = 0 à p-1, sont réutilisées horizontalement à travers les PEs (il s’agit donc d’un multicast horizontal des poids du filtre), les lignes in rowi de IN, i = 0 à n-1 sont réutilisées diagonalement à travers les PEs (un multicast diagonal de l’image d’entrée, ici mis en œuvre par la succession d’un multicast horizontal et d’un multicast vertical) et les sommes partielles psum sont accumulées verticalement à travers les PEs (il s’agit d’un unicast des psum), comme représenté par les flèches verticales en pointillé. L’accélérateur 1 est adapté pour mettre en œuvre, dans la phase d’inférence du réseau de neurones, la réutilisation en parallèle, décrite ci-dessus, par les PE des trois types de données que sont les poids du filtre, les données d’entrée de la matrice Input Feature Map et les sommes partielles, ainsi que le recouvrement, par le calcul, des communications, dans un mode de réalisation de l’invention. L’accélérateur 1 est notamment adapté pour mettre en œuvre les étapes décrites ci-dessous. Dans une première étape, une alimentation parallèle de la grille 11 est effectuée avec les poids de filtre et les données d’entrée de la matrice Ifmap, via un bus entre les mémoires tampons 13_1 et la grille 11. Ainsi, au cycle de traitement T0 (les cycles sont cadencés par l’horloge de l’accélérateur 1) : la première colonne de la grille 11 est alimentée par les lignes respectives du filtre : la ligne de poids F rowi , i = 0 à 3 est fournie en entrée du nœud (i, 0), ici par l’IGB_i 13_1 (non représenté en FIG. 18 ) ; la première colonne et la dernière ligne de la grille 11 sont alimentées par les lignes respectives de la matrice Input Feature Map : la ligne in rowi , i = 0 à 3 est fournie en entrée du nœud (i, 0) (ici par l’IGB_i 13_1 (non représenté en FIG. 18 )) et la ligne in rowi , i = 4 à 6 est fournie en entrée du nœud (3, i-3) ici par l’IGB_i 13_1 (non représenté en FIG. 18 ). Au cycle T1 suivant le cycle T0, les poids et données issues de la matrice Ifmap reçus par chacun de ces nœuds 14 sont stockés dans des registres respectifs 511, 510 du nœud 14. Dans une étape suivante, la diffusion des poids de filtre et des données d’entrée au sein du réseau est itérée : elle est effectuée en parallèle, par multicast horizontal des lignes de poids de filtre et multicast diagonal des lignes de l’image d’entrée Input Feature Map. Ainsi au cycle T2 : la première colonne envoie, par diffusion horizontale, à la deuxième colonne de la grille 11 les lignes respectives du filtre préalablement stockée : la ligne de poids F rowi , i = 0 à 3, est fournie en entrée du nœud (i, 1) par le nœud (i,0) ; et en parallèle chacun des nœuds (i, 0) transmet la ligne in rowi , i = 1 à 3, et chacun des nœuds (3, i-3) transmet la ligne in rowi , i = 4 à 6), à destination du bloc 10 de traitement qui leur est respectivement voisin en direction NE (par exemple le nœud (3,0) transmet à destination du nœud (2,1)) : pour arriver à cette destination, cela prendra dans le cas présent, deux transmissions : une transmission horizontale et une transmission verticale (par exemple pour que les données parviennent du nœud (3,0) au nœud (2,1), elle ira du nœud (3,0) au nœud (3,1), puis au nœud (2,1) : donc d’abord les voisins à l’Est des nœuds (i, 0), i = 1 à 3 et des nœuds (3, i-3) reçoivent la ligne ; la première colonne des nœuds disposant des poids de filtre et des données d’entrée de la matrice Ifmap, les PE de ces nœuds mettent en œuvre un calcul de convolution entre le filtre et (certaines au moins de) ces données d’entrée ; le résultat ainsi calculé de somme partielle psum 0j par le PE 0j , j = 0 à 3, est stocké dans un registre du nœud. Au cycle T3, les poids de filtre et données issues de la matrice Ifmap reçus à T2 par ces nœuds à T2 sont stockés dans des registres respectifs de chacun de ces nœuds. Au cycle T4, en parallèle : la deuxième colonne alimente, par diffusion horizontale, la troisième colonne de la grille 11 par les lignes respectives du filtre préalablement stockée : la ligne de poids F rowi , i = 0 à 3, est fournie en entrée du nœud (i, 2) par le nœud (i,1) ; les nœuds (i-1, 1) reçoivent la ligne in rowi , i = 1 à 3 et chacun des nœuds (2, i-2) reçoivent la ligne in rowi , i = 4 à 5 ; la deuxième colonne des nœuds 14 disposant des poids de filtre et des données d’entrée de la matrice Ifmap, les PE de ces nœuds mettent en œuvre un calcul de convolution entre le filtre et (certaines au moins de) ces données d’entrée; le résultat ainsi calculé de somme partielle psum 1j par le PE 1j , j = 0 à 3, est stocké dans un registre mémoire local au nœud. Au cycle T5, les poids de filtre et données issues de la matrice Ifmap reçus à T4 par ces nœuds sont stockés dans des registres respectifs de chacun de ces nœuds. Au cycle T6, en parallèle : la troisième colonne alimente, par diffusion horizontale, la quatrième colonne de la grille 11 par les lignes respectives du filtre préalablement stockée, achevant ainsi la diffusion des poids de filtre dans la grille 11 : la ligne de poids F rowi , i = 0 à 3, est fournie en entrée du nœud (i, 3) par le nœud (i,2) ; les nœuds ayant reçus au temps T4 une ligne de la matrice Ifmap et ayant un voisin en direction du NE émettent à leur tour cette ligne de matrice Ifmap à destination de ce voisin. Au cycle T7, les poids de filtre et données issues de la matrice Ifmap reçus à T4 par ces nœuds sont stockés dans des registres respectifs de chacun de ces nœuds. Au cycle T8, la troisième colonne des nœuds disposant des poids de filtre et des données d’entrée de la matrice Ifmap, les PE de ces nœuds mettent en œuvre un calcul de convolution entre le filtre et (certaines au moins de) ces données d’entrée ; le résultat ainsi calculé de somme partielle psum 2j par le PE 2j , j = 0 à 3, est stocké dans un registre du nœud. les nœuds ayant reçus au temps T6 une ligne de la matrice Ifmap et ayant un voisin en direction du NE émettent à leur tour cette ligne de matrice Ifmap à destination de ce voisin. La diffusion diagonale se poursuit. Au cycle T12, le nœud (03) a reçu à son tour la ligne in row3 . La quatrième colonne des nœuds disposant des poids de filtre et des données d’entrée de la matrice IN, les PE de ces nœuds mettent en œuvre un calcul de convolution entre le filtre et (certaines au moins de) ces données d’entrée ; le résultat ainsi calculé de somme partielle psum 3j par le PE 3j , j = 0 à 3, est stocké dans un registre du nœud. Ensuite, un transfert parallèle des sommes partielles psum est effectué et il est procédé à l’accumulation de ces psums : les nœuds de la dernière ligne de la grille 11 envoient chacun la somme partielle calculée à leur voisin situé en direction Nord. Celui-ci accumule cette somme partielle reçue à celle qu’il a précédemment calculée et à son tour envoie la somme partielle accumulée à son voisin Nord qui répète la même opération etc. jusqu’à ce que les nœuds de la première ligne de la grille 11 aient effectué cette accumulation (l’ensemble de ces traitements étant effectués de façon cadencé par l’horloge de l’accélérateur 1). Cette dernière accumulation réalisée par chaque nœud (0,j) j = 0 à 3, correspond à (une partie) des données de la ligne j de la matrice OUT. Elle est alors délivrée par le nœud (0,j) à la mémoire tampon OGB 13_2 pour stockage. Les résultats Output Feature maps de la couche de convolution considérés sont ainsi déterminés en fonction des sorties Out rowi , i = 0 à 3. La diffusion des poids de filtre est effectuée dans l’accélérateur 1 (un multicast des poids de filtre avec une réutilisation horizontale des poids de filtre à travers les nœuds) en parallèle de la diffusion des données d’entrée de la matrice Ifmap (multicast des lignes de l’image avec une réutilisation diagonale à travers les nœuds). Le recouvrement des communications par le calcul permet une réduction du coût de transfert de données en améliorant le temps d’exécution des programmes parallèles en diminuant la contribution effective du temps dédié au transfert des données au temps d’exécution de l’application complète. Les calculs sont découplés de la communication des données dans la grille afin que les PE 50 effectuent des travaux de calcul pendant que l’infrastructure de communication (routeurs 52 et liens de communication du NOC) effectue le transfert des données. Ceci permet de cacher en partie ou totalement le surcoût de la communication, sachant que le recouvrement ne peut être parfait que si le temps de calcul dépasse le temps de communication et que le matériel permet de supporter ce paradigme. Dans le mode de réalisation décrit ci-dessus relativement à la FIG. 18 , il est attendu que toutes les psum soient calculées avant de procéder à leur accumulation. Dans un autre mode de réalisation, l’accumulation des psum est lancée sur les premières colonnes du réseau alors même que le transfert des données de filtre et des données de matrice Ifmap se poursuit dans les colonnes plus à l’Est et que donc les psum pour ces colonnes ne sont encore pas calculées : il y a donc dans ce cas un recouvrement des communications par les communications des sommes partielles psum, ce qui permet de réduire encore davantage la contribution des transferts de données dans le temps d’exécution total de l’application et ainsi améliorer les performances. Les premières colonnes peuvent alors, en option, être utilisées plus rapidement pour d’autres mémorisations et d’autres calculs, le temps de traitement global s’en trouvant donc encore amélioré. Les opérations ont été décrites ci-dessus par exemple relativement à la première couche dans le cas particulier d’un RS (Row Stationary) Dataflow et d’une couche convolutive de type Conv2D (cf. Y. Chen ae al. 2017. Eyeriss: An Energy-Efficient Reconfigurable Accelerator for Deep Convolutional Neural Networks. IEEE Journal of Solid-State Circuits 52, 1 (Nov. 2017), 127–138). D’autres types d’exécution Dataflow (WS Weight-Stationnary Dataflow, IS Input-Stationnary Dataflow, OS Output-Stationnary Dataflow, etc) impliquant d’autres schémas de réutilisation des données entre PE donc d’autres chemins de transfert, d’autres organisations des calculs, d’autres types de couches CNN (Fully Connected, PointWise, depthWise, Residual) etc. peuvent être mises en œuvre selon l’invention : les transferts des données de chaque type de données (filtre, ifmap, psum), pour leur réutilisation parallèle, doivent pouvoir ainsi être réalisés dans l’une quelconque des directions possibles dans les routeurs, et ce en parallèle des transferts de données de chaque autre type (on notera que des modes de réalisation peuvent bien sûr n’utiliser que certaines des options proposées : par exemple, la réutilisation spatiale d’un sous-ensemble seulement des types de donnée parmi les données de type filtre, Input Feature Maps, sommes partielles). A cette fin, l’accélérateur est paramétrable afin d’adapter l’accès aux données d’entrée dans les mémoires et d’adapter le sens d’envoi des données, en fonction notamment du type de couche de réseau de neurones à exécuter. Deux aspects innovants sont maintenant décrits. Ils sont, dans l’exemple considéré mis en œuvre tous les deux dans le même système 2. Toutefois, ils sont indépendants l’un de l’autre et chacun peut être mis en œuvre dans un système sans que l’autre ne le soit. Ces deux aspects innovants sont : - architecture à base de FSM et procédé de configuration correspondant - architecture avec emballage des données et procédé correspondant et sont décrits dans les chapitres ci-dessous. Architecture de circuit à base de FSM et procédé de CONFIGURATION correspondant Dans un mode de réalisation, le bloc de contrôle global 10 comprend, en référence aux figures 1 et 5, un registre de configuration 20 et une machine à états finis 40, dite FSM 40. Dans un mode de réalisation, cette FSM 40 du bloc de contrôle global 10 est configurable en fonction d’un mot de configuration. Le bloc de contrôle global 10 pilote le fonctionnement de l’accélérateur 1 pour le calcul des ofmaps par chaque couche d’un réseau de neurones DNN qui y est exécuté. Pour ce faire, le bloc de contrôle global 10, par le déroulement de la FSM 40, sur la base d’un mot de configuration associé sélectivement à chaque couche, est adapté pour identifier la forme de la couche C_i qui est maintenant à exécuter, pour configurer sa FSM 40 en fonction de ce mot de configuration, pour ensuite dérouler cette FSM configurée ce qui donne lieu au déclenchement de l'alimentation des nœuds de calcul 14 avec les données caractéristiques d'entrée (ifmaps) et filtres stockés dans l’ensemble 13 des mémoires tampons, à l’attente de la fin de l'exécution de la tâche en cours, et permet de synchroniser l’accélérateur 1 pour déclencher une nouvelle exécution. Ceci est répété jusqu'à la fin du calcul, lorsque les résultats en sortie de la couche sont récupérés de l’ensemble 13 de mémoire tampon et envoyés à la DRAM 19, via le contrôleur DMA 18. La FSM 40 du bloc de contrôle global 10 comprend dans l’exemple considéré, cinq états 41 à 45, qu’elle parcourt en boucle, de la façon décrite plus bas en référence à la FIG. 2 . Les cinq états sont « INACTIF » 41, « CHARGEMENT CONFIGURATION » 42, « CHARGEMENT filtre » 43, « CHARGEMENT ifmap » 44 et « ATTENTE » 45. Des règles régissent d’une part le nombre de fois où un même état 4i est réitéré (règle r ii ) et d’autre part le déclenchement d’une transition d’un état 4i à un état 4j (règle r ij ), avec i et j entiers de 1 à 5. Ces règles sont notamment fonction de réception de signaux de contrôle et de valeurs courantes de compteurs. Le rebouclage permet de rester dans un état jusqu’à la fin de la tâche à réaliser par cet état. Le rebouclage ou la transition d’un état à un autre permet de passer à une autre fonction à réaliser par l’accélérateur 1. Dans l’état « INACTIF » 41, le bloc de contrôle global 10 est inactif (il reboucle ainsi dans cet état) jusqu’à réception d’un signal indiquant qu’une exécution d’un réseau de neurones est à lancer par l’accélérateur 1 (r 12 ). L’état « CHARGEMENT CONFIGURATION » 42 permet de configurer notamment la FSM 40 en fonction du mot de configuration associé à la couche courante à exécuter, comme cela est davantage décrit plus bas en référence à la FIG. 2 , puis d’envoyer un signal de contrôle de lancement d’exécution (signal « start execution ») de la couche C_i au contrôleur de mémoire 12 et aux nœuds de calcul 14. L’état « CHARGEMENT filtre » 43, déclenche, via l’envoi du signal de contrôle « Load filter » par le bloc de contrôle global 10, aux nœuds 14, l’envoi des données d’un filtre utilisé par la couche considérée, depuis des mémoires tampons prédéfinies de l’ensemble 13 de mémoires tampons aux routeurs des nœuds 14 qui leur sont directement connectés. Ces données de filtre, comme l’ensemble des données circulant dans la grille 11 entre les routeurs 52 et communiquées entre routeurs voisins, sont accompagnés de mots de contrôle de communication associés permettant aux routeurs 52 de la grille 11 de router les données reçues. En fonction de ce mot de contrôle, les routeurs transmettent les données associées en unicast, multicast ou broadcast. La règle r33 conditionne le nombre de fois où la FSM reboucle dans cet état 43 ; elle dépend donc du nombre de données d’une ligne d’un filtre ; par exemple, elle est mise en œuvre avec un compteur dédié dont la valeur maximale est définie dans le mot de configuration 50 (champ 50_13, voir FIG. 6 ), défini plus loin. L’état « CHARGEMENT ifmap » 44 déclenche, via l’envoi du signal de contrôle « Load ifmap » par le bloc de contrôle global 10, aux nœuds 14, l’envoi des données ifmaps utilisées par la couche considérée, depuis des mémoires tampons prédéfinies de l’ensemble 13 de mémoires tampons aux routeurs qui leur sont directement connectés. En fonction du mot de contrôle associé respectivement aux données dans un paquet Payload (i.e. une donnée ifmap ou N PACK suivant les modes de réalisation : cf plus loin), les routeurs transmettent ces données en unicast, multicast ou broadcast. Le rebouclage dans l’état 44 est conditionné par l’application de la règle r 44 , fonction du nombre de données d’une ligne d’ifmap, via un compteur dédié dont la valeur maximale est définie dans le mot de configuration 50 (champ Ifmap_H 50_14 indiquant le nombre de lignes dans la matrice ifmap, voir FIG. 6 ), défini plus loin. Quand l’envoi à la grille 11 des données de filtre et des données ifmaps a été effectué, la FSM passe à l’état « ATTENTE » 45 (règle r 45 ) : le signal start_compute est alors envoyé par le bloc de contrôle global 10 aux nœuds de calcul 14 : les opérations MACs dans les nœuds de calcul 14 ont alors lieu ; une fois qu’une somme partielle est calculée dans un nœud 14 du dernier rang de la grille 1, la somme partielle est envoyée au nœud de calcul situé au Nord du nœud de calcul considéré ; ce nœud de calcul 14 ajoute la somme partielle reçue à la somme partielle qu’il a calculée localement et envoie à son tour le résultat au nœud de calcul 14 voisin situé au Nord ; ce traitement est poursuivi jusqu’à ce que l’accumulation des sommes dans un nœud de calcul 14 situé sur le premier rang de la grille ; la somme partielle correspondante est alors stockée dans la mémoire tampon de l’ensemble 13 associée au nœud de calcul (dans l’exemple le résultat provenant de N_0k est stocké dans OGB_k, k= 0 à 4), le cas échéant après traitement additionnel effectué par le bloc de pooling 15 et/ou le bloc d’activation 17 et/ou le bloc d’emballage 16. Quand ce traitement est achevé pour l’ensemble des nœuds 14 du premier rang de la grille, un signal de fin d’exécution de tâche (signal « End computation » reçu par la FSM) est envoyé par le nœud situé dans le coin nord-est de la grille (le nœud N_04 dans l’exemple), signalant la fin de l’exécution de la couche courante (la règle de rebouclage r 55 dans l’état 45 est donc fonction de la présence ou de l’absence de ce signal), la FSM retourne à l’état « CHARGEMENT CONFIGURATION » 42 (r 52 ). La donnée de somme partielle stockée dans la mémoire tampon de l’ensemble 13 associée au nœud de calcul sera alors suivant les cas envoyée en mémoire DRAM ou alors directement réinjectée dans la grille 11 pour le traitement de la couche suivante. La règle r54 pour piloter le basculement ou non de l’état 45 à l’état 44 est conditionnée par le nombre d’ifmap dans une couche ; elle est mise en œuvre via un compteur dédié dont la valeur maximale est définie dans le mot de configuration 50 (champ 50_25, voir FIG. 6 ), défini plus loin. La règle r53 pour piloter le basculement ou non de l’état 45 à l’état 43 est conditionnée par le nombre de filtres dans une couche ; la règle est mise en œuvre via un compteur dédié, dont la valeur maximale est définie dans le mot de configuration 50 (champ 50_23). La règle r52 déclenchant le basculement ou non de l’état 45 à l’état 42 est conditionnée par le signal « End computation » et l’atteinte des maximums des deux compteurs mentionnés précédemment en référence aux règles r 53 et r 54 . La règle r 21 est conditionnée par la fin de toutes les couches. Le contrôleur de mémoire 12 comporte, dans un mode de réalisation, en référence à la FIG. 3 , une simple machine à états finis 30 (FSM) pour déclencher la lecture des données d'entrée de la DRAM 19 vers des mémoires tampons de l’ensemble 13 (par exemple, dans le mode de réalisation considéré, vers les IGB 13_1) et l'écriture des données de sortie de mémoires tampons de l’ensemble 13 (par exemple, dans le mode de réalisation considéré, les données des OGB 13_2) vers la DRAM 19, sur la base de signaux de contrôle indiquant l'état des mémoires et le traitement sur l'accélérateur 1. Le contrôleur de mémoire 12 comprend également un multiplexeur (MUX) 36 et un démultiplexeur (DEMUX) 35 pour gérer respectivement les accès mémoire tout-vers-un (en anglais « all-to-one ») et un-vers-tous (en anglais « one -to-all »). La FSM 30 envoie des signaux de contrôle au DEMUX 35 pour sélectionner celle des IGBs à remplir et envoie des signaux de contrôle au MUX 36 pour sélectionner celle des OGBs dont le contenu sera délivré. Comme représenté en FIG. 4 , les états de la boucle de la FSM 30 du contrôleur de mémoire 12 sont successivement : - état « INACTIF » 31 (en anglais IDLE), jusqu’à ce qu’un signal de départ soit reçu (en provenance de l’hôte externe (GPU ou CPU)), puis basculement dans l’état 32 ; - état « Remplissage configuration » 32, dans lequel les mots de configuration associés aux couches respectives du réseau de neurones à exécuter sont obtenus et chargés dans l’accélérateur 1, comme décrit plus loin ; le basculement de l’état 32 à l’état 33 est contrôlé par un compteur de nombre de mots de configuration dont la valeur seuil dépend donc du nombre de couches ; - état « Remplissage IGBs » 33, dans lequel les données de la DRAM (données d’entrée et données de filtre) sont chargées via le contrôleur DMA 18 et le DEMUX 35, dans les mémoires tampons IGBs, jusqu’à ce que les IGBs soient remplis (ce qui est indiqué via un compteur de nombre de données d’entrée et de données filtre, qui seront stockées dans les mémoires IGBs) ; puis basculement dans l’état 34 ; - état « attente EoE » 34 : cet état correspond à l’attente de la fin de l’exécution (EoE pour l’anglais « End of Execution ») des calculs relatifs aux données chargées dans les IGBs et ne nécessitant pas de nouveaux remplissages d’IGBs, jusqu’à ce qu’un signal indiquant la fin de l’exécution de toutes les couches d’un réseau DNN soit reçu (en provenance du bloc de contrôle global 10), puis basculement dans l’état 35 ; - état « Lecture OGBs » 35, dans lequel les mémoires tampons OGBs sont lues, puis transmises au MUX 36 pour stockage dans la DRAM 19 via le contrôleur DMA 18, jusqu’à ce que tous les OGBs aient été ainsi lus (ce qui sera indiqué via un compteur paramétré au préalable par le nombre des ofmaps de la dernière couche), puis re-basculement dans l’état « INACTIF » 31 (le basculement à l’état 31 est déclenché quand le compteur atteint la valeur maximale représentant le nombre de tous les ofmaps de la dernière couche). Dans un mode de réalisation, le contrôleur PE 58 de l’élément de traitement 50 d’un nœud de calcul 14 représenté en FIG. 7 comprend par exemple également une machine à états finis configurable régissant son comportement, notamment contrôlant : - le déclenchement ou non de la mise à jour des données de filtre ou d’ifpmaps ; - le déclenchement d’une opération spécifique parmi multiplication, addition, accumulation. Dans un mode de réalisation, les états de la machine à états finis du contrôleur PE 58 sont configurés en fonction du contenu de certains au moins de champs du mot de configuration relatif à la couche en cours de traitement, comme décrits ci-dessous. Procédé de configuration (des FSM notamment) en fonction du mot de configuration Dans un mode de réalisation, le système 2 de traitement de réseau de neurones est adapté pour mettre en œuvre le procédé de traitement de réseau de neurones 100 représenté schématiquement en FIG. 2 et comprenant un procédé de configuration. Considérons un réseau de neurones DNN prédéfini, comportant n couches successives C_1, …, C_n prédéfinies de réseau de neurones. Le système 2 est mis en œuvre pour fournir en entrée de l’accélérateur 1 les données d’entrée nécessaires, pour calculer les données de sortie correspondantes de ce réseau de neurones DNN. Un mot de configuration CONFIG_i a été préalablement prédéfini pour chacune de ces couches C_i, i = 1 à n, de la manière représentée en FIG. 6 dans un mode de réalisation. Le mot de configuration 50 se présente ici par exemple sous la forme d’un double mot de contrôle 50_1 et 50_2 (soit 2 x 32 bits au total). Le mot de configuration 50 comprend, de façon répartie entre les deux mots de contrôle 50_1 et 50_2 qui comprennent la valeur de paramètres définissant la couche associée au mot de configuration : - un champ 50_12, dit champ « layer », indiquant le type de couche de réseau de neurones (typiquement conv, dw, pw, pool, fc, …) ; - un champ 50_13, dit champ « Filter_H », indiquant la hauteur de filtre ; - un champ 50_14, dit champ « Ifmap_H », indiquant la hauteur des données d’entrée ifmaps ; - un champ 50_15, dit champ « Shift », indiquant la taille du saut de bits (en anglais « shift ») dans la fonction d’activation ; - un champ 50_16, dit champ « NumMac », indiquant le nombre d’opérateurs MAC par nœud de calcul 14 ; - un champ 50_17, dit champ « stride » indiquant le pas ; - un champ 50_18, dit champ « padding » indiquant la marge ; - un champ 50_22, dit champ « F », indiquant ’0’ en cas de filtre unique considérée dans la couche de réseau et indiquant ‘1’ si le nombre de filtres de la couche de réseau considérée est supérieur ou égal à 2 ; - un champ 50_23, dit champ « numFilter», indiquant le nombre de filtres de la couche considérée ; - un champ 50_24, dit champ « I », indiquant ’0’ en cas de de matrice de données d’entrée, ifmap, unique considérée dans la couche de réseau et indiquant ‘1’ si le nombre de d’images d’entrée de la couche de réseau considérée est supérieur ou égal à 2; - un champ 50_25, dit champ « Channel_I », indiquant le nombre d’images ifmap d’entrée pour la couche considérée. Comme dans le cas présent, le mot de configuration 50 se présente sous la forme d’un double mot de contrôle 50_1 et 50_2 (soit 2 x 32 bits au total), chaque mot de contrôle 50_1 et 50_2 comprend ici en outre un premier champ de 4 bits (dit champ opcode), respectivement 50_11 et 50_21 signalant qu’il s’agit d’une composante du mot de configuration 50. En référence à la FIG. 2 , dans une étape 101, préalablement à l’exécution par l’accélérateur 1 des traitements pour calculer les données de sortie d’un réseau de neurones DNN prédéfini auquel des données d’entrée sont fournies en entrée, la liste ordonnée des mots de configuration CONFIG_i, i = 1 à n, dans l’ordre de succession des couches depuis la couche d’entrée jusqu’à la couche de sortie, est mémorisée dans le système 2 et est rendue accessible au bloc de contrôle global 10 : on considère ici qu’elle est par exemple stockée dans le registre de configuration 20 du bloc de contrôle global 10. Le bloc de contrôle global 10 met alors en œuvre l’étape 102 avant le traitement effectif, par l’accélérateur 1, de chaque couche C_i, i = 1 à n. Le bloc de contrôle global 10 extrait du registre de configuration 20 le mot de configuration CONFIG_i pour la prochaine couche C_i à traiter : à ce stade, la FSM 40 du bloc de contrôle global est dans un état 42 « CHARGEMENT CONFIGURATION » (si toutes les couches de réseau de neurones ont été exécutées par l’accélérateur 1, la FSM 40 retourne à l’état « INACTIF 41). Dans cet état 42, les valeurs initiales de compteurs, dont sont fonction les règles de répétition d’un même état ou encore dont sont fonction les transitions d’un état à l’autre, sont fixées en fonction des champs concernés du mot de configuration CONFIG_i. Ainsi, dans cette étape 102, dans une sous-étape 102_1, le bloc de contrôle global 10, sa FSM 40 étant dans l’état 42, configure cette FSM 40 (laquelle va être utilisée pour orchestrer la part incombant au contrôleur global 10, de l’exécution de la couche C_i) en fonction de ce mot de configuration CONFIG_i . Notamment via la configuration de certaines au moins des règles de transition/rebouclage en fonction du mot de configuration CONFIG_i : il est fixé en fonction de ce mot de configuration le nombre de fois où un même état (par exemple l’état 43 ou 44) va être itéré, au cours du traitement de la couche C_i, , il est fixé le nombre de fois où on va transiter d’un état défini à un autre état défini au cours du traitement de la couche C_i, (par exemple passer de l’état 45 « ATTENTE » à l’état 44 « CHARGEMENT ifmap », ou encore le nombre de fois où on va passer de l’état 45 « ATTENTE » à l’état 43 « CHARGEMENT filtre», ou encore les cas où on passera directement de l’état 43 à l’état 45 (sans passer par l’état 44)). Par exemple, les transitions entre états sont à adapter pour l’exécution d’une couche où : - dans le cas d’une couche faisant intervenir k filtres (ce qui est indiqué par le champ 50_23 « numFilter » du mot de configuration) et t images ifmaps (ce qui est indiqué par le champ 50_25 « Channel_I » du mot de configuration), l’état 43 « CHARGEMENT filtre » sera à itérer k fois et l’état 44 « CHARGEMENT ifmap » sera à itérer t fois ; - plusieurs images et plusieurs filtres sont à traiter, ce qui peut donner lieu à des itérations de séquences « état 43 suivi d’état 44 suivi d’état 45 ») ; - si plusieurs images d’entrée ifmaps sont à traiter par un même filtre lors du traitement de la couche (ce qui est indiqué par le champ 50_23 « numFilter » du mot de configuration et par le champ 50_12 « layer » définissant le type de couche) : plusieurs états 44 « CHARGEMENT ifmap » seront à effectuer avec, suite à chaque chargement, la mise en œuvre des calculs (état 45), sans avoir à recharger les filtres (ce qui donnera lieu à itérations de la séquence « état 44 suivi d’état 45 ») ; ou - si plusieurs filtres sont à appliquer à une même image d’entrée ifmap : plusieurs états 43 « CHARGEMENT filtre » (en nombre défini par le contenu du champ 50_23) seront à effectuer avec, suite à chaque chargement, la mise en œuvre des calculs (état 45), sans avoir à recharger les données de ifmap (ce qui donnera lieu à plusieurs itérations de la séquence « état 43 suivi d’état 45 » sans passer par l’état 44). Dans un nœud 14, le bloc de calcul 51, y compris chaque opérateur MAC 57 qu’il comporte, est piloté par le FSM 40 du bloc de contrôle global 10. Il est adapté pour rester à l'état inactif jusqu'à ce que le bloc de contrôle global 10 déclenche l'exécution (par envoi du signal de contrôle « start execution), puis pour procéder ainsi en fonction des signaux de contrôle envoyés par le bloc de contrôle global 10 : lorsque le signal load_filter est reçu par un nœud de calcul 14, le bloc de calcul 51 du nœud 14 stocke la charge utile entrante dans le registre du filtre (RF 511) ; une fois que tous les nœuds de calcul 14 ont reçu leurs données de filtre correspondantes (i.e. une fois que le nœud de calcul 14 en haut à droite de la grille 11 les a reçues), le contrôleur 58 de ce nœud de calcul 14 en haut à droite de la grille 11 (chaque nœud connaît sa position dans la grille 11) envoie alors un signal au bloc de contrôle global 10 pour que la FSM 40 passe à l'état suivant (ce qui correspond à la règle de transition r 34 ) ; dans un mode de réalisation, le passage à l’état 44 « CHARGEMENT ifmap » du FSM 40 (ce qui correspond à la règle de transition r 34 ) se fait un cycle après l’état de chargement des filtres, ce qui permet d’assurer la propagation simultanée de deux types de données dans la grille 11 et assure le recouvrement communication/communication afin de réduire le temps d’exécution ; lorsque le signal load_ifmap est reçu par un nœud de calcul 14, le bloc de calcul 51 du nœud 14 stocke la charge utile entrante dans le RF ifmaps 510. Une fois que tous les nœuds 14 ont reçu leurs données ifmaps correspondantes, le nœud de calcul 14 envoie un signal au bloc de contrôle global 10 pour passer à l'état suivant de sa FSM 40 (ce qui correspond à la règle de transition r 45 ) ; dans un mode de réalisation, le passage à l’état ATTENTE du FSM 40 (ce qui correspond à la règle de transition r 45 ) se fait un cycle après l’état de chargement ifmap : ce cycle assure que les données ifmap aient été envoyées à la première colonne (à gauche) et la première ligne (dans un mode de réalisation : le bas [la première couche du DNN] ou le haut [les couches profondes du DNN]) de la grille 11 ; de ce fait, un déclenchement de calcul sera fait en parallèle à la propagation des données ifmaps dans le réseau, ce qui assure le recouvrement communication/calcul afin de réduire le temps d’exécution ; le bloc de calcul 51 du nœud 14 commence l'opération MAC sur ses données de filtre et ses données ifmaps dès que ces données sont présentes dans les RF 511, 510 et génère PSum. Ensuite, soit il envoie le PSum au nœud Nord (si nœud de la rangée du bas), soit (ii) ajoute le PSum entrant du nœud sud avec le PSum local et envoie le résultat au nœud nord ou à l'OGB 13_2 associé (si nœud de la rangée supérieure). Dans cette phase, le chevauchement communication-calcul est également effectué par le NPE, qui a reçu les données requises. A la fin du calcul, un signal end_computation sera envoyé par le dernier nœud 14 (le dernier nœud, dans le cas considéré, est dans le coin à droite et en haut de la grille active) de la grille pour informer le bloc de contrôle 10 de la fin de l'exécution, afin de passer à l'exécution suivante et au chargement de nouvelles données. Dans un mode de réalisation, à l’issue ou en parallèle de l’étape 102_1, dans une sous-étape 102_2, dans l’état 42 « CHARGEMENT configuration », le bloc de contrôle global 10 transmet en outre le mot de configuration 50 (ou au moins certaines des informations contenues dans ce mot de configuration) de la couche C_i courante à traiter, par exemple en parallèle du signal « start execution », aux nœuds de calcul 14 et/ou au contrôleur de mémoire 12, et dès réception de ce mot de configuration, un nœud de calcul 10 et/ou le contrôleur de mémoire 12 configure son traitement (par exemple par la configuration d’une FSM locale utilisée pour orchestrer sa part de l’exécution de la couche C_i) en fonction de ce mot de configuration CONFIG_i. Le nœud de calcul 14 comporte par exemple un contrôleur PE 58 comprenant une machine à état (FSM) adaptée pour, suite à la réception du mot de configuration CONFIG_i envoyé par le bloc de contrôle global 10, se synchroniser avec le bloc de contrôle global 10 et configurer cette FSM en fonction du mot de configuration. Cette disposition permet par exemple de fixer combien d'opérations sont à effectuer localement au nœud pour la couche C_i. La FSM du contrôleur PE 58 est par exemple composée de 4 états : « Idle », « Mul », « acc », « add ». La transition de « idle » à « mul » est déclenchée par la réception du signal ‘start execution’ (du bloc de contrôle global 10), la disponibilité des données dans les RF 511, 510 (filtre et ifmap), et dans des modes de réalisation en fonction en outre d’autres signaux configurés par le mot de configuration notamment par les champs 50_12, 50_13 et 50_14. La transition de « mul » à « acc » est déclenchée systématiquement au cycle suivant. La transition de « acc » à « add » est déclenchée quand un compteur dédié atteint sa valeur maximale qui est la hauteur du filtre diminuée de 1 (l’information de hauteur est extraite du champ 50_13 du mot de configuration). L’état « add » reboucle sur lui-même en attendant l’arrivée de la somme partielle PSum du PE voisin du sud. Une fois cette somme partielle arrivée, il effectue l’addition requise et crée le mot de contrôle associé à cette donnée actualisée de somme partielle et l’envoie au PE voisin du nord. On passe ensuite à l’état « mul » ou « idle » selon les conditions ci-dessous : le rebouclage de l’état « add » à « mul » est fonction de la valeur courante d’un compteur dédié dont la valeur maximale est celle de la taille d’une ligne ofmap (la formule est donnée plus haut et utilise les valeurs des champs Filter_H 50_13, Ifmap_H 50_14, stride 50_17 et padding 50_18 du mot de configuration 50 : cf. FIG. 6 ) ; la transition de « add » à « idle » est déclenchée quand le compteur atteint la valeur max du ofmap ; à ce moment, le PE 50 envoie le signal « End_computation ». Ces dispositions permettent ainsi dans les nœuds 14, aux contrôleurs PE 58 de configurer leur FSM pour déclencher les calculs MAC dès réception de données de filtre en réutilisant des données ifmaps précédemment chargées et déjà utilisées pour un précédent calcul, par exemple si plusieurs filtres sont à appliquer sur les mêmes données ifmap lors du traitement d’une couche donnée (ou vice-versa pour déclencher les calculs MAC dès réception de données ifmaps en réutilisant des données de filtre précédemment chargées et déjà utilisées pour un précédent calcul, par exemple si un même filtre est à appliquer sur plusieurs ifmaps). Le type de la couche détermine si pour un nouveau calcul, un PE 58 attend une nouvelle donnée ifmap/filtre, ou alternativement conserve celle déjà chargée pour le calcul précédent, ainsi que le contenu de certains des champs du mot de configuration, tels que le champ 50_23 « numFilter », le champ 50_25 « Channel_I », le champ 50_12 « layer ». Dans un mode de réalisation, le PE 50 d’un nœud 14 est paramétrique : il est paramétré dynamiquement pour l’exécution de la couche à traiter, il comporte ainsi un opérateur MAC 57 (par exemple pour traiter une couche de convolution dépendant d’un mode de fonctionnement RS), ou bien plusieurs, opérateurs MAC 57 (par exemple pour traiter plusieurs convolutions en parallèle dans le même nœud 14 ou pour gérer deux branches de décisions dans un DNN dynamique). Par exemple, si le DNN doit être exécuté en mode statique Row Stationary (RS) avec des filtres de taille 3x3, un seul opérateur MAC 57 est généré pour exécuter trois MAC successifs sur trois cycles, ou trois opérateurs MAC 57 sont générés pour une exécution parallèle de ceux-ci en un seul cycle. Dans le cas d’une exécution sur un DNN dynamique où il existe une deuxième branche pour la prise de décision en parallèle avec la branche initiale du réseau DNN classique, la génération de deux opérateurs MAC 57 permet de traiter les deux branches simultanément et de parvenir à une prise de décision la plus rapide possible sans compromettre le calcul. Alternativement, quatre opérateurs supplémentaires MAC 57 peuvent être générés pour donner trois opérateurs fonctionnels pour chaque branche, afin d'ajouter un deuxième niveau de parallélisme. Dans le cas de plusieurs opérateurs MAC 57 paramétrés dans un PE 50, ils sont tous interfacés avec le même routeur 52 et le même contrôleur d’horloge 53 du PE 50. Dans un mode de réalisation, l’accélérateur est implémenté sur un FPGA comportant des éléments de logiques (portes logiques) programmables dynamiquement. Lorsque le contrôleur PE 58 reçoit le mot de configuration en provenance du bloc de contrôle global 10, il configure l’élément de traitement PE 50 de manière à ce que ce dernier comporte un nombre de blocs de calcul (et donc d’opérateurs MAC) égal au nombre indiqué dans le champ 50_16 « NumMac » en programmant des portes logiques du FPGA en fonction du champ 50_16 « NumMac ». Ainsi il ne s’agit pas comme dans le cas du mécanisme clock gating, d’une mise en veille d’opérateurs de calcul inutiles, mais bien d’une redéfinition des circuits. Dans un mode de réalisation, un mécanisme d’envoi des données, depuis une mémoire locale de l’ensemble 13 des mémoires tampon vers un nœud de calcul ou inversement, définit le ou les destinataires des données (figurant dans le paquet de données discuté en FIG. 8 en fonction du mot de configuration courant et/ou suivant. Les données d’entrée de la première couche et les données de tous les filtres dans le réseau DNN donnée sont stockés préalablement dans les mémoires tampon 13_1 (IGB) selon la forme donnée dans la FIG. 8 . Ceci est effectué par l’intermédiaire du contrôleur de mémoire 12. Les données de filtre sont associées à des mots de contrôle assurant un multicast horizontal et les données d’entrée sont associées à des mots de contrôle assurant un multicast diagonal. Les données de sortie du calcul de chaque couche, deviendront les entrées de la couche suivante. Dans ce cas, dans un mode de réalisation, le module d’emballage 16 génère les mots de contrôle à associer à ces données en fonction du type de la couche à traiter par la suite. Les dispositions exposées dans le présent chapitre permettent d’obtenir une architecture compacte d’une part et d’autre part aisément adaptable et configurable, permettant ainsi d’exécuter différents types de couches DNN et de réseaux de neurones. En effet, alors qu’il est connu jusqu’alors que 2 types de coprocesseur IA : - soit une architecture câblée intégralement qui exécute toujours la même chose (row stationnary ou autre), les données étant envoyées toujours de la même façon, ce qui donne une architecture compacte, efficace mais non reconfigurable ; - soit une architecture SIMD ou MIMD programmable – chaque nœud doit faire le processus (chargement des données (fetch) – décoder instructions – exécuter instructions), ce qui donne une architecture reconfigurable, mais pas compacte (il faut un processeur dans chaque nœud) et consommatrice. La solution proposée permet, grâce à l’utilisation de « simple FSM » (à la place de processeur) et d’un mécanisme léger de paramétrisation de la FSM par mot de configuration, d’avoir une architecture relativement compacte et reconfigurable pour pouvoir réaliser tout type de réseau de neurones. Architecture de circuit avec emballage des données Comme vu précédemment, les données circulant dans l’accélérateur 1 sont transférées par le routeur de chaque nœud en fonction d’un mot de contrôle associé à chaque donnée (cf. FIG. 8 ). Dans un mode de réalisation, le bloc d’emballage 16 est adapté pour, entre le traitement mis en œuvre par la grille 11 pour traiter une couche, C_i, i = 1 à N-1, du réseau de neurones et le traitement mis en œuvre par la grille 11 pour traiter la couche suivante, C_i+1, déterminer, en fonction du mot de configuration CONFIG_i+1, qui lui est fourni par le bloc de contrôle global 10, le mot de contrôle associé à certaines au moins des données d’entrée de la couche C_i+1 quand elles sont issues également des données de sortie de la grille 11 après son traitement relatif à la couche C_i, (i.e. des données d’images ifmap de la couche C_i+1, qui sont les résultats d’accumulation psum de la couche C_i. Ainsi, dans un mode de réalisation, le bloc d’emballage 16 détermine, en fonction du type de couche indiqué dans le champ « layer » 50_12 du mot de configuration pour la couche C_i+1 et d’une table de correspondance stockée par exemple dans le bloc d’emballage 16 (ou bien qui lui est accessible) le type de diffusion (unicast, broadcast, multicast), ainsi que le destinataire (unicast) ou alors le sens de la diffusion (multicast) parmi les sens suivants : E ou O (si multicast horizontal), S ou N (si multicast vertical), NE ou NO, ou SE, ou SO (si multicast diagonal) : ces informations conditionnent la structure des mots de contrôle considérés. Par exemple, la table de correspondance indique : - une communication multicast diagonale SO si la couche est une couche conv cachée ; - une communication unicast à tous les nœuds de la grille 11 si la couche est une couche entièrement connectée (fc) ; - une communication unicast à tous les nœuds de la grille 11 si la couche est une couche pointwise ; - une communication multicast verticale SO si la couche est une couche depthwise. Il existe plusieurs implémentations possibles de ce mécanisme d’emballage. Par exemple, dans un mode de réalisation, le procédé de traitement suivant 200 est mis en œuvre par l’accélérateur 1, en référence à la FIG. 17 . Dans une étape 201, une donnée de sortie ofmap résultat des accumulations effectuées lors du traitement par la grille 11 de la couche C_i est délivrée au bloc d’emballage 16 (facultativement, cette donnée est d’abord traitée par le bloc d’activation 17, puis la donnée résultante est fournie au bloc d’emballage 16) par un nœud 14 chargé de la dernière accumulation réalisée avant fourniture du résultat de cette accumulation de la grille, par exemple, dans les exemples décrits précédemment le nœud N_0i (i= 0 à 4) de la première ligne de la grille 11 (même si en réalité, les accumulations peuvent alternativement par reconfiguration être réalisées, verticalement mais vers le sud, ou encore horizontalement vers l’E ou l’O ; par exemple via une reconfiguration statique basée sur un paramètre générique ou via une reconfiguration dynamique, basée sur l’exploitation d’un champ dédié dans le mot de configuration et indiquant le sens de l’accumulation). Dans une étape 202, dès que le bloc d’emballage 16 a reçu N PACK données ofmaps fourni(s) par le nœud N_0i (N PACK est une valeur entière paramétrable supérieure ou égale à 1 ; dans l’exemple représenté en FIG. 11 , N PACK est strictement supérieur à 1, par exemple il a été choisi égal à 3, il les insère dans un paquet de données utiles 160 et génère le mot de contrôle - commun - associé à ces données ofmaps, en fonction de la table de correspondance et en fonction (comme indiqué plus haut) du mot de configuration CONFIG_i+1 de la future couche, C_i+1, du réseau à exécuter. Puis le double paquet de données résultant (le paquet de contrôle comportant le mot de contrôle et le paquet de données utiles associé, voir FIG. 8 ) est fourni à la mémoire tampon OGB _i, associée au nœud N_0i, pour y être stockée (si l’activation n’a pas été réalisée en amont du bloc d’emballage, elle peut être effectuée le cas échéant avant stockage dans la mémoire tampon). Les paquets (ou mots) de données utiles, nommés aussi paquets Payload, sont créés en fonction des informations figurant dans le champ 50_14 (I fmap_H) du mot de configuration de la future couche. Par exemple, dans un cas où N PACK =3 : si le champ 50_14 indique 6, le « découpage » suivant est fait : deux mots de données utiles dont chacun contient 3 données ifmap ; si le champ 50_14 indique 5, deux mots de données utiles sont constitués dont le premier contient 3 données ifmap et le deuxième contient 2 données ifmap complétées par des zéros (bourrage de zéros). Le nombre de mots de contrôle à générer est fonction des valeurs des champs 50_14 et 50_25 : il est égal à (Ceil (Ifmap_W/Npack)*Ifmap_H) * Channel_I, où Ceil (x) est une fonction mathématique qui renvoie le plus petit entier supérieur ou égal à x. Dans le cas de matrice régulière considérée ici à titre d’illustration : Ifmap_W= Ifmap_H, ce qui correspond au champ 50_14. Le choix de 3 pour N PACK est relatif à la taille des données véhiculant dans la grille 11 et qui est dans le cas considéré d’une valeur de 32 bits. Sachant que les opérateurs manipulent dans le cas considéré des données de taille 8-bits (les résultats sont aussi de 8 bits), dans un paquet de 32-bits peuvent être insérés un flit d’en-tête de 4-bits plus 3 mots maximum de 8-bits. Si des opérateurs manipulant des données de taille 6-bits, 4-bits ou autres sont utilisés, plus de 3 mots seront insérés dans un même paquet. Dans une étape 203, l’exécution de la couche de réseau de neurones C_i+1 est lancée par le bloc de contrôle global 10 ; il est déterminé, le cas échéant, en fonction du mot de configuration par le bloc de contrôle 10 que les données d’entrée ifmaps de la couche C_i+1 sont celles alors stockées dans les mémoires tampons OGB _i (par exemple, un mécanisme dans le contrôleur global 10 incrémente un compteur à chaque mot de configuration nouvellement rencontré et quand la valeur est strictement supérieure à 1, en déduit que le mot de configuration est celui d’une couche profonde et donc que les données d’entrées sont déjà stockées dans les OGB). Le bloc de contrôle 10 déclenche donc la fourniture des paquets stockées dans la mémoire OGB _i au nœud d’entrée de la grille, qui est associé à cette mémoire dans la grille 11, i.e. ici le nœud N_0i. Comme indiqué, le nœud N_0i débute donc la diffusion de la donnée ifmap reçue conformément au type de communication (unicast, multicast horizontal, multicast vertical, multicast diagonal ou broadcast) indiqué dans le mot de contrôle associé à la donnée d’entrée. Et la diffusion de la donnée pourra ainsi être réalisée de nœud en nœud, sur la base du mot de contrôle associé. Le fait de regrouper dans un paquet de données N PACK données ofmaps permet de ne charger (idem pour le retrait de la mémoire vers la grille lors de l’exécution de la couche suivante C_i+1) qu’une fois la mémoire tampon plutôt que N PACK fois. Dans un autre mode de réalisation, les N PACK données ofmaps sont stockées en un paquet de données dans la mémoire OGB_i, mais cette fois sans opération d’emballage par le bloc d’emballage 16. Et quand l’exécution de la couche de réseau de neurones C_i+1 est lancée par le bloc de contrôle global 10, il est déterminé en fonction du mot de configuration par le bloc de contrôle 10 que les données d’entrée ifmaps de la couche C_i+1 sont celles alors stockées dans les mémoires tampons OGB _i, et le bloc de contrôle 10 déclenche alors la fourniture des paquets stockées dans la mémoire OGB _i au bloc d’emballage 16. Dans cet autre mode de réalisation, le bloc d’emballage 16, une fois qu’il a reçu le paquet de N PACK données ofmaps fourni(s), détermine, comme indiqué à l’étape 202, le mot de contrôle - commun - associé à ces données ofmaps, en fonction de la table de correspondance et en fonction (comme indiqué plus haut du mot de configuration CONFIG_i+1 de la couche C_i+1 dont l’exécution vient d’être déclenchée. Puis le double paquet de données résultant, constitué du paquet de données utiles et du paquet du mot de contrôle associé, est fourni au nœud d’entrée (correspondant à la mémoire OGB_i) dans la grille 11, i.e. ici le nœud N_0i (le mot de contrôle est en outre fonction du mode d’exécution choisi lorsqu’il y en a plusieurs possibles, par exemple WS, IS, OS). Et ainsi, pour chaque couche C_ i+1, le type et le sens de communications des données d’entrée ifmap de la couche sont définis en fonction du type de couche indiqué dans le mot de configuration, en fonction de la mémoire 13 de stockage ( donc du nœud de la grille, qui est associé à cette mémoire de stockage et auquel seront fournies les données extraites de cette mémoire au début de l’exécution de la couche C_i+1) et en fonction des données de sortie ofmaps de la couche précédente dans la grille 11 de l’accélérateur 1. Le traitement d’emballage dans les deux modes de réalisation exposés par la section ci-dessus, utilisant un bloc d’emballage 16 local, disposé entre les nœuds 14 et la mémoire locale 13, autonome dans son opération d’emballage (indépendant du bloc de contrôle global 10) simplifie les opérations de communication des données, diminue les accès aux mémoires extérieures à l’accélérateur 1 (par exemple la DRAM 19) et in fine permet une plus grande parallélisation des opérations. On notera que tous les nœuds 14 sont constitués de la même manière. Les nœuds d’entrée de la grille (i.e. qui reçoivent les données ifmaps ou filtre d’une couche courante à exécuter) ou par les nœuds de sortie de la grille (i.e. qui délivrent hors de la grille 11 les résultats d’accumulation) savent, avant une exécution de couche, qu’ils sont respectivement nœuds d’entrée ou de sortie (par exemple il est indiqué aux nœuds que les nœuds de telle ligne ou de telle colonne sont concernés) de la grille, et ils exécutent alors les fonctionnalités spécifiques de traitement de ces nœuds d’entrée ou de sortie (typiquement, réception des ifmaps des données tampons ou encore fourniture à une mémoire tampon, ou à un bloc d’activation ou un bloc d’emballage des données d’accumulation). Sont décrits ci-après des cas mettant en œuvre un accélérateur dans des modes de réalisation de l’invention : La FIG. 12 donne un aperçu de différents types de mouvement des données dans l’accélérateur 1 (section gauche de la FIG. 12 pour la première couche d’un DNN considéré déjà commentée plus haut pour illustrer le recouvrement communication/calcul), section droite pour les couches cachées du DNN). La section droite de la FIG. 12 illustre le traitement d’une couche cachée de type convolution dans un mode de réalisation de l’invention, où les ifmaps sont donc envoyées en diagonale depuis les OGB_i (In rowi+1 venant de OGB_i, i = 0 à 2) (par application du procédé 200 décrit plus haut), les filtres sont envoyés horizontalement (F rowi+1 venant de IGB_i, i = 1 à 3), et l'accumulation de PSum est effectuée en accumulant les résultats de chaque nœud dans une colonne en les déplaçant verticalement. Enfin, les nœuds de la rangée supérieure stockent respectivement les données ofmap dans les OGB de l’ensemble de mémoires 13_2. En considérant à présent la FIG. 13 , qui illustre l’exécution d’une première couche de convolution avec une valeur de stride qui est de 1, la taille des ifmaps qui est de 7x5 [ligne*colonne], la taille du filtre qui est de 3x3, la taille de ofmap est de 5x3 et la taille de la grille 11 à utiliser est 3x5. Il y a 7 IGB et 5 OGB utilisés dans cet exemple pour expliquer le modèle d'exécution. 7 lignes d’entrée ifmap, r1, r2, …, r7 sont envoyées via les IGB en utilisant la multidiffusion diagonale Nord-Est vers la grille 11 des nœuds 14, et 3 lignes de filtres sont envoyées à la grille 11 en utilisant la multidiffusion verticale. Une fois que toutes les données requises sont disponibles dans une colonne de nœuds, les nœuds de cette colonne particulière commencent le calcul tandis que les autres nœuds reçoivent toujours leurs données respectivement. De cette façon, un chevauchement entre les calculs de communication est établi. Une fois qu'un nœud est prêt avec un PSum, les données sont envoyées à son nœud Nord en utilisant la monodiffusion verticale. Du côté réception, le nœud attend que la donnée arrive du nœud Sud (une exception est ajoutée pour les nœuds de la rangée du bas qui n'ont aucun nœud connecté à leur Sud) ; une fois que la donnée est disponible au niveau de la broche de données d'entrée du nœud, le PSum local est ajouté à la donnée entrante et envoyé au nœud Nord. Une telle chaîne de calcul est exécutée jusqu'à ce que la dernière PSum de ofmap soit accumulée et stockée dans les OGB (ligne Ri+1 de Ofmaps vers OGB_i depuis N_0i, i = 0 à 4). Ce processus est répété jusqu'à ce que tous les ifmaps et filtres de cette couche de convolution particulière soient utilisés pour calculer les ofmaps requis. La FIG. 14 illustre l’exécution d’une couche cachée de type convolution ou depthwise : telle que les ofmap de la couche précédente sont au départ déjà stockés dans les OGB (suite par exemple au traitement d’une première couche telle qu’illustré en FIG. 13 ) ; ces données deviennent les ifmaps de la couche actuelle (le procédé 200 a par exemple été appliqué). Ici, les ifmaps sont envoyés en diagonale Sud-Ouest depuis les OGB (ligne Ri+1 de Ofmaps depuis OGB_i vers N_0i, i = 0 à 4). Les filtres sont envoyés horizontalement depuis les IGB. Suit ensuite la phase d'accumulation de PSum, et enfin les données Ofmaps sont respectivement stockées dans leurs OGB. Ici, les données ifmap sont envoyées des OGB à la grille 11 en utilisant la multidiffusion diagonale, et les données de filtre sont envoyées à la grille 11 en utilisant la multidiffusion horizontale. Une fois que toutes les données requises sont disponibles dans une colonne de nœuds, les nœuds de cette colonne particulière commencent le calcul tandis que les autres nœuds reçoivent toujours leurs données respectivement. Une fois qu'un nœud est prêt avec un PSum, cettea donnée est envoyée à son nœud vertical en utilisant la monodiffusion verticale. Du côté réception, le nœud attend que la donnée arrive du nœud Sud (une exception est ajoutée pour les nœuds de la rangée du bas qui n'ont aucun nœud connecté à leur Sud), une fois que la donnée est disponible à l'entrée du nœud, le PSum local est ajouté à la donnée entrante et envoyé au nœud Nord. Une telle chaîne de calcul est exécutée jusqu'à ce que la dernière PSum de ofmap soit accumulée et stockée dans les OGB. Ce processus est répété jusqu'à ce que tous les ifmaps et filtres de cette couche de convolution particulière soient utilisés pour calculer les ofmaps requis (lignes Ofmap R1’, R2’, R3’). La FIG. 15 illustre l’exécution d’une couche de type pointwise: les ifmaps sont envoyés en unicast à partir de l’ensemble de mémoires tampon OGB 13_2 et les données de filtre sont envoyées horizontalement à partir des IGB 13_1. Suit ensuite la phase d'accumulation de PSum, et enfin les données ofmaps sont respectivement stockées dans leurs OGB. Ici, 5 lignes (ri_j, i = 1 à 5 de 3 ifmaps différentes (Ifmap_j, j=1 à 3) sont envoyées des OGB à la grille 11 en utilisant l’unicast ou unidiffusion parallèle, et 3 copies des données de filtre sont envoyées à la grille 11 en utilisant la multicast horizontal. Une telle distribution de données est effectuée pour utiliser les ressources matérielles. Une fois que toutes les données requises sont disponibles dans une colonne de nœuds, les nœuds de cette colonne commencent le calcul tandis que les autres nœuds reçoivent toujours leurs données respectivement. Une fois qu'un nœud est prêt avec un PSum, les données sont envoyées au nœud au Nord en utilisant l’unicast vertical. Du côté réception, le nœud attend que les données arrivent du nœud Sud (une exception est ajoutée pour les nœuds de la rangée du bas qui n'ont aucun nœud connecté à leur Sud). Une fois que les données sont disponibles au niveau de l’entrée du nœud, le PSum local est ajouté aux données entrantes et envoyé au nœud Nord. Une telle chaîne de calcul est exécutée jusqu'à ce que la dernière PSum de ofmap soit accumulée et stockée dans les OGB (les données stockées en OGB_i, i = 0 à 4 permettent d’obtenir la rangée Ri+1 de Ofmap). Ce processus est répété jusqu'à ce que tous les ifmaps et filtres de cette couche de convolution particulière soient utilisés pour calculer les ofmaps requis. La FIG. 16 montre l'exécution d’une couche de type entièrement connectée (« fully connected »). En raison de l'architecture des CNN, des ofmaps de la couche précédant la couche entièrement connectée prennent la forme d'une seule colonne qui est stockée dans le premier OGB. Ainsi, les ifmaps pour les couches entièrement connectées sont envoyées depuis le premier OGB en utilisant l’unicast. Les données de filtre divisées en 3 lignes égales sont envoyées en unicast. Suit ensuite la phase d'accumulation de PSum, et enfin les données ofmaps sont respectivement stockées dans leurs OGB. Ici, les données ifmap divisées en 3 lignes (c'est-à-dire le nombre de lignes dans la grille 11) sont envoyées à la grille de nœuds 11 en utilisant l’unicast, et les données de filtre sont divisées en 3 lignes et sont envoyées dans la grille 11 en utilisant l’unicast. Une fois que toutes les données requises sont disponibles dans une colonne de nœuds, ceux-ci commencent le calcul pour calculer PSum. Une fois que tous les nœuds ont leur PSum prête, l'accumulation de PSum dans chaque ligne est effectuée en parallèle en envoyant des données au nœud ouest en unicast. Du côté de la réception, le nœud attend que la donnée arrive du nœud Est (une exception est ajoutée pour les nœuds de la colonne la plus à droite qui n'ont aucun nœud connecté à leur Est), une fois que la donnée est disponible au niveau de l'entrée du nœud, le PSum local est ajouté à la donnée entrante et envoyé au nœud Ouest. Une telle chaîne de calcul est exécutée jusqu'à ce que les nœuds les plus à gauche aient effectué l'accumulation de PSum. Ensuite, les données sont envoyées à leur nœud vertical en utilisant l’unicast vertical. Du côté réception, le nœud attend que la donnée arrive du nœud Sud (une exception est ajoutée pour les nœuds de la rangée du bas qui n'ont aucun nœud connecté à leur Sud), une fois que la donnée est disponible au niveau de l'entrée du nœud, le PSum local est ajouté à la donnée entrante et envoyé au nœud Nord. Le nœud en haut à gauche, (c'est-à-dire PE_0_0) stocke la valeur accumulée dans l'OGB_0. On notera que l’aspect « configuration (des FSM notamment) en fonction du mot de configuration » et l’aspect « emballage des données » peuvent être implémentés l’un indépendamment de l’autre et que dans des modes de réalisation d’accélérateur, seul un quelconque des deux aspects est mis en œuvre. L’invention propose ainsi une solution d’exécution du flot de données paramétrable, permettant d’assurer la flexibilité des traitements et réduire la consommation d’énergie dans les architectures spécialisées de réseaux de neurones convolutifs (CNNs) d’inférences. L’invention a été décrite ci-dessus dans une implémentation sur NoC. D’autres types d’architectures Dataflow peuvent néanmoins être utilisées. Dans l’exemple considéré, l’ensemble 13 de mémoires tampons comprend les mémoires tampons 13_1 destinées à stocker les données ifmaps et les données filtres et les mémoires tampons 13_2, destinées à stocker les résultats (ofmaps) de la première couche, délivrés par les nœuds de la première ligne de la grille après accumulation des résultats psum des nœuds par colonne, qui sont aussi, dans des modes de réalisation, des données ifmaps de couches cachées. D’autres configurations de mémoires tampons peuvent être utilisées, par exemple, comportant plus de mémoires tampons ou bien moins de mémoires tampons : par exemple, les mêmes mémoires tampons peuvent stocker d’abord les données ifmaps et les données filtres, puis les résultats d’accumulation, moyennant une orchestration du flux adaptée, et des temps de traitement plus ou moins longs. Au moins une rangée de mémoires locales est prévue, chaque rangée de mémoire locale étant positionnée sur un côté de la matrice de nœuds de calcul et chaque mémoire locale est reliée à un routeur d’un nœud de calcul. Procédé de traitement pour l’exécution d’un réseau de neurones comportant au moins N couches successives de réseau de neurones C_i, i = 1 à N, avec N>1, dans un accélérateur (1) de réseau de neurones ; l’accélérateur (1) de réseau de neurones comprenant : - un bloc de contrôle global (10), - une matrice (11) de nœuds de calcul (14), chaque nœud (14) comprenant un routeur (52) et un élément de traitement (50), dit encore PE associé à un ensemble de registres mémoires locaux respectifs (510, 511), l’élément de traitement (50), permettant d’effectuer des opérations de calcul parmi des multiplications et des accumulations de données stockées dans ses registres, le routeur (52) permettant de réaliser plusieurs routages de données indépendants en parallèle vers des sorties distinctes du routeur, les routeurs étant reliés les uns aux autres ; - au moins une rangée de mémoires tampons locales (13), chaque rangée de mémoire tampon locale étant positionnée sur un côté de la matrice (11) de nœuds de calcul, et chaque mémoire tampon locale est reliée à un routeur d’un nœud de calcul qui lui est associé ; les routeurs (52) étant adaptés pour router les données, à travers la matrice des nœuds de calcul en parallèle de l’exécution par les nœuds de calcul, en fonction d’un mot de contrôle associé à chaque donnée ; selon lequel au début de l’exécution par l’accélérateur (1) d’une couche C_i, des données d’entrée ifmap de la couche sont extraites de certaines au moins desdites mémoires tampons locales et sont fournies, avec leur mot de contrôle associé, aux routeurs des nœuds de calcul associés ; selon lequel au cours de l’exécution de la couche C_i par l’accélérateur, des données de sortie ofmap de la couche C _i issues de données délivrées par les routeurs de nœuds de calcul associés à des mémoires tampons locales sont stockées dans lesdites mémoires tampons locales ; ledit procédé étant caractérisé en ce que l’accélérateur (1) comporte en outre un bloc d’emballage (16) disposé entre certaines au moins des mémoires tampons locales et les nœuds associés audites mémoires tampons locales, et ledit bloc d’emballage (16) détermine le mot de contrôle associé aux données d’entrée ifmap de la couche C_i+1 en fonction d’un mot de configuration défini pour ladite couche C_i+1, lors de la mise en œuvre de l’une ou l’autre des dispositions suivantes i et j dans l’accélérateur : disposition i/ i1/ au cours de l’exécution de la couche C_i par l’accélérateur : - avant que lesdites données de sortie ofmap de la couche C _ i ne soient stockées dans lesdites mémoires tampons locales (13), ledit bloc d’emballage (16) détermine, en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour chacune des données d’entrée ifmap de la couche C_i+1 lesquelles correspondent aux données de sortie ofmap de la couche C_i ; - puis lesdites données de sortie ofmap sont insérées dans des paquets de données stockées dans lesdites mémoires tampons locales (13) avec les mots de contrôle associés ainsi déterminés pour la couche C_i+1 par le bloc d’emballage (16) ; i2/ au début de l’exécution de la couche C_i+1 par l’accélérateur (1), lesdites données d’entrée ifmap de la couche sont extraites des mémoires tampons locales (13) où elles étaient stockées depuis l’étape i1 et sont fournies, avec leur mot de contrôle associé pour la couche C_i+1, aux routeurs (52) des nœuds de calcul (14) auxquels lesdites mémoires tampons locales (13) sont associées ; disposition j/ j1/ au début de l’exécution de la couche C_i+1 par l’accélérateur, les données de sortie ofmap de la couche C _i ayant été stockées dans lesdites mémoires tampons locales (13) à la fin de l’exécution de la couche C_i, ledit bloc d’emballage (16) détermine en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour la couche C_i+1, qui sont associés aux données d’entrée ifmap de la couche C_i+1, lesquelles correspondent aux données de sortie ofmap ; j2/ puis lesdites données d’entrée ifmap de la couche extraites des mémoires tampons locales (13) où elles étaient stockées depuis la fin de l’exécution de la couche C_i sont insérées dans des paquets avec leur mot de contrôle associé déterminé pour la couche C_i+1, et sont ainsi fournies aux routeurs (52) des nœuds de calcul (14) auxquels lesdites mémoires tampons locales (13) sont associées. Procédé de traitement pour l’exécution d’un réseau de neurones selon la revendication 1, selon lequel la détermination du mot de contrôle pour une donnée pour la couche C_i+1 est effectuée en fonction au moins d’un champ du mot de configuration indiquant le type de couche C_i+1 et de la mémoire tampon locale (13) stockant la donnée ofmap correspondant à la donnée ifmap de la couche C_i+1. Procédé de traitement pour l’exécution d’un réseau de neurones selon la revendication 2, selon lequel la détermination du mot de contrôle pour une donnée pour la couche C_i+1 est effectuée en fonction au moins d’au moins un élément parmi la position de ladite mémoire tampon locale (13) et la position du nœud (14) associé à ladite mémoire tampon locale. Procédé de traitement selon l’une quelconque des revendications précédentes, selon lequel le mot de contrôle déterminé indique un type de communication parmi unicast, broadcast, multicast diagonal, multicast vertical, multicast horizontal et indique en outre un sens si le type de communication est multicast. Procédé de traitement selon l’une quelconque des revendications précédentes, selon lequel plusieurs desdites données associés à un même mot de contrôle et délivrées par un même nœud de calcul (14) sont insérées dans un paquet de données commun associé audit mot de contrôle déterminé par le bloc d’emballage (16). Accélérateur (1) de réseau de neurones adapté pour l’exécution d’un réseau de neurones comportant au moins N couches successives de réseau de neurones C_i, i = 1 à N, avec N>1, l’accélérateur (1) de réseau de neurones comprenant : - un bloc de contrôle global (10), - une matrice (11) de nœuds de calcul (14), chaque nœud (14) comprenant un routeur (52) et un élément de traitement (50), dit encore PE associé à un ensemble de registres mémoires locaux respectifs (510, 511), l’élément de traitement (50) étant adapté pour effectuer des opérations de calcul parmi des multiplications et des accumulations de données stockées dans ses registres, le routeur (52) étant adapté pour réaliser plusieurs routages de données indépendants en parallèle vers des sorties distinctes du routeur, les routeurs étant reliés les uns aux autres ; - au moins une rangée de mémoires tampons locales (13), chaque rangée de mémoire tampon locale étant positionnée sur un côté de la matrice (11) de nœuds de calcul, et chaque mémoire tampon locale est reliée à un routeur d’un nœud de calcul qui lui est associé ; les routeurs (52) étant adaptés pour router les données, à travers la matrice des nœuds de calcul en parallèle de l’exécution par les nœuds de calcul, en fonction d’un mot de contrôle associé à chaque donnée ; ledit accélérateur étant adapté pour que, au début de l’exécution par l’accélérateur (1) d’une couche C_i, des données d’entrée ifmap de la couche soient extraites de certaines au moins desdites mémoires tampons locales et soient fournies, avec leur mot de contrôle associé, aux routeurs des nœuds de calcul associées et pour que au cours de l’exécution de la couche C_i par l’accélérateur, des données de sortie ofmap de la couche C _i issues de données délivrées par les routeurs de nœuds de calcul associés à des mémoires tampons locales soient stockées dans lesdites mémoires tampons locales ; ledit accélérateur étant caractérisé en ce qu’il comporte en outre un bloc d’emballage (16) disposé entre certaines au moins des mémoires tampons locales et les nœuds associés audites mémoires tampons locales, et ledit bloc d’emballage (16) est adapté pour déterminer le mot de contrôle associé aux données d’entrée ifmap de la couche C_i+1 en fonction d’un mot de configuration défini pour ladite couche C_i+1, lors de la mise en œuvre de l’une ou l’autre des dispositions suivantes i et j dans l’accélérateur : disposition i/ i1/ au cours de l’exécution de la couche C_i par l’accélérateur : - avant que lesdites données de sortie ofmap de la couche C _ i ne soient stockées dans lesdites mémoires tampons locales (13), ledit bloc d’emballage (16) est adapté pour déterminer, en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour chacune des données d’entrée ifmap de la couche C_i+1 lesquelles correspondent aux données de sortie ofmap de la couche C_i ; - l’accélérateur étant adapté pour lesdites données de sortie ofmap soient ensuite insérées dans des paquets de données stockées dans lesdites mémoires tampons locales (13) avec les mots de contrôle associés ainsi déterminés pour la couche C_i+1 par le bloc d’emballage (16) ; i2/ au début de l’exécution de la couche C_i+1 par l’accélérateur (1), ledit accélérateur est adapté pour que lesdites données d’entrée ifmap de la couche soient extraites des mémoires tampons locales (13) où elles étaient stockées depuis l’étape i1 et soient fournies, avec leur mot de contrôle associé pour la couche C_i+1, aux routeurs (52) des nœuds de calcul (14) auxquels lesdites mémoires tampons locales (13) sont associées ; disposition j/ j1/ au début de l’exécution de la couche C_i+1 par l’accélérateur, les données de sortie ofmap de la couche C _i ayant été stockées dans lesdites mémoires tampons locales (13) à la fin de l’exécution de la couche C_i, ledit bloc d’emballage (16) est adapté pour déterminer en fonction du mot de configuration associé à la couche C_i+1, les mots de contrôle, pour la couche C_i+1, qui sont associés aux données d’entrée ifmap de la couche C_i+1, lesquelles correspondent aux données de sortie ofmap ; j2/ l’accélérateur est adapté pour que lesdites données d’entrée ifmap de la couche extraites des mémoires tampons locales (13) où elles étaient stockées depuis la fin de l’exécution de la couche C_i soient ensuite insérées dans des paquets avec leur mot de contrôle associé déterminé pour la couche C_i+1, et soient ainsi fournies aux routeurs (52) des nœuds de calcul (14) auxquels lesdites mémoires tampons locales (13) sont associées. Accélérateur (1) selon la revendication 6, dans lequel le bloc d’emballage (16) est adapté pour déterminer le mot de contrôle pour une donnée pour la couche C_i+1 en fonction au moins d’un champ du mot de configuration indiquant le type de couche C_i+1 et de la mémoire tampon locale (13) stockant la donnée ofmap correspondant à la donnée ifmap de la couche C_i+1. Accélérateur (1) selon la revendication 7, dans lequel la détermination du mot de contrôle pour une donnée pour la couche C_i+1 est effectuée par le bloc d’emballage (16) en fonction au moins d’au moins un élément parmi la position de ladite mémoire tampon locale (13) et la position du nœud (14) associé à ladite mémoire tampon locale. Accélérateur (1) selon l’une quelconque des revendications 6 à 8, dans lequel le mot de contrôle déterminé indique un type de communication parmi unicast, broadcast, multicast diagonal, multicast vertical, multicast horizontal et indique en outre un sens si le type de communication est multicast. Accélérateur (1) selon l’une quelconque des revendications 6 à 9, dans lequel plusieurs desdites données associés à un même mot de contrôle et délivrées par un même nœud de calcul (14) sont insérées dans un paquet de données commun associé audit mot de contrôle déterminé par le bloc d’emballage (16).