Brevet FR3007163A1 — publié le 20141219

SYSTEME DE TRADUCTION D'ADRESSES VIRTUELLES EN ADRESSES PHYSIQUES POUR DES CANAUX DE COMMUNICATION D'UN RESEAU Domaine technique de l'invention L'invention est relative à la traduction d'adresses virtuelles en adresses physiques, notamment dans le cadre de transferts effectués entre des canaux de communication d'un réseau-sur-puce et une mémoire système. État de la technique Les adresses virtuelles, dans un système processeur, servent à offrir aux processus un espace d'adressage continu et unifié pour accéder aux diverses ressources du système, alors que les adresses physiques effectivement utilisées, allouées de manière dynamique par le système d'exploitation, peuvent être fragmentées et correspondre à des ressources de natures différentes (registres, mémoire dynamique, mémoire non-volatile, disque dur). De tels systèmes intègrent généralement un module de gestion de mémoire, couramment appelé MMU (« Memory Management Unit »), qui est configuré par le système d'exploitation notamment pour mapper les adresses virtuelles sur les adresses physiques correspondantes. La figure 1 représente schématiquement des éléments d'un module MMU. Le module MMU comprend une table de traduction 10 recevant les adresses virtuelles Av et produisant des adresses physiques correspondantes Ap. Ces adresses physiques sont, par exemple, des adresses d'une mémoire système SMEM dans laquelle des données D présentées avec les adresses virtuelles sont à écrire. L'espace d'adressage virtuel est en général si grand qu'il n'est pas concevable en pratique que la table 10 stocke les correspondances de toutes les adresses virtuelles, même si les adresses virtuelles sont restreintes pour ne désigner que des pages mémoire. C'est pourquoi la table de traduction est en pratique maintenue par le système d'exploitation dans une mémoire externe TMEM, pouvant faire partie de la mémoire système SMEM. La table 10, au sein du module MMU, est alors une mémoire cache couramment 30 désignée « Translation Look-aside Buffer », ou TLB. Tant que les adresses virtuelles Av utilisées sont contenues dans la table TLB, cette table peut fournir les traductions en adresses physiques Ap immédiatement. Si une adresse virtuelle n'est pas présente dans la table TLB, la traduction est cherchée dans la mémoire TMEM et mise à jour dans la table TLB. La figure 2 est un chronogramme illustrant ce mécanisme. A des cycles successifs, des données DO, Dl, D2... arrivent avec des adresses virtuelles AvO, Avl, Av2... Les 5 adresses virtuelles AvO et Avl sont présentes dans la table TLB ; les adresses physiques correspondantes Ap0 et Apl sont fournies avec un cycle de décalage. Par contre, l'adresse virtuelle Av2 n'est pas présente dans la table TLB. Le flot de données est alors interrompu, en attendant que les nouvelles traductions soient chargées dans la table TLB à partir de la mémoire TMEM. Lorsque les nouvelles traductions ont été chargées, 10 l'adresse physique Ap2 est produite pour la donnée D2 mise en attente, et le flot de données peut reprendre. Résumé de l'invention Dans certaines circonstances, notamment pour des communications dans un réseau-surpuce, on souhaite ne pas interrompre un flot de données dans la phase de traduction 15 d'adresses virtuelles en adresses physiques. On tend à satisfaire ce besoin en prévoyant un procédé de transfert de données entre plusieurs canaux de communication utilisant des adresses virtuelles et une mémoire système utilisant des adresses physiques, comprenant les étapes suivantes pour une nouvelle communication : allouer à la communication une première fenêtre continue 20 dans une table de traduction d'adresses virtuelles en adresses physiques ; utiliser la première fenêtre pour transférer les données de la communication ; sans interrompre le transfert, dupliquer le contenu de la première fenêtre dans une deuxième fenêtre continue de la table ; utiliser la deuxième fenêtre pour continuer le transfert ; et libérer l'espace de la première fenêtre dans la table. 25 Selon un mode de mise en oeuvre, le procédé comprend les étapes suivantes : allouer la première fenêtre continue en identifiant son début dans un registre programmable associé au canal de la communication ; indexer la table de traduction en fonction de l'ordre d'arrivée des données de la communication et du contenu du registre ; et après la duplication du contenu de la première fenêtre dans la deuxième fenêtre, remplacer le 30 contenu du registre pour identifier le début de la deuxième fenêtre. Selon un mode de mise en oeuvre, le procédé comprend les étapes suivantes : organiser les données de la communication en paquets, où chaque paquet véhicule une information de position de paquet ; et indexer la table de traduction en fonction de l'ordre d'arrivée des données du paquet, de l'information de position de paquet, et du contenu du registre. Selon un mode de réalisation, la mémoire est organisée en pages et la table de traduction contient des adresses de page. Le procédé comprend alors les étapes 5 suivantes : incrémenter un compteur à chaque arrivée d'une donnée ; indexer la table à partir d'un groupe de bits de poids fort du compteur, ce groupe de bits ayant la même taille que le registre programmable ; joindre les bits de poids faible du compteur à droite des adresses de page fournies par la table pour produire des adresses physiques de la mémoire ; et à chaque début de paquet, initialiser le compteur avec la somme du 10 contenu du registre, décalé à gauche, et de l'information de position de paquet. Selon un mode de mise en oeuvre, la deuxième fenêtre continue est cherchée à partir du début de la table. Selon un mode de mise en oeuvre, la recherche de la deuxième fenêtre continue est initiée à la fin d'une communication concurrente. 15 Un noeud de réseau-sur-puce mettant en oeuvre ce procédé peut comprendre une pluralité de canaux de communication véhiculant des données ; une table de traduction d'adresses contenant des adresses physiques associées aux positions dans la table ; une mémoire accessible par les adresses physiques produites par la table ; un registre programmable associé à chaque canal et identifiant une position dans la table ; et un 20 circuit d'indexation associé à chaque canal, configuré pour indexer la table en fonction du contenu du registre associé au canal et l'ordre d'arrivée des données d'une communication en cours dans le canal. Selon un mode de réalisation, les données des communications sont organisées en paquets véhiculant chacun une information de position de paquet, le circuit d'indexation 25 étant configuré pour indexer la table de traduction en fonction de l'ordre d'arrivée des données du paquet, de l'information de position de paquet, et du contenu du registre. Description sommaire des dessins Des modes de réalisation seront exposés dans la description suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : 30 - la figure 1, précédemment décrite, représente schématiquement un module MMU ; - la figure 2, précédemment décrite, est un chronogramme illustrant une phase de traduction d'adresses pour un flot de données à l'aide d'une table TLB ; - la figure 3 représente schématiquement des éléments d'un noeud de réseau-surpuce intervenant dans la gestion des communications, notamment un mode de réalisation de circuit de traduction d'adresses ; - la figure 4 illustre un exemple de circuit de calcul d'adresse virtuelle utilisable dans le système de la figure 3 ; - les figures 5A à 5D représentent diverses étapes de fonctionnement du système de la figure 3 ; et - la figure 6 est un chronogramme illustrant une phase de traduction d'adresses pour un flot de données à l'aide du système de la figure 3. Description d'un mode de réalisation préféré de l'invention La figure 3 représente schématiquement des éléments d'un noeud de réseau-sur-puce intervenant dans la gestion des communications. Le noeud peut gérer plusieurs canaux de communication entrants RxO, Rxl ... et plusieurs canaux de communication sortants TxO... Chaque canal comprend généralement une queue FIFO dans laquelle des données attendent leur tour de traitement. Le noeud comprend une mémoire système SMEM locale, accessible par des adresses physiques Ap. Les opérations à effectuer dans le noeud sont gérées par un processeur ou microcontrôleur UC. Des éléments décrits en détail ultérieurement permettent de gérer des traductions d'adresses de manière optimisée. Le réseau-sur-puce comprend une multiplicité de noeuds du type de la figure 3 reliés par des canaux de communication configurés selon une topologie choisie. Les données peuvent être transférées dans un canal entre deux noeuds par salves correspondant aux contenus de tampons mémoire gérés par des circuits d'accès direct à la mémoire (DMA). On désigne ci-après par « communication » le transfert d'un tampon mémoire d'un noeud source vers un tampon mémoire d'un noeud cible. Une telle communication peut être subdivisée en paquets de données comportant des en-têtes indicatifs de paramètres des paquets. Les tampons mémoire sont généralement alloués de manière dynamique dans la mémoire système SMEM de chaque noeud, et utilisent de ce fait un espace d'adresses physiques fragmenté et pouvant changer d'une allocation à l'autre. L'utilisation d'adresses virtuelles au sein du noeud permet de mapper l'espace d'adresses physiques d'un tampon sur un espace virtuel continu utilisable par les processus producteurs ou consommateurs de données. Ainsi, dans le noeud source, on a besoin d'une traduction d'adresses notamment pour lire dans le tampon mémoire les données à envoyer. Dans le noeud cible, on a besoin d'une traduction d'adresses notamment pour écrire dans le tampon mémoire les données reçues. Dans un tel réseau-sur-puce, on souhaite ne pas interrompre une communication entrante en cours. En effet, si on interrompt la réception, les données non encore reçues de la communication restent bloquées dans le réseau et favorisent la congestion du réseau. En outre, le fait de contraindre le système à ne pas interrompre une communication entrante rend le comportement du système plus déterministe, notamment quant à la latence de traversée du réseau, ce qui rend le système plus facile à optimiser. Ainsi, dans ce contexte, l'utilisation d'une table de type TLB pour traduire les adresses 15 est peu adaptée, car elle peut entraîner une interruption de communication lorsqu'un rafraîchissement de la table est nécessaire. Dans un noeud de réseau-sur-puce, la mémoire système est généralement petite par rapport à l'espace physique adressable d'un système processeur générique. Par exemple, la mémoire SMEM peut avoir une taille de l'ordre de 1 mégaoctet (220 octets). Si on 20 considère qu'on accède à cette mémoire par pages de 4 kilooctets (212 octets), une table de traduction d'adresses virtuelles en adresses physiques ne contient plus que 256 entrées. Les octets de chaque page sont identifiés par des bits de poids faible dits « offset » (12 dans l'exemple), partagés entre les adresses virtuelles et physiques, sans passer par une traduction. 25 Il est envisageable en pratique d'intégrer une telle table dans un module MMU du noeud réseau. Ainsi, le noeud de la figure 3 comprend une table de traduction TAB, sous la forme, par exemple, d'un plan mémoire embarqué de type SRAM. La table TAB est indexée par une plage continue d'adresses virtuelles Av. En pratique, comme cela est illustré pour la première adresse virtuelle AvO, les bits de poids fort de chaque adresse 30 virtuelle constituent un index (idx) identifiant une cellule de la table. La cellule identifiée contient une adresse physique de page mémoire (Pgl). Cette adresse physique de page est complétée à droite par les bits de poids faible, l'offset, de l'adresse virtuelle pour identifier l'emplacement mémoire dans la page. Le noeud peut être conçu pour affecter les adresses virtuelles aux données d'une communication en cours de manière incrémentale, dans l'ordre d'arrivée des données. En définissant l'adresse virtuelle de départ des incréments (F0), on définit une fenêtre continue dans la table, allouée à la communication. On peut pour cela associer à chaque canal un registre programmable REG dont le contenu (FO pour le canal RxO, F 1 pour le canal Rxl ...) identifie le début de la fenêtre continue allouée à la communication en cours dans le canal. L'adresse virtuelle est alors la somme du contenu du registre REG et du rang de la donnée reçue dans la communication (en considérant que les rangs partent de 0). Cette adresse virtuelle est calculée pour chaque canal par un circuit VAC respectif. Dans certains cas, on souhaite effectuer un tri des données d'une communication, par exemple, lorsqu'une image capturée par lignes dans un noeud source doit être traitée par macroblocs dans le noeud cible. Le tri peut être fait « à la source », c'est-à-dire que le processus émetteur ordonne les pixels de l'image par macroblocs dans la communication sortante. Cela peut être effectué en parcourant la fenêtre associée à la communication sortante dans le « désordre », pour lire les données par macroblocs dans la mémoire système. Les données arrivent alors au noeud cible dans le bon ordre, de sorte que l'indexation de la table de traduction du noeud cible peut continuer à être faite dans l'ordre d'arrivée des données. Il peut être souhaitable d'effectuer le tri « à la destination », car cela demande moins de ressources. Dans ce cas, le processus émetteur envoie les pixels dans l'ordre initial, ligne par ligne, mais crée un paquet à chaque frontière de macrobloc, c'est-à-dire tous les quatre pixels pour des macroblocs de 4x4 pixels. Dans l'en-tête de chaque paquet, le processus insère une information de position de paquet PP, à savoir une valeur à ajouter à l'adresse virtuelle initiale de la communication, du côté du noeud cible, pour trouver l'adresse virtuelle de la première donnée du paquet. Dans l'exemple d'une transmission d'une image par lignes et d'un traitement à la destination par macroblocs de 4x4 pixels, les positions insérées dans les premiers paquets sont 0, 16, 32, 48... Les circuits de calcul d'adresse virtuelle VAC sont conçus pour tenir compte des 30 positions de paquet PP. L'adresse calculée (AvO) est alors égale à la somme du contenu (F0) du registre, de la position de paquet PP, et du rang de la donnée dans le paquet. La figure 4 représente schématiquement un exemple de circuit de calcul d'adresse virtuelle VAC. L'adresse virtuelle Av est fournie par un compteur CNT cadencé par une horloge RxCK au rythme de succession des données dans le canal correspondant. Au début de chaque paquet de la communication, identifié par un signal PKT fourni au compteur, le compteur est initialisé avec la somme du contenu du registre REG et de la position PP fournie dans l'en-tête du paquet. Les bits de poids fort du compteur constituent l'index de la table TAB, et les bits de poids faible constituent l'offset de l'adresse physique Ap. Cet offset est adjoint à droite de l'adresse de page Pg fournie par la table pour former l'adresse physique complète Ap. Le contenu du registre REG, correspondant finalement à une adresse virtuelle de page, est complété à droite par des bits d'offset nuls pour former une adresse virtuelle complète. A l'établissement d'une communication dans un noeud réseau, le système d'exploitation alloue à la communication un tampon dans la mémoire SMEM et une fenêtre continue correspondante dans la table TAB. Le système d'exploitation remplit la fenêtre avec les adresses physiques des pages du tampon. La taille du tampon à allouer est obtenue, par exemple, lors d'une négociation préalable entre les noeuds source et cible. La fenêtre est allouée à la communication en inscrivant son index de départ dans le registre REG du canal utilisé par la communication. Les communications pouvant s'établir de façon aléatoire, et utilisant des tailles de fenêtre variables, on comprend que la table peut vite devenir fragmentée, c'est-à-dire comporter des espaces vides de taille insuffisante pour contenir une nouvelle fenêtre. On arrive alors à une situation où des nouvelles communications doivent être mises en attente, alors que la mémoire système dispose de suffisamment de place pour allouer les tampons aux communications. Ce problème n'est que retardé en augmentant la taille de la table. Les figures 5A à 5D illustrent différentes étapes d'un procédé de défragmentation de la 25 table TAB, mise en oeuvre par le système d'exploitation du noeud réseau. Grâce à ce procédé on pourra établir une communication dans un noeud tant que la mémoire système dispose de suffisamment de place pour contenir le tampon correspondant. A la figure 5A, une communication est en cours dans un canal entrant Rxi. Une fenêtre lui a été allouée dans la table TAB, débutant à l'index Fi contenu dans le registre REG 30 du canal. Pendant que la communication est en cours, le système d'exploitation cherche dans la table un espace libre continu pouvant également contenir la fenêtre Fi. Un espace libre est trouvé à l'index Fz. Cette recherche peut être effectuée de la même manière que pour la fenêtre originale, par exemple, à partir du début de la table. Il n'est pas utile qu'une telle recherche démarre immédiatement après le début de la communication - il vaut mieux attendre la libération d'une fenêtre allouée à une communication concurrente pour augmenter les chances de trouver un espace libre. Ainsi, la recherche démarre de préférence après la première communication concurrente qui se termine. A la figure 5B, sans interrompre la communication, démarre une duplication (DUP) du contenu de la fenêtre Fi vers l'emplacement identifié par l'index Fz. La duplication peut s'effectuer à la vitesse de l'horloge interne du noeud réseau, ayant généralement une fréquence plus élevée que l'horloge cadençant le canal de communication. Comme chaque cellule de la table correspond à une page mémoire, donc à un nombre de données relativement important (par exemple 4 kilooctets) la duplication de la fenêtre se termine en règle générale bien avant la fin de la communication. On remarque que la table TAB peut être soumise à des accès concurrents à la vitesse de l'horloge interne, à savoir la lecture de la fenêtre à copier ou l'écriture de la copie, et le remplissage d'une fenêtre pour une nouvelle communication. Pour éviter que les processus prennent du retard, la table TAB est de préférence une mémoire à double accès en écriture et à un accès indépendant en lecture. En outre, on peut établir un ordre de priorité d'accès à la table. Par exemple, pour garantir la non-interruption d'une communication entrante, les lectures de la table pour les données entrantes ont priorité sur les lectures pour les données sortantes. Les lectures et écritures pour dupliquer les fenêtres et mettre à jour les fenêtres ont la priorité la plus basse. A la figure 5C, la duplication de la fenêtre est terminée. L'index Fz de la nouvelle fenêtre est écrit dans le registre REG du canal Rxi, remplaçant la valeur Fi. Cette 25 écriture a lieu sans interrompre la communication, avant que le contenu du registre ne soit pris en compte pour la lecture suivante de la table. A la figure 5D, la lecture suivante de la table a lieu pour la communication en cours. Cette nouvelle lecture est basée sur le nouvel index Fz contenu dans le registre, qui pointe vers la copie de la fenêtre. A partir de là, les adresses de page Pg qui restaient à 30 lire dans la fenêtre originale sont lues dans la copie de la fenêtre. L'espace réservé à la fenêtre originale Fi est libéré dans la table et rendu disponible pour une nouvelle communication. La figure 6 illustre les étapes des figures 5A à 5D sous forme d'un chronogramme. La ligne D représente une séquence de données DO, Dl, D2... d'une communication courante, arrivant au rythme de l'horloge cadençant le canal de communication. La ligne DUP représente l'activité de duplication de fenêtre. Cette activité a lieu, dans 5 cet exemple, pendant la réceptions des données Dl et D2. La ligne REG illustre le contenu du registre du canal. Le registre contient la valeur Fi au début de la communication et bascule sur la valeur Fz à la fin de l'activité de duplication. Le basculement du contenu du registre a lieu de préférence avec suffisamment de marge avant la prise en compte du contenu du registre pour une 10 nouvelle lecture de la table. Comme cela est représenté, l'écriture du nouvel index dans le registre peut être synchronisé sur une transition des données. La ligne idx reflète les valeurs de l'index produits par le circuit de calcul d'adresse virtuelle VAC, et la ligne Pg indique les adresses de page produites par la table. Bien entendu, pour pouvoir ainsi dupliquer le contenu d'une fenêtre au sein même de la 15 table sans dégrader les performances, il est préférable d'agrandir la table. En règle générale, les tampons mémoire ne sont pas alignés sur les pages, de sorte que chaque tampon peut, au pire, occuper une page de plus par rapport au nombre théorique, à savoir une page incomplète contenant les premières données du tampon, ou une page incomplète contenant les dernières données du tampon. Dans ce cas, en doublant la 20 taille de la table par rapport à la taille minimale théorique, on est sûr de toujours avoir un espace libre continu pour dupliquer une fenêtre. Malgré cela, la taille de la table reste compatible avec une intégration au sein des circuits du noeud réseau. Si les tampons mémoire alloués aux communications sont alignés sur les pages, la taille de la table pourra être comprise entre 100 % et 200 % de la taille minimale théorique, 25 selon la méthode de duplication utilisée et la vitesse de duplication. REVENDICATIONS1. Procédé de transfert de données entre plusieurs canaux de communication (Rx, Tx) utilisant des adresses virtuelles (Av) et une mémoire système (SMEM) utilisant des adresses physiques (Ap), comprenant les étapes suivantes pour une nouvelle communication (Rxi) : - allouer à la communication une première fenêtre continue (Fi) dans une table de traduction (TAB) d'adresses virtuelles en adresses physiques ; - utiliser la première fenêtre (Fi) pour transférer les données de la communication ; - sans interrompre le transfert, dupliquer le contenu de la première fenêtre dans une deuxième fenêtre continue de la table ; - utiliser la deuxième fenêtre (Fz) pour continuer le transfert ; et - libérer l'espace de la première fenêtre (Fi) dans la table. 2. Procédé selon la revendication 1, comprenant les étapes suivantes : - allouer la première fenêtre continue en identifiant son début (F0) dans un registre programmable (REG) associé au canal de la communication ; - indexer (VAC) la table de traduction en fonction de l'ordre d'arrivée des données de la communication et du contenu du registre ; et - après la duplication du contenu de la première fenêtre dans la deuxième fenêtre, remplacer le contenu du registre pour identifier le début (Fz) de la deuxième fenêtre. 3. Procédé selon la revendication 2, comprenant les étapes suivantes : - organiser les données de la communication en paquets, où chaque paquet véhicule une information de position de paquet (PP) ; et - indexer la table de traduction en fonction de l'ordre d'arrivée des données du paquet, de l'information de position de paquet, et du contenu du registre. 4. Procédé selon la revendication 3, dans lequel la mémoire est organisée en pages et la table de traduction contient des adresses de page (Pg), le procédé comprenant les étapes suivantes : - incrémenter un compteur (CNT) à chaque arrivée d'une donnée ; - indexer la table à partir d'un groupe de bits (idx) de poids fort du compteur, ce groupe de bits ayant la même taille que le registre programmable (REG) ; - joindre les bits de poids faible du compteur (offs.) à droite des adresses de page (Pg) fournies par la table pour produire des adresses physiques de la mémoire ; et - à chaque début de paquet, initialiser le compteur avec la somme du contenu du registre, décalé à gauche, et de l'information de position de paquet (PP). 5. Procédé selon la revendication 1, dans lequel la deuxième fenêtre continue est cherchée à partir du début de la table. 6. Procédé selon la revendication 5, dans lequel la recherche de la deuxième fenêtre continue est initiée à la fin d'une communication concurrente. 7. Noeud de réseau-sur-puce, comprenant : - une pluralité de canaux de communication (Rx, Tx) véhiculant des données ; - une table de traduction d'adresses (TAB) contenant des adresses physiques (Ap) associées aux positions dans la table ; - une mémoire (SMEM) accessible par les adresses physiques (Ap) produites par la table ; - un registre programmable (REG) associé à chaque canal et identifiant une position (F0) dans la table ; et - un circuit d'indexation (VAC) associé à chaque canal, configuré pour indexer la table en fonction du contenu (F0) du registre associé au canal et l'ordre d'arrivée des données d'une communication en cours dans le canal. 8. Noeud de réseau-sur-puce selon la revendication 7, dans lequel les données des communications sont organisées en paquets véhiculant chacun une information deposition de paquet (PP), le circuit d'indexation (VAC) étant configuré pour indexer la table de traduction en fonction de l'ordre d'arrivée des données du paquet, de l'information de position de paquet, et du contenu du registre.