FR3010201A1 - Calculateur comprenant un processeur multicoeur et procede de controle d'un tel calculateur - Google Patents

Abstract

Ce calculateur comprend un processeur (8) multicoeur possédant plusieurs cœurs (10) physiquement distincts et des ressources communes (12). Chaque cœur (10) possède une mémoire cache privée (16) et exécute un superviseur (18) logiciel dédié à ce cœur (10), le superviseur (18) étant exécuté par le cœur (10) localement depuis sa mémoire cache privée (16), le superviseur (18) de chaque cœur (10) étant configuré pour intercepter chaque requête émise par la ou chaque application et dont le résultat n'est pas disponible dans la mémoire cache privée (16), et pour émettre au moins une transaction pour répondre à chaque requête interceptée, chaque transaction étant émise dans une fenêtre temporelle associée à cette transaction selon une partition temporelle comprenant des fenêtres temporelles disjointes, chaque fenêtre temporelle étant associée à au moins une transaction, au moins une fenêtre temporelle étant associée à chaque transaction.

Description

Calculateur comprenant un processeur multicoeur et procédé de contrôle d'un tel calculateur La présente invention concerne le domaine des calculateurs à processeurs multicoeur, comprenant plusieurs coeurs physiquement distincts et partageant des ressources communes. Chaque coeur d'un processeur multicoeur est une unité de calcul physiquement distincte des autres coeurs. La présence de plusieurs coeurs permet l'exécution en parallèle de plusieurs applications logicielles, pour plus de meilleures performances globales.

Pour l'exécution des applications, les coeurs utilisent des ressources communes. Ces ressources sont par exemple des mémoires, notamment une mémoire principale, ou des interfaces entrée/sortie (ou interface I/O) du calculateur (Bus rapide PCIe ou Réseau Ethernet par exemple). Les coeurs sont en concurrence pour l'utilisation de ces ressources communes.

L'orientation technologique ainsi que l'évolution des besoins des systèmes embarqués rendent inévitable l'introduction des processeurs multicoeurs dans les systèmes avioniques embarqués dans les aéronefs, pour bénéficier notamment de l'apport de performance, de la rapidité de calcul de ces processeurs, de la compacité et de la réduction de la puissance consommée.

Les systèmes avioniques des aéronefs modernes sont conçus de façon modulaire, selon le concept dit IMA (acronyme de « Integrated Moduler Avionics » en anglais). Un système avionique selon le concept IMA est décomposé en un ensemble de modules matériels et/ou logiciels, à chaque module est associé un processus de certification modulaire permettant d'assurer les exigences de sûreté du fonctionnement. Ceci permet de remplacer un module devenant obsolète par un nouveau module. Ce nouveau module faisant l'objet d'une certification unitaire ne nécessitant pas de devoir certifier dans son ensemble le système avionique incluant le nouveau module à la place de l'ancien. L'introduction d'un calculateur à processeur multicoeur dans un système avionique ne doit pas entraîner de régression dans la sûreté du fonctionnement du système avionique. En particulier, il est nécessaire de pouvoir assurer un partitionnement robuste dans l'exécution des applications logicielles implémentée sur ce calculateur. Selon le principe du partitionnement robuste, une erreur dans l'exécution d'une application ne doit pas se propager à d'autres applications. Cette propriété d'isolation des fautes, exigée par le standard DO-297, permet de séparer les analyses de défaillances effectuées sur les applications, et est assurée par des mécanismes de partitionnement spatial et temporel sur les calculateurs monocoeurs des systèmes avioniques actuels, conformément à la recommandation ARINC 653. En outre, il est nécessaire de déterminer des pires temps d'exécution ou WCET (acronyme de « Worst Case Execution Time » en anglais) pour chaque application implémentée sur ce calculateur. Une méthode d'évaluation du pire temps d'exécution doit être associée à un nouveau calculateur introduit dans un système avionique. La méthode d'évaluation du pire temps d'exécution doit être sûre et modulaire, c'est-à-dire qu'elle permette de déterminer une sur-approximation du pire temps d'exécution réel d'une application, et qu'elle permette de déterminer un pire temps d'exécution pour une application sans connaître les applications concurrentes qui seront exécutées en parallèle par le calculateur ou par un autre calculateur du système avionique. Par ailleurs, pour des raisons de coûts, il est souhaitable d'utiliser des processeurs multicoeurs génériques ou COTS (acronyme de « Commercial Off The Shelf » en anglais) qui ne sont pas spécifiquement conçus pour une application particulière ni pour une intégration dans un système avionique. En outre, pour des raisons de confidentialité, la conception et le fonctionnement interne des processeurs multicoeurs génériques ne sont pas entièrement divulgués par les fondeurs, et ne sont donc pas connus par l'intégrateur en charge de la conception des calculateurs des systèmes avioniques.

Il est donc difficile d'assurer de manière fiable et démontrable le partitionnement robuste et la détermination des pires temps d'exécution pour des calculateurs à processeurs multicoeurs, ce qui est pourtant nécessaire pour une utilisation dans un système avionique. Un des buts de l'invention est de proposer un calculateur à processeur multicoeur permettant d'assurer un partitionnement robuste et un calcul fiables des pires temps d'exécution. A cet effet, l'invention propose un calculateur comprenant un processeur multicoeur possédant plusieurs coeurs physiquement distincts et des ressources communes partagées par les coeurs, - dans lequel chaque coeur exécute au moins une application, et chaque coeur est propre à émettre des transactions vers les ressources communes, parmi un ensemble de transactions possibles entre les coeurs et les ressources communes ; - dans lequel chaque coeur possède une mémoire cache privée et exécute un superviseur logiciel dédié à ce coeur, le superviseur étant exécuté par le coeur localement depuis sa mémoire cache privée, le superviseur de chaque coeur étant configuré pour intercepter chaque requête émise par la ou chaque application et dont le résultat n'est pas disponible dans la mémoire cache privée, et pour émettre au moins une transaction pour répondre à chaque requête interceptée, chaque transaction étant émise dans une fenêtre temporelle associée à cette transaction selon une partition temporelle comprenant des fenêtres temporelles disjointes, chaque fenêtre temporelle étant associée à au moins une transaction, au moins une fenêtre temporelle étant associée à chaque transaction. Selon des modes de réalisation particuliers, le calculateur comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles : - au moins une fenêtre temporelle est à associée à plusieurs transactions ; - au moins une fenêtre temporelle est associées à plusieurs transactions incluant des transactions émises par des coeurs différents ; - chaque coeur comprend au moins une table d'accès aux ressources stockée dans sa mémoire cache privée et indiquant la ou chaque fenêtre temporelle dans laquelle l'émission de la ou chaque transaction est autorisée ; - la table d'accès aux ressources de chaque coeur est consultable et modifiable uniquement par le superviseur de ce coeur ; - chaque coeur comprend une unité de gestion de mémoire configurée pour lever une interruption à la réception d'une requête dont le résultat n'est pas disponible dans la mémoire cache privée, le superviseur étant configuré pour détecter chaque interruption générée par l'unité de gestion de mémoire ; - le superviseur de chaque coeur est configuré pour intercepter chaque requête de configuration de l'unité de gestion de mémoire émises par une application logicielle exécutée sur le coeur, et gérer une table d'adressage virtuelle en fonction des instructions de configuration de l'unité de gestion de mémoire ; - le superviseur est configuré pour lire la table d'adressage virtuelle en fonction de chaque requête interceptée, et déterminer une transaction correspondante pour répondre à cette requête ; - le superviseur est configuré pour associer à une requête interceptée la transaction correspondante et au moins une transaction spéculative destinée à être émises dans la même fenêtre temporelle que la transaction correspondant à la requête interceptée ; - le superviseur de chaque coeur comprend un module d'analyse propre à déterminer une transaction correspondant à chaque requête interceptée et des transactions spéculatives, et à demander l'émission de la transaction correspondante et des transactions spéculatives entre une mémoire apparentant aux ressources communes et la mémoire cache privée du coeur ; - le superviseur de chaque coeur comprend un module de gestion du cache propre à allouer un espace de la mémoire cache privée au stockage du résultat d'une ou plusieurs transactions, à modifier la configuration de l'unité de gestion de mémoire pour ne pas intercepter les requêtes dont le résultat est stocké dans la mémoire cache privée, à modifier la configuration de l'unité de gestion de la mémoire pour intercepter les requêtes dont le résultat n'est plus stocké dans la mémoire cache privée ; - le module de gestion du cache est configuré pour gérer au moins une liste des espaces de la mémoire cache privée dont le contenu est remplaçable ou effaçable et qui sont susceptible d'être allouer au stockage de nouveaux résultats ; - le superviseur comprend un module de synchronisation propre à déterminer la fenêtre temporelle active ; - le processeur comprend une horloge mettant à jour un registre temporel respectif dédié à chaque coeur, le processeur étant configuré pour la mise à jour des registres temporels de manière synchrone ; - le processeur comprend une horloge mettant à jour un registre temporel commun aux coeurs, chaque coeur possédant un chemin physique respectif dédié d'accès au registre temporel commun ; L'invention concerne également un procédé de contrôle d'un processeur multicoeur possédant plusieurs coeurs physiquement distincts et des ressources communes partagées par les coeur, chaque coeur comprenant une mémoire cache privée et étant propre à émettre des transactions vers les ressources communes, parmi un ensemble de transactions réalisables entre les coeurs et les ressources communes, en réponse à des requêtes d'applications exécutées par ce coeur, chaque coeur possédant une mémoire cache privée, le procédé comprenant les étapes suivantes mises en oeuvre par chaque coeur : - interception de chaque requête dont le résultat n'est pas disponible dans la mémoire cache privée par un superviseur logiciel dédié à ce coeur et exécuté par ce coeur localement depuis sa mémoire cache privée, et - émission par le superviseur d'une ou plusieurs transactions associées à la requête interceptée, en émettant la ou chaque transaction dans une fenêtre temporelle associée à chaque transaction émise, selon une partition temporelle comprenant des fenêtres temporelles disjointes, chaque fenêtre temporelle étant associée à au moins une transaction, au moins une fenêtre temporelle étant associée à chaque transaction. Selon des modes de mise en oeuvre particuliers, le procédé comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles : - la configuration par le superviseur de chaque coeur d'une unité de gestion de mémoire de manière à ce que l'unité de gestion de mémoire lève une interruption à la réception d'une requête dont le résultat n'est pas disponible dans la mémoire cache privée ; - l'interception par le superviseur des instructions de configuration de l'unité de gestion de la mémoire émises par une application exécutée par le coeur, et la gestion par le superviseur d'une table d'adressage virtuelle en fonction des instructions de configuration interceptées ; - l'association à chaque requête interceptée, d'une transaction correspondante répondant la requête et d'au moins une transactions spéculatives, destinées à être émise dans la même fenêtre temporelle que la transaction correspondante. L'invention et ses avantages seront mieux compris à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en référence aux dessins annexés, sur lesquels : - la figure 1 est une vue schématique d'un calculateur d'un système avionique embarqué, le calculateur comprenant un processeur multicoeur possédant plusieurs coeurs partageant des ressources communes ; - la figure 2 est une vue schématique d'une partition temporelle pour l'utilisation des ressources communes par les coeurs ; et - les figures 3 et 4 sont des vues schématiques d'un coeur illustrant différents modes de fonctionnement du coeur ; - les figures 5 et 6 sont des vues schématiques de mécanismes matériels permettant une exécution cohérente de l'ensemble des coeurs. Sur le Figure 1, un système avionique 2 embarqué dans un aéronef 4 possède un calculateur 6 ayant un processeur 8 multicoeur ayant plusieurs coeurs 10, des ressources communes 12 partagées par les coeurs 10, et une interconnexion 14 par l'intermédiaire de laquelle les coeurs 10 accèdent aux ressources communes 12. Les coeurs 10 sont physiquement distincts. Chaque coeur 10 est une unité de calcul individuelle comprenant ses propres composants électroniques, distincts de ceux des autres coeurs 10. Les ressources communes 12 sont des ressources matérielles partagées par les coeurs 10. Les ressources communes 12 sont par exemple des mémoires, telles qu'une mémoire principale, une mémoire cache partagée (par exemple une mémoire de niveau 2 dite Cache L2 ou de niveau 3 dite Cache L3), ou des interfaces entrée/sortie (ou interface I/O). Une interface entrée/sortie permet d'émettre ou de recevoir des signaux sur un bus de communication (non représenté), par exemple un bus de communication du système avionique pour une communication entre plusieurs calculateurs ou entre les calculateurs et des sondes de mesure ou des actuateurs. L'interconnexion 14 est par exemple un bus d'interconnexion. De préférence, tous les coeurs 10 du processeur 8 sont reliés aux ressources communes 12 par l'intermédiaire du même et unique moyen formé par l'interconnexion 14. Chaque coeur 10 est apte à exécuter une ou plusieurs applications AP logicielles. Chaque coeur 10 exécute la ou chaque application sous le contrôle d'un système d'exploitation informatique ou OS (pour « Operating System » en anglais). Un système d'exploitation OS est une application logicielle particulière, exécutée par le coeur 10 et qui contrôle l'utilisation des ressources logicielles ou matérielles accessible à ce coeur 10 (y compris les ressources communes) par les applications AP. Chaque coeur 10 possède son propre système d'exploitation individuel. Dans la suite, en l'absence de précision, le terme « application » désigne une application utilisateur ou un système d'exploitation exécuté par un coeur.

Lors de son exécution, une application émet des requêtes qui sont traitées par le coeur 10. Une requête correspond généralement à une demande de lecture ou d'écriture à une adresse déterminée de l'espace mémoire adressable. Dans la suite, en l'absence de précision, le terme « requête » désigne une demande d'accès à l'espace mémoire adressable faite par une application au coeur 10 qui exécute cette application.

Pour répondre à une requête d'une application, le coeur 10 fait appel notamment aux ressources communes 12. Dans la suite, une « transaction » désigne un échange de données entre un coeur 10 déterminé et une ressource commune 12 déterminée. L'expression « émission d'une transaction » entre un coeur 10 et une ressource commune 12 englobe l'envoi par ce coeur 10 d'une demande du coeur 10 vers la ressource commune 12 et la réception par le coeur 10 de l'éventuelle réponse de la ressource commune 12. Il existe pour le calculateur un ensemble de transactions E réalisables entre les coeurs 10 et les ressources communes 12 partagées par ces coeurs 10. L'ensemble de transactions E comprend un nombre entier fini de transaction, chacune associée à un couple coeur / ressource commune respectif. Lors de l'exécution des applications par les coeurs 10, les coeurs 10 sont en concurrence pour l'utilisation des ressources communes 12. Or, chaque transaction entre un coeur 10 déterminé et une ressource commune 12 déterminée doit être effectuée avec un coût temporel borné.

Le partage de ressources communes 12 par plusieurs coeurs 10 nécessite donc de définir une politique de partage de ressources communes 12, c'est-à-dire un ensemble de règles restreignant l'activité concurrente des différents coeurs 10 dans les ressources communes 12. Le calculateur 6 est configuré pour mettre en oeuvre une politique de partage des ressources communes 12 basée sur une partition temporelle comprenant une séquence périodique de fenêtres temporelles Fl, F2, FN. Chaque fenêtre temporelle est associée à une ou plusieurs transactions de l'ensemble de transaction E, qui sont exécutables simultanément avec un coût temporel borné.. Il est possible qu'une fenêtre temporelle ne soit associée qu'à une seule transaction.

Chaque transaction de l'ensemble des transactions E réalisables entre les coeurs 10 et les ressources communes 12 partagées par ces coeurs 10, est associée à au moins une fenêtre temporelle. Ainsi, les fenêtres temporelles couvrent l'intégralité des transactions possibles entre les coeurs 10 et les ressources communes 12 qu'ils partagent.

Chaque transaction est associée à une ou plusieurs fenêtres temporelles. Une transaction associée à plusieurs fenêtres temporelles est réalisable dans chacune de ces fenêtres temporelles. Pour déterminer une partition temporelle, on sélectionne plusieurs sous-ensembles de transactions E1, E2...EN, chaque sous-ensemble de transactions contenant des transactions exécutables simultanément avec un coût temporel borné. Les sous-ensembles sont choisis de manière que leur union couvre l'intégralité de l'ensemble des transactions E réalisables entre les coeurs 10 et les ressources communes 12. Ensuite on découpe une période temporelle en fenêtres temporelles F1, F2, FN disjointes, et on alloue chaque fenêtre temporelle à un sous-ensemble de transactions El, E2 ...EN respectif. De préférence, chaque fenêtre temporelle possède une durée suffisante pour permettre l'exécution de l'intégralité des transactions associées à cette fenêtre temporelle. Lorsqu'une application émet une requête qui implique pour le coeur l'émission d'une transaction, le coeur attend qu'une fenêtre temporelle associée à cette transaction soit active pour émettre cette transaction. La transaction est donc émise seulement dans une fenêtre temporelle allouée à un sous-ensemble de transactions contenant cette transaction. Le pire temps d'exécution d'une transaction se décompose donc en deux termes bornés temporellement : un terme correspondant à la latence d'activation d'une fenêtre temporelle associée à cette transaction, et un terme correspondant au coût temporel d'exécution de ladite transaction dans cette fenêtre temporelle. Le coût d'exécution de la transaction est donc bien borné. Les fenêtres temporelles sont disjointes et espacées temporellement. Chaque fenêtre temporelle est séparée de la fenêtre temporelle suivante par un intervalle de temporisation, pendant lequel aucun coeur ne peut initier une transaction. Chaque intervalle de temporisation possède une durée supérieure à la durée d'exécution de chacune des transactions de la fenêtre temporelle qui précède l'intervalle de temporisation. Ceci permet de s'assurer que chaque transaction initiée dans la fenêtre temporelle sera terminée avant le début de la fenêtre temporelle suivante.

La Figure 2 est un graphique illustrant l'émission des transactions par un premier coeur et un deuxième coeur vers une interface I/O et une mémoire principale MEM en fonction du temps. Une première ligne de temps illustre l'activité des coeurs sur la mémoire principale MEM et une deuxième ligne de temps illustre l'activité des coeurs sur l'interface I/O. L'activité du premier coeur est illustrée par des barres noires, et l'activité du deuxième coeur est illustrée par des barres hachurées. Le graphique illustre une première fenêtre temporelle F1 et une deuxième fenêtre temporelle F2 séparées par un intervalle I. La première fenêtre temporelle F1 est associée à la transaction entre le premier coeur et la mémoire principale MEM et à la transaction entre le coeur et une interface I/O.

La deuxième fenêtre temporelle F2 est associée à la transaction entre le deuxième coeur et la mémoire principale MEM, et à la transaction entre le deuxième coeur et l'interface I/O. Lorsque la première fenêtre temporelle F1 est active, le premier coeur réalise successivement deux transactions avec la mémoire principale MEM à des instants T1 et T2 puis une transaction avec l'interface I/O à un instant T3. La transaction avec l'interface I/O est initiée dans la première fenêtre F1 et se termine dans l'intervalle de temporisation entre la première fenêtre F1 et la deuxième fenêtre F2. Lorsque la première fenêtre temporelle F1 est active, le deuxième coeur souhaite émettre une transaction avec la mémoire principale MEM à un instant T4, mais cette transaction n'est pas associée à la première fenêtre temporelle F1. Le deuxième coeur n'émet pas la transaction dans la première fenêtre temporelle F1 ni dans l'intervalle de temporisation I, et attend pour émettre cette transaction que la deuxième fenêtre temporelle F2 soit active, comme illustré par la ligne pointillés W. Dans la deuxième fenêtre temporelle F2, le deuxième coeur émet deux transactions vers la mémoire principale MEM à des instants T5 et T6. L'instant T5 correspond au début de la deuxième fenêtre temporelle F2. Ensuite, le deuxième coeur souhaite initier une transaction vers l'interface I/O à un instant T7, mais cette transaction arrive pendant l'intervalle de temporisation I suivant la deuxième fenêtre temporelle F2. Elle ne peut être initiée et le deuxième coeur doit donc attendre la prochaine activation de la deuxième fenêtre temporelle F2 pour initier cette transaction.

Dans l'exemple de la Figure 2, pour des raisons de simplification, chaque fenêtre est associée à des transactions associées à un coeur respectif. En pratique, il est possible qu'une même fenêtre soit associée à des transactions associées à des coeurs différents, ces transactions pouvant être exécutées sans interférence entre les coeurs. Ceci dépend de l'interconnexion. Par exemple une transaction entre un premier coeur et une première interface I/O est généralement exécutable simultanément à une transaction entre un deuxième coeur et une deuxième interface I/O distincte de la première interface I/O. Le calculateur 6 est configure pour la mise en oeuvre de cette politique de partage des ressources, ce qui nécessite notamment de pouvoir maîtriser l'instant d'émission des transactions par chaque coeur 10 et de pouvoir s'assurer que les transactions puissent être effectuées sans interférence entre elles. La structure et le fonctionnement de chaque coeur 10 sont décrit en référence aux Figures 3 à 6 illustrant un seul des coeurs 10, les ressources communes 12 et l'interconnexion 14, chacune des Figures 3 et 6 illustrant une étape de fonctionnement respective.

Comme illustré sur la Figure 3, chaque coeur 10 possède une mémoire cache privée 16, qui est utilisée exclusivement par ce coeur 10, et physiquement intégrée au coeur 10. Chaque coeur 10 exécute un superviseur 18 logiciel apte à intercepter les requêtes demandées par les applications exécutées par le coeur 10 avant l'émission d'une transaction correspondante par le coeur 10. Le superviseur 18 forme une couche logicielle interposée entre les applications exécutées par le coeur 10 (y compris un système d'exploitation exécuté par le coeur 10) et le coeur 10 lui-même. Le superviseur 18 est un programme informatique et comprend un ensemble d'instructions et de données propres à ce programme.

Chaque coeur 10 exécute son propre superviseur 18 localement, sans faire appel aux ressources communes 12. Le superviseur 18 comprend des instructions de code qui sont entièrement stockées dans la mémoire cache privée 16 du coeur 10 et exécutables en utilisant uniquement la mémoire cache privée 16 de ce coeur 10. La mémoire cache privée 16 du coeur 10 possède une capacité suffisante pour l'exécution du superviseur 18.

L'exécution du superviseur 18 par le coeur 10 ne nécessite donc pas l'émission de transactions vers les ressources communes 12, susceptibles d'interférer avec l'activité des autres coeurs 10 dans les ressources communes 12. La mémoire cache privée 16 de chaque coeur 10 est configurée pour ne pas propager les données mémorisées dans la mémoire cache privée 16. Un tel mode de fonctionnement d'une mémoire cache est généralement désigné par le terme anglais « copy-back ». Ainsi, les données mémorisées dans la mémoire cache privée 16 ne seront pas propagées dans une mémoire des ressources communes, par exemple une mémoire principale, ce qui provoquerait l'émission de transactions correspondantes entre le coeur 10 et la mémoire commune et qui seraient susceptibles d'interférer avec l'activité des autres coeurs 10 dans les ressources communes 12. Le superviseur 18 de chaque coeur 10 est configuré pour intercepter des requêtes demandées au coeur 10 par les applications, avant l'émission de transactions correspondantes par le coeur 10 vers les ressources communes 12, et pour commander l'émission par le coeur 10 d'au moins une transaction associée à chaque requête interceptée, dans une fenêtre temporelle associée à cette ou chaque transaction associée, selon la partition temporelle P. Chaque coeur 10 dispose d'au moins deux niveaux de privilège. Le superviseur 8 est au niveau de privilège le plus élevé, et chaque application est à un niveau de privilège inférieur à celui du superviseur 8. Si le coeur 10 exécute un système d'exploitation, ce dernier est par exemple à un niveau de privilège intermédiaire entre le niveau de privilège supérieur du superviseur 18 et le niveau de privilège des applications utilisateur. Chaque coeur 10 comprend une unité de gestion de mémoire 20 (ou MMU pour « Memory Management Unit » en anglais) permettant de gérer les accès des applications exécutées par le coeur 10 et du superviseur 18 à la mémoire cache privée 16 et à la ou chaque mémoire des ressources communes 12. Chaque coeur 10 comprend sa propre unité de gestion de mémoire 20, distincte de celle des aux autres coeurs 10. Chaque coeur 10 comprend ici une unité de gestion de mémoire 20 interne et intégrée physiquement à ce coeur 10. En variante, l'unité de gestion de mémoire est un composant matériel physiquement distinct du coeur 10 et relié à celui-ci. L'unité de gestion de mémoire 20 de chaque coeur 10 possède une mémoire interne contenant les adresses de l'espace adressable. Plus spécifiquement, l'espace mémoire est subdivisé en pages, chaque page contenant plusieurs adresses. L'unité de gestion de mémoire 20 de chaque coeur 10 contient une table des pages superviseur 20A et une table des pages utilisateur 20B contenant la définition des pages de l'espace mémoire, c'est-à-dire les règles de traduction des adresses logiques pointées par les requêtes des applications, en adresses physiques de l'espace mémoire adressable. La table des pages superviseur 20A est dédiée au superviseur 18 et la table des pages utilisateur 20B est dédiée aux applications.

La table des pages utilisateur 20B est configurée pour identifier les pages attribuées à l'utilisateur (les applications) dont le contenu est présent dans la mémoire cache privée 16. La configuration de l'unité de gestion de mémoire 20 est réservée au niveau de privilège supérieur, c'est-à-dire exclusivement au superviseur 18. Ainsi, seul le superviseur 18 du coeur 10 dispose du niveau de privilège suffisant pour modifier la configuration de l'unité de gestion de mémoire 20 de ce coeur 10. L'unité de gestion de mémoire 20 de chaque coeur 10 est configurée pour, lorsqu'une application émet une requête d'accès à une adresse qui n'est pas présente dans la mémoire cache privée 16, émettre un défaut de page déclenchant une interruption (ou « cache miss » en anglais) qui est reçue par le superviseur 18. Pour éviter qu'une interruption déclenchée sur un coeur 10 ne génère des échanges entre les coeurs 10 et leurs mémoires caches privées 16 respectives, le processeur 6 est configuré de manière qu'une interruption déclenchée par un coeur 10 est signalée exclusivement au superviseur 18 de ce coeur 10, sans communication avec les autres coeurs 10. Chaque interruption déclenchée sur un coeur 10 est restreinte au niveau de privilège supérieur de ce coeur 10, c'est-à-dire au superviseur 18. En outre, le processeur 6 est configuré de manière à désactiver les mécanismes de maintien de la cohérence des mémoires caches privées 16 des différents coeurs 10. Les mémoires caches privées 16 fonctionnent donc indépendamment les unes des autres, sans échange de données entre elles. La mémoire cache privée 16 de chaque coeur 10 comprend une partie superviseur 16A réservée au superviseur 18, qui est maintenue de manière persistante dans la mémoire cache privée 16, et une partie applicative 16B disponible pour stocker des données utiles aux applications exécutées par le coeur 10.

La partie superviseur 16A contient notamment les instructions de code du superviseur 18, ainsi que des tables stockées dans la mémoire cache privée par le superviseur 18 pour le contrôle et l'exécution des applications exécutées sur le coeur 10. Le superviseur 18 de chaque coeur 10 comprend des modules logiciels qui sont tous exécutés exclusivement depuis la mémoire cache privée 16 de ce coeur 10 et ne génèrent pas d'activité dans les ressources communes 12 autres que les transactions réalisées pour l'exécution des applications exécutées par les coeurs 10.

Le superviseur 18 de chaque coeur 10 comprend un module d'interception 22, un module de configuration 24 pour configurer l'unité de gestion de mémoire 20, un module d'analyse 26 pour analyser les requêtes, un module d'émission 28 pour émettre des transactions, un module de gestion du cache 30 et un module de synchronisation 32.

Module d'Interception Le superviseur 18 de chaque coeur 10 comprend un module d'interception 22 propre à s'exécuter lors des interruptions émises par l'unité de gestion de mémoire 20 de ce coeur 10. Ainsi, chaque requête demandée par une application (Flèche R1) et qui ne peut être servie à partir de la mémoire cache privée 16 du coeur 10, et nécessite donc d'émettre une transaction sur l'interconnexion 14, entraîne la levée d'une interruption (Flèche R2) qui est interceptée par le superviseur 18 avant l'émission d'une transaction associée. Il est possible qu'une application exécutée par un coeur 10 émette une requête de modification de la configuration de l'unité de gestion de mémoire 20 de ce coeur 10, pour modifier la table des pages utilisateur 21, en vue du bon fonctionnement de cette application (Flèche R3). C'est le cas en particulier pour un système d'exploitation exécuté par le coeur 10. L'unité de gestion de mémoire 20 est configurée de telle sorte qu'une requête de modification de la configuration de l'unité de gestion de mémoire 20 à un niveau de privilège inférieur à celui du superviseur 18 déclenche une exception de privilège (Flèche R4). Ainsi, toute tentative de modification de la configuration de l'unité de gestion de mémoire 20 à un niveau de privilège inférieur à celui du superviseur 18 ne corrompra pas la configuration courante. Module de configuration Le module de configuration 24 est configuré pour être exécuté lors des exceptions de privilège. Ainsi, chaque tentative de modification de la configuration de l'unité de gestion de mémoire 20 par les applications est détectée par le superviseur 18.

Le module de configuration 24 est configuré pour maintenir dans la partie superviseur 16A de la mémoire cache privée 16 une table des pages virtuelle 34 en fonction des exceptions de privilège détectées. Ainsi, les applications exécutées par le coeur 10 peuvent accéder à la table d'adressage virtuelle 34 qui n'est pas localisée dans l'unité de gestion de mémoire 20, au travers de l'unité de gestion de mémoire 20 et du superviseur 18, de manière transparente pour les applications, dont l'exécution n'est donc pas perturbée.

En outre, toute tentative d'écriture de la configuration de l'unité de gestion de mémoire 20 à un niveau de privilège inférieur à celui du superviseur 18 ne corrompra pas la configuration courante et déclenchera une exception de privilège vers le superviseur 18.

Ainsi, le mécanisme d'interruption des requêtes est étanche. Toute requête ne pouvant être servie par localement par la mémoire cache privée 16 est interceptée du fait de la configuration appropriée de l'unité de gestion de mémoire 20 par le superviseur 18, seul le superviseur 18 pouvant modifier la configuration de l'unité de gestion de mémoire 20.

Le superviseur 18 est programmé pour contrôler le contenu de la partie application 16B de la mémoire cache privée 16 et pour configurer l'unité de gestion de mémoire 20, en mettant à jour la table des pages utilisateur 20B, de façon à ne pas intercepter les requêtes pointant sur des pages présentes dans la partie application 16B de la mémoire cache privée 16.

Module d'analyse Le module d'analyse 26 est programmé, après appel du module d'interception 22, pour déterminer l'adresse physique correspondant à l'adresse logique pointée par la requête en se référant à la table des pages virtuelle 34 (flèche R5) et à une table d'accès aux ressources 36 (Flèche R6) spécifiant pour chaque transaction des paramètres d'accès aux ressources. Le module d'analyse 26 est ainsi programmé pour associer à chaque requête interceptée la transaction correspondante et pour lire la table d'accès aux ressources 36 pour déterminer les paramètres d'accès associés à cette transaction. Un paramètre d'accès est la ou chaque fenêtre temporelle associée à chaque transaction. Un autre paramètre d'accès aux ressources est le droit ou non d'accéder à une ressource. Un autre paramètre est par exemple le fait de savoir si le contenu de l'adresse visé par la requête est propre à être mémorisé dans la mémoire cache privée 16 du coeur 10 ou non. Le module d'analyse 26 du superviseur 18 de chaque coeur 10 est en outre configuré pour déterminer des transactions spéculatives entre une mémoire commune, en particulier la mémoire principale, et la mémoire cache privée 16 du coeur 10, en vue du stockage du résultat de ces transactions spéculatives dans la mémoire cache privée 16 du coeur 10.

Le module d'analyse 26 est programmé pour associer, à chaque transaction correspondant à une requête interceptée, une ou plusieurs transactions associées. Ces transactions associées comprennent la transaction correspondant à la requête ainsi que des éventuelles transactions spéculatives. Ces transactions spéculatives ne correspondent pas à des requêtes d'une application, mais à des requêtes susceptibles d'être émises après la requête interceptée. Si la requête vise une adresse mémoire qui appartient à une page comprenant plusieurs adresses, des requêtes susceptibles d'être émises sont des requêtes de lecture ou d'écriture des autres adresses de cette page. L'association de transactions spéculatives à une requête interceptée permet d'émettre ces transactions dans la même fenêtre temporelle que la transaction correspondant à la requête interceptée. Ceci permet d'améliorer l'utilisation de la fenêtre temporelle en émettant plusieurs transactions. En outre, le stockage des résultats de ces transactions spéculatives dans la partie application 16B rend les résultats disponibles localement dans la mémoire cache privée 16 du coeur 10 et par conséquent accessibles pour une application sans passer par l'interconnexion 14. Le module d'analyse 26 est programmé pour appeler le module d'émission 28 en vue de l'émission de chaque transaction. Le module d'analyse 26 des transactions est programmé pour appeler le module de gestion du cache 30 si la ressource est propre à être mémorisée dans la mémoire cache privée. Module d'émission Le module d'émission 28 est configuré pour émettre les transactions déterminées par le module d'analyse 26 sur l'interconnexion 14 (Flèche R7). Le module d'émission 28 est en charge de l'intégralité des émissions de transaction sur l'interconnexion 14. Chaque transaction émise par un coeur 10 sur l'interconnexion 14 est émise exclusivement par le module d'émission 28 de ce coeur 10. Le module d'émission 28 émet chaque transaction uniquement lorsque la fenêtre temporelle active est associée à cette transaction. Pour ce faire, le module d'émission appelle le module de synchronisation 32 Module de synchronisation Les coeurs 10 travaillent en parallèle. Dans la mesure où la politique de partage des ressources communes 12 est basée sur une partition temporelle comprenant des fenêtres temporelles, il est nécessaire de disposer d'un mécanisme de synchronisation des coeurs 10, afin que les coeurs 10 soient tous dans la même fenêtre temporelle à chaque instant.

Le module de synchronisation 32 qui a pour fonction de déterminer la fenêtre temporelle active. Pour ce faire, le module de synchronisation 32 consulte un registre temporel 40 permettant de synchroniser les coeurs 10 entre eux, afin que tous les coeurs 10 soient dans la même fenêtre temporelle à un chaque instant (Flèche R8).

Dans un mode de réalisation illustré sur la Figure 5, le processeur 6 possède une horloge 42 mettant à jour un registre temporel 34 commun aux coeurs 10, chaque coeur disposant d'un accès physique privé au registre temporel 40. Ainsi, chaque coeur 10 peut consulter le registre temporel 40 sans générer de transaction via l'interconnexion 14. Le registre temporel 40 est commun mais chaque coeur 10 dispose d'un accès direct et privatif au registre temporel 40, qui lui permet d'accéder au registre temporel 40 sans interférence avec les autres coeurs 10 et sans être en concurrence avec les autres coeurs 10. Dans un autre mode de réalisation illustré sur la Figure 6, le processeur 6 possède un registre temporel 40 respectif associé à chaque coeur 10, et une horloge 42 commune aux coeurs 10 et mettant à jour les registres temporels 40 de manière synchrone. Pour déterminer si le coeur 10 se situe dans une fenêtre temporelle autorisant l'émission d'une transaction déterminée, le module de synchronisation 32 est programmé pour consulter la table d'accès aux ressources 36 (Flèche R9). Le module de synchronisation 32 fonctionne dans une mode de fonctionnement bloquant ou dans un mode de fonctionnement non bloquant. Dans un mode de fonctionnement non bloquant, le module de synchronisation 32 interrogé par le module d'émission 28 pour l'émission d'une transaction attend qu'une fenêtre temporelle autorisant l'émission de cette transaction soit active pour retourner l'information au module d'émission 28 qui émet alors la transaction.

Dans un mode de fonctionnement bloquant, le module de synchronisation 32 interrogé par le module d'émission 28 pour l'émission d'une transaction retourne au module d'émission 28 une information (par exemple un booléen) indiquant si le coeur 10 se trouve dans une fenêtre temporelle autorisant l'émission de cette transaction ou si le coeur 10 se trouve dans une fenêtre temporelle n'autorisant par l'émission de cette transaction. Lorsque l'émission d'une transaction est demandée au module d'émission 28 par le module d'analyse 26, le module d'émission 28 appelle le module de synchronisation 32, puis émet la transaction dès qu'une fenêtre temporelle associée est active, puis termine la transaction. Si la transaction fait partie d'un groupe de transactions, ces opérations sont répétées pour chaque transaction appartenant à la séquence de transactions.

La terminaison d'une transaction inclut optionnellement la vérification que la transaction est bien terminée dans la fenêtre temporelle voulue et/ou la vérification qu'une seule transaction a été émise par le coeur 10. Module de gestion du cache Il n'est pas nécessaire d'intercepter des requêtes visant des adresses dont le contenu est déjà stocké dans la mémoire cache privée 16 et qui peut être récupéré sans émettre de transaction. Pour autant, il convient de s'assurer de manière certaine qu'une requête qui n'est pas interceptée pointe vers une adresse qui figure effectivement dans la mémoire cache privée 16 du coeur 10. Comme illustré sur la Figure 4, le module de gestion du cache 30 est programmé pour gérer le contenu de la partie application 16B de la mémoire cache privée 16 de manière à garantir l'absence de situations de défaut de cache, dans laquelle une application effectuerait un accès à la mémoire cache privée 16 du coeur sans que le contenu demandé s'y trouve et que le superviseur 18 initie alors une transaction non contrôlée vers une mémoire partagée. Le module de gestion du cache 30 doit garantir une correspondance totale entre les pages correspondant aux transactions non interceptées et celles qui sont effectivement présentes dans la mémoire cache privée 16. La mémoire cache privée 16 possède un service de verrouillage interne permettant de verrouiller des lignes de cache afin d'empêcher leur éviction du cache, ce service pouvant être appelé exclusivement par le superviseur 18 situé au niveau de privilège supérieur. Le module de gestion du cache 30 est configuré pour gérer, dans la partition superviseur 16A de la mémoire cache privée 16, une table de pages en cache 44 contenant des descripteurs des pages de la mémoire cache privée 16. La taille de la table des pages en cache 44 est égale au nombre de pages pouvant être chargées dans la partition applicative 16B de la mémoire cache privée 16 dédiée aux applications exécutée par le coeur 10. Par exemple si les pages font 4Ko (Kilooctet) et la partition applicative 16B fait 512Ko, la taille de la table des pages en cache 44 128.

La table des pages en cache 44 est par exemple organisée en un tableau dont chaque élément correspond à une page et est caractérisé par un ordre d'arrivée. A l'initialisation, l'ordre d'arrivée de chaque élément correspond à son numéro de colonne. Lorsque le module d'analyse 26 détermine un groupe de transactions à émettre pour le chargement d'une page, le module de gestion du cache 30 détermine un emplacement de stockage de la page dans la mémoire cache privée 16.

Pour ce faire, le module de gestion du cache 30 détermine la ligne de la table des pages en cache dans laquelle la page peut être stockée (Flèche R10). Si un emplacement est libre dans cette ligne, il alloue cet emplacement à la page demandée, fixe son ordre d'arrivéeà zéro et incrémente l'ordre d'arrivée de toutes les autres pages dans la ligne. Si aucun emplacement n'est libre dans cette ligne, le module de gestion du cache 30 attribue à la page demandée l'emplacement de l'élément le plus ancien. Il fixe l'ordre d'arrivéede la page demandée à zéro et incrémente l'ordre d'arrivée de toutes les autres pages dans la ligne. Le déchargement de la page préalablement stockée dans le cet emplacement est effectué avant ou simultanément au chargement de la page demandée à laquelle cet emplacement a été attribué. Si aucun emplacement n'est disponible dans la ligne concernée (par exemple parce que toutes les pages sont verrouillées), le module de gestion du cache 30 retourne un code d'erreur. Cette situation peut être évitée si on fixe une limite au nombre de pages pouvant être verrouillées. Le module de gestion du cache 30 appelle ensuite le module d'émission 28 pour l'émission des transactions en indiquant l'emplacement de chargement alloué à la page à charger dans la mémoire cache privée 16. Au fur et à mesure du chargement de la page, le module d'émission verrouille les lignes de cache chargées (Flèche R11).

Le module de gestion du cache 30 écrit dans la table des pages utilisateurs 20B de l'unité de gestion de mémoire 20, une entrée correspondant à la page chargée (Flèche R12). Si une application requiert l'accès à une adresse référencée dans la table des pages utilisateur 20B (Flèche R13), la table des pages utilisateurs 20B indiquera l'adresse physique dans la partie application 16B de la mémoire cache privée 16, et le coeur 10 retournera la réponse sans avoir à émettre de transaction (Flèche R14). Ainsi, le mécanisme d'interception est désactivé pour chaque adresse de la page chargée. Du fait du verrouillage des lignes de cache par le module de gestion du cache 30 du superviseur 18 situé au niveau de privilège supérieur, la modification des pages chargées dans la partie application 16B est interdites hors du contrôle du superviseur 18. Le superviseur 18 contrôle donc le contenu de la partie application 16B de la mémoire cache privée 16, ce qui évite qu'une requête ne soit pas interceptée alors que la page correspondante ne se situe pas dans la partie application 16B.

Le module de gestion du cache 30 est programmé pour demander au module d'émission 28 l'écriture, dans la mémoire principale, d'une page stockée dans la mémoire cache privée 16, sans décharger cette page de la mémoire cache privée 16. Lorsque ce service est appelé, le module de gestion du cache 30 appelle le module d'émission 28 qui force l'écriture de la page stockée en cache dans la mémoire principale. Ce service ne peut être appelé qu'explicitement par un appel système dirigé vers le superviseur 18 ou par un autre service du module de gestion du cache 30. Le module de gestion du cache 30 est configuré pour décharger dans la mémoire principale une page de la mémoire cache privée 16, en effaçant cette page de la mémoire cache privée 16. Ce service ne peut être appelé qu'explicitement par un appel système dirigé vers le superviseur 18. En fonctionnement un coeur 10 exécute une application sous le contrôle du superviseur 18. L'application émet une requête de lecture d'une adresse.

Si le contenu de l'adresse est stocké dans la partie applicative 16B de la mémoire cache privée 16, et est donc référencée dans l'unité de gestion de mémoire 20, l'unité de gestion de mémoire 20 traduit l'adresse logique demandée par l'application en une adresse physique correspondante dans la mémoire cache privée 16, le coeur 10 lit localement les données stockées à cette adresse physique de la mémoire cache privée 16, ce qui ne nécessite par l'émission d'une transaction vers les ressources communes 12. Si le contenu de l'adresse n'est pas stocké dans la partie applicative 16B de la mémoire cache privée 16, l'unité de gestion de mémoire 20 lève une interruption. L'interruption est détectée par le module d'interception 22. Le module d'interception 22 transmet la requête au module d'analyse 26. Le module d'analyse 26 associe à la requête interceptée au moins une transaction, de préférence une séquence de transaction pour le chargement de la page contenant l'adresse visée par la requête interceptée, à chaque transaction étant associée la ou chaque fenêtre temporelle associée à cette transaction. Le module d'interception 22 appelle le module d'émission pour l'émission de la ou chaque transaction associée à la requête interceptée. Pour chaque transaction, le module d'émission 22 appelle le module de synchronisation 32 qui détermine si la fenêtre temporelle active est associée à la transaction en consultant le registre temporel 40 auquel le coeur 10 a accès. Si la fenêtre temporelle est associée à la transaction, le module d'émission 28 émet la transaction. Sinon, le module d'émission attend que le module de synchronisation retourne un signal indiquant qu'une fenêtre temporelle associée à la transaction est active.

Le module d'analyse transmet la transaction associée à la requête au module de gestion du cache. Si le module de gestion du cache détermine que la page mémoire contenant l'adresse visée par la requête est susceptible d'être mémorisée dans la mémoire cache privée 16, le module de gestion du cache met en oeuvre la politique chargement des pages de manière à charger la page dans la mémoire cache privée 16. Si l'application émet une requête de modification de la configuration de l'unité de gestion de mémoire 20, l'unité de gestion de mémoire 20 émet une exception de privilège car l'application ne dispose pas du niveau de privilège suffisant, seul le niveau de privilège supérieur, donné uniquement au superviseur 18, permettant de modifier la configuration de l'unité de gestion de mémoire. Le module de configuration tient à jour la table des pages virtuelles stockée dans la partie superviseur 16A de la mémoire cache privée 16. Dans le mode de réalisation décrit, l'unité élémentaire de chargement de données dans la mémoire cache privée 16 est la page mémoire contenant plusieurs adresses mémoire. Lorsqu'un chargement associé à une adresse est effectué dans la mémoire cache privée 16, l'ensemble de la page mémoire contenant cette adresse est chargée dans la mémoire cache privée 16. Le module de gestion du cache 30 tient à jour une table des pages en cache. Grâce à l'invention, il est possible de contrôler les transactions émises par les coeurs à destination des ressources communes grâce à des mécanismes logiciels, qui permettent l'utilisation dans un contexte avionique de processeurs à coeurs multiples qui n'ont pas été conçus au départ pour répondre aux contraintes des systèmes avioniques embarqué, notamment pour une architecture modulaire (IMA), un partitionnement robuste et la détermination sûre et modulaire des pires temps d'exécution.

Le contrôle des transactions est obtenu grâce à l'interception de requêtes émises par les applications exécutées par chaque coeur 10 avant que ce coeur 10 n'émette une transaction associée, l'analyse de la transaction par rapport à une table d'accès aux ressources vérifiant les droits d'accès et décrivant la procédure d'émission, et l'émission de la transaction dans une fenêtre temporelle dans laquelle l'émission de cette transaction spécifique est autorisée. Le contrôle des transactions est optimisé par l'association de chaque transaction à une séquence de transactions pour le chargement conjoint de plusieurs adresses dans la mémoire cache privée, auxquelles une application pourra alors accéder sans interception de sa requête.

En particulier, le contrôle des transactions est effectué de manière à charger (ou décharger) une page mémoire contenant l'adresse visée par la requête interceptée dans la mémoire cache privée. Les pages disponibles dans la mémoire cache privée sont gérées par un module de gestion du cache 30 dédié qui est appelé avant l'émission de la transaction. Le contrôle des transactions est optimisé par le contrôle exclusif du contenu de la mémoire cache privée 16 par le superviseur 18 et la configuration exclusive correspondante de l'unité de gestion de mémoire 20 par le superviseur 18 de manière à ne pas intercepter une requête, et donc à autoriser la lecture de la mémoire cache privée 16, uniquement pour les requêtes dont le contenu de l'adresse visée figure avec certitude dans la mémoire cache privée 16.

Le calculateur est paramétrable pour la mise en oeuvre de l'invention sans connaissance a priori des applications destinées à être exécutées sur le calculateur. Le calculateur est en particulier rétro-compatible avec des applications déjà existantes. Le calculateur est réalisable avec un processeur multicoeur générique qui n'a pas été conçu spécifiquement pour la fabrication de ce calculateur ni pour l'exécution des applications destinée à tourner sur le calculateur. Le calculateur est réalisable avec une connaissance limitée du processeur multicoeur. Le calculateur est configuré de telle manière que l'émission des transactions est supervisé par le superviseur 18 : le superviseur 18 contrôle le contenu de la mémoire cache privée 16 accessible aux applications, il contrôle la configuration de l'unité de gestion de mémoire 20 permettant aux applications d'accéder à ce contenu, il intercepte toute requêtes qui ne peut être servie localement à partir de la mémoire cache privée 16, et il contrôle l'émission d'une ou plusieurs transactions associées dans une fenêtre temporelle associée à la ou chaque transaction.

Le processeur est configuré de manière à ce que l'émission d'une transaction d'un coeur vers une ressource commune n'entraîne pas l'émission de transaction vers ou par les autres coeurs 10. En particulier, la mise en cohérence des mémoires cache privées est désactivée.

Claims (19)

1. REVENDICATIONS1.- Calculateur comprenant un processeur (8) multicoeur possédant plusieurs coeurs (10) et des ressources communes (12) partagées par les coeurs (10), - dans lequel chaque coeur (10) exécute au moins une application, et chaque coeur (10) est propre à émettre des transactions vers les ressources communes (12), parmi un ensemble de transactions possibles entre les coeurs (10) et les ressources communes (12) ; - dans lequel chaque coeur (10) possède une mémoire cache privée (16) et exécute un superviseur (18) logiciel dédié à ce coeur (10), le superviseur (18) étant exécuté par le coeur (10) localement depuis sa mémoire cache privée (16), le superviseur (18) de chaque coeur (10) étant configuré pour intercepter chaque requête émise par la ou chaque application et dont le résultat n'est pas disponible dans la mémoire cache privée (16), et pour émettre au moins une transaction pour répondre à chaque requête interceptée, chaque transaction étant émise dans une fenêtre temporelle associée à cette transaction selon une partition temporelle comprenant des fenêtres temporelles disjointes, chaque fenêtre temporelle étant associée à au moins une transaction, au moins une fenêtre temporelle étant associée à chaque transaction.
2. 2.- Calculateur selon la revendication 1, dans lequel au moins une fenêtre temporelle est à associée à plusieurs transactions.
3. 3.- Calculateur selon la revendication 1 ou la revendication 2, dans lequel au moins une fenêtre temporelle est associée à plusieurs transactions incluant des transactions émises par des coeurs différents.
4. 4.- Calculateur selon l'une quelconque des revendications précédentes, chaque coeur (10) comprend au moins une table d'accès-aux ressources (36) stockée dans sa mémoire cache privée (16) et indiquant la ou chaque fenêtre temporelle dans laquelle l'émission de la ou chaque transaction est autorisée.
5. 5.- Calculateur selon la revendication 4, dans lequel la table d'accès aux ressources (36) de chaque coeur (10) est consultable et modifiable uniquement par le superviseur (18) de ce coeur (10).
6. 6.- Calculateur selon l'une quelconque des revendications précédentes, dans lequel chaque coeur (10) comprend une unité de gestion de mémoire (20) configurée pour lever une interruption à la réception d'une requête dont le résultat n'est pas disponible dans la mémoire cache privée (16), le superviseur (18) étant configuré pour détecter chaque interruption générée par l'unité de gestion de mémoire (20).
7. 7.- Calculateur selon la revendication 6, dans lequel le superviseur (18) de chaque coeur (10) est configuré pour intercepter chaque requête de configuration de l'unité de gestion de mémoire (20) émises par une application logicielle exécutée sur le coeur (10), et gérer une table d'adressage virtuelle (34) en fonction des instructions de configuration de l'unité de gestion de mémoire (20).
8. 8.- Calculateur selon la revendication 7, dans lequel le superviseur (18) est configuré pour lire la table d'adressage virtuelle (34) en fonction de chaque requête interceptée, et déterminer une transaction correspondante pour répondre à cette requête.
9. 9.- Calculateur selon la revendication 8, dans lequel le superviseur (18) est configuré pour associer à une requête interceptée la transaction correspondante et au moins une transaction spéculative destinée à être émises dans la même fenêtre temporelle que la transaction correspondant à la requête interceptée.
10. 10.- Calculateur selon la revendication 9, dans lequel le superviseur (18) de chaque coeur (10) comprend un module d'analyse (26) propre à déterminer une transaction correspondant à chaque requête interceptée et des transactions spéculatives, et à demander l'émission de la transaction correspondante et des transactions spéculatives entre une mémoire apparentant aux ressources communes (12) et la mémoire cache privée (16) du coeur (10).
11. 11.- Calculateur selon l'une quelconque des revendications 6 à 10, dans lequel le superviseur (18) de chaque coeur (10) comprend un module de gestion du cache (30) propre à allouer un espace de la mémoire cache privée (16) au stockage du résultat d'une ou plusieurs transactions, à modifier la configuration de l'unité de gestion de mémoire (20) pour ne pas intercepter les requêtes dont le résultat est stocké dans la mémoire cache privée (16), à modifier la configuration de l'unité de gestion de la mémoire (20) pour intercepter les requêtes dont le résultat n'est plus stocké dans la mémoire cache privée.
12. 12.- Calculateur selon la revendication 11, dans lequel le module de gestion du cache (30) est configuré pour gérer au moins une liste des espaces de la mémoire cache privée (16) dont le contenu est remplaçable ou effaçable et qui sont susceptible d'être allouer au stockage de nouveaux résultats.
13. 13.- Calculateur selon l'une quelconque des revendications précédentes, dans lequel le superviseur (18) comprend un module de synchronisation (32) propre à déterminer la fenêtre temporelle active.
14. 14.- Calculateur selon la revendication 13, dans lequel le processeur (18) comprend une horloge (42) mettant à jour un registre temporel (40) respectif dédié à chaque coeur (10), le processeur étant configuré pour la mise à jour des registres temporels (40) tfé manière synchrone.
15. 15.- Calculateur selon la revendication 13, dans lequel le processeur (6) comprend une horloge (42) mettant à jour un registre temporel (40) commun aux coeurs (10), chaque coeur (10) possédant un chemin physique (43) respectif dédié d'accès au registre temporel commun.
16. 16.- Procédé de contrôle d'un processeur multicoeur possédant plusieurs coeurs (10) physiquement distincts et des ressources communes (12) partagées par les coeurs (12), chaque coeur (10) comprenant une mémoire cache privée (16) et étant propre à émettre des transactions vers les ressources communes (12), parmi un ensemble de transactions réalisables entre les coeurs (10) et les ressources communes (12), en réponse à des requêtes d'applications exécutées par ce coeur (10), chaque coeur (10) possédant une mémoire cache privée (16), le procédé comprenant les étapes suivantes mises en oeuvre par chaque coeur (10) - interception de chaque requête dont le résultat n'est pas disponible dans la mémoire cache privée (16) par un superviseur (18) logiciel dédié à ce coeur (10) et exécuté par ce coeur (10) localement depuis sa mémoire cache privée (16), et - émission par le superviseur (18) d'une ou plusieurs transactions associées à la requête interceptée, en émettant la ou chaque transaction dans une fenêtre temporelle associée à chaque transaction émise, selon une partition temporelle comprenant des fenêtres temporelles disjointes, chaque fenêtre temporelle étant associée à au moins une transaction, au moins une fenêtre temporelle étant associée à chaque transaction.
17. 17.- Procédé selon la revendication 16, comprenant la configuration par le superviseur (18) de chaque coeur (10) d'une unité de gestion de mémoire (20) de manière à ce que l'unité de gestion de mémoire (20) lève une interruption à la réception d'une requête dont le résultat n'est pas disponible dans la mémoire cache privée (16).
18. 18.- Procédé selon la revendication 17, comprenant l'interception par le superviseur (18) des instructions de configuration de l'unité de gestion de la mémoire (20) émises par une application exécutée par le coeur (10), et la gestion par le superviseur (18) d'une table d'adressage virtuelle (34) en fonction des instructions de configuration interceptées.
19. 19.- Procédé selon l'une quelconque des revendications 16 à 18, comprenant l'association à chaque requête interceptée, d'une transaction correspondante répondant à la requête et d'au moins une transactions spéculatives, destinées à être émise dans la même fenêtre temporelle que la transaction correspondante.