Brevet FR3045866A1 — publié le 20170623

CALCULATEUR COMPRENANT UN PROCESSEUR MULTI-COEURS ET PROCEDE DE CONTROLE La présente invention concerne le domaine des calculateurs à processeurs multi- coeurs, comprenant plusieurs coeurs physiquement distincts partageant des ressources matérielles communes. Chaque coeur d'un processeur multi-coeurs 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, afin d'offrir de meilleures performances globales. Pour l'exécution des applications logicielles, les coeurs utilisent des ressources matérielles communes. Ces ressources communes sont par exemple des mémoires, notamment une mémoire principale, un réseau d'interconnexion, des interfaces entrée/sortie (ou interface I/O) du calculateur (Bus rapide PCIe ou Réseau Ethernet par exemple) ou encore une interface d'interconnexion entre les coeurs et ces différentes ressources communes. Les coeurs sont en concurrence pour l'utilisation de ces ressources communes. Cette concurrence entraîne une incertitude dans le temps de traitement des données par le processeur mufti-coeurs. Or, les systèmes électroniques embarqués tels que ceux utilisés dans le domaine avionique, le domaine spatial ou le domaine ferroviaire, ont besoin de déterminisme dans la durée des traitements pour satisfaire des contraintes de certification. Il est possible d'organiser les codes informatiques des applications logicielles exécutées par les coeurs de manière à assurer un ordonnancement des tâches tel qu'à un instant donné, un seul coeur a le droit d'accéder aux ressources communes. Néanmoins, cette conception des applications logicielles est très contraignante et difficilement adaptable à des systèmes électroniques embarqués, surtout ceux qui sont développés sans avoir connaissance des applications logicielles qu'ils auront à exécuter, comme c'est le cas d'un système avionique modulaire intégré (ou « IMA » pour « Integrated Modular Avionics » en anglais). Il est possible de déployer un contrôleur logiciel mettant en oeuvre une politique d'accès aux ressources communes basée sur l'allocation de fenêtres temporelles aux coeurs, chaque coeur ayant un accès exclusif aux ressources communes pendant les fenêtres temporelles qui lui sont allouées. L'allocation des fenêtres temporelles est prédéterminée et statique. 3045866 2 Néanmoins, l'accès aux ressources communes n'est pas optimisé et la durée des traitements s'en trouve affectée, ce qui peut être préjudiciable dans des systèmes électroniques embarqués. Un des buts de l'invention est de proposer un calculateur à processeur multi- 5 coeurs implémentant un procédé de contrôle efficace, permettant d'améliorer l'utilisation des ressources communes tout en assurant un bon niveau de déterminisme dans la durée de traitement des données. A cet effet, l'invention propose un calculateur comprenant un processeur multicoeurs possédant plusieurs coeurs physiquement distincts et des ressources matérielles 10 communes partagées par les coeurs et accessibles aux coeurs selon une séquence de fenêtres temporelles et en fonction de règles d'accès prédéfinies enregistrées dans au moins une mémoire du calculateur et mises en oeuvre par le calculateur en cours de fonctionnement, selon lesquelles dans chaque fenêtre temporelle, chaque coeur a, pour chaque ressource commune, un accès garanti, un accès sur demande ou un accès 15 interdit à la ressource commune, la séquence incluant au moins une fenêtre temporelle pendant laquelle au moins un coeur a un accès garanti à au moins une ressource commune et au moins une fenêtre temporelle pendant laquelle plusieurs coeurs ont un accès sur demande à une même ressource commune, l'accès à ladite même ressource commune étant attribuable à un ou plusieurs coeurs parmi lesdits plusieurs coeurs ayant 20 un accès sur demande, selon les règles d'accès et en fonction des demandes d'accès émises par lesdits plusieurs coeurs. Le calculateur comprend en option une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles : - la séquence comprend au moins une fenêtre temporelle pendant laquelle l'accès 25 à une ressource commune ou à chaque ressource commune est réservé exclusivement à un ou plusieurs coeurs ayant un accès garanti à cette ressource commune ou à chaque ressource commune ; - la séquence comprend au moins une fenêtre temporelle pendant laquelle l'accès à une ressource commune ou à chaque ressource commune est réservé exclusivement à 30 un seul et unique coeurs ayant un accès garanti à cette ressource commune ou à chaque ressource commune ; - la séquence comprend au moins une fenêtre temporelle pendant laquelle l'accès à une ressource commune ou à chaque ressource commune est attribuable exclusivement à un ou plusieurs coeurs parmi plusieurs coeurs ayant un accès sur 35 demande à cette ressource commune ou à chaque ressource commune ; 3045866 3 - la séquence comprend au moins une fenêtre temporelle pendant laquelle l'accès à une ressource commune ou à chaque ressource commune est attribuable exclusivement à un seul et unique coeur parmi plusieurs coeurs ayant accès sur demande à cette ressource commune ou à chaque ressource commune ; 5 - la séquence comprend au moins une fenêtre temporelle pendant laquelle l'accès à des premières ressources communes est attribuable à au moins un coeur d'un premier groupe de coeurs selon un premier jeu de règles d'accès et l'accès des deuxièmes ressources communes distinctes de premières ressources communes est attribuable à au moins un coeur d'un deuxième groupe de coeurs disjoint du premier groupe de coeurs 10 selon un deuxième jeu de règles d'accès indépendantes de celles du premier jeu de règles d'accès ; - la séquence comprend une première phase possédant des fenêtres temporelles ayant une même première durée et une deuxième phase possédant des fenêtres temporelles ayant une même deuxième durée différente de la première durée ; 15 - il est configuré de sorte que chaque coeur exécute un contrôleur d'accès appliquant les règles d'accès pour déterminer, pour chaque fenêtre temporelle, si ce coeur est à un accès garanti ou un accès sur demande à une ressource commune ou à chaque ressource commune pendant cette fenêtre temporelle ; - les contrôleurs d'accès des différents coeurs sont synchronisés à partir d'une 20 horloge de référence commune aux coeurs ; - le contrôleur d'accès de chaque coeur est exécuté par le coeur à partir d'une mémoire cache du coeur intégrée physiquement au coeur, sans accéder aux ressources communes ; - chaque fenêtre temporelle pendant laquelle plusieurs coeurs ont un accès sur 25 demande à au moins une même ressource commune, comprend une période de notification pendant laquelle chaque coeur indique aux autres coeurs s'il souhaite ou non réserver la fenêtre temporelle, une période de décision pendant laquelle chaque coeur détermine s'il est autorisé à accéder aux ressources partagées pendant la fenêtre temporelle, en fonction des demandes émises par les autres coeurs, et une période 30 d'utilisation pendant laquelle chaque coeur autorisé peut accéder aux ressources partagées. L'invention concerne également une procédé de contrôle d'un processeur multicoeurs possédant plusieurs coeurs physiquement distincts ayant accès à des ressources matérielles communes partagées par les coeurs et accessibles aux coeurs selon une 35 séquence de fenêtres temporelles et en fonction de règles d'accès prédéfinies enregistrées dans au moins une mémoire du calculateur et selon lesquelles, dans chaque 3045866 4 fenêtre temporelle, chaque coeur a, pour chaque ressource commune, un accès garanti, un accès sur demande ou un accès interdit à la ressource commune, la séquence incluant au moins une fenêtre temporelle pendant laquelle au moins un coeur a un accès garanti à au moins une ressource commune, et au moins une fenêtre temporelle pendant 5 laquelle plusieurs coeurs ont un accès sur demande à une même ressource commune, le procédé comprenant, au cours du fonctionnement du processeur, l'attribution de l'accès à ladite même ressource commune à un ou plusieurs coeurs parmi lesdits plusieurs coeurs ayant un accès sur demande, en fonction des demandes d'accès émises par lesdits plusieurs coeurs. 10 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 multi-coeurs possédant plusieurs 15 coeurs partageant des ressources communes ; - les Figures 2 à 5 sont des frises temporelles illustrant des partitions temporelles de partage des ressources communes; - la Figure 6 est une frise temporelle illustrant différentes phases d'une fenêtre temporelle d'une partition temporelle de partage des ressources communes ; 20 - la Figure 7 représente des graphiques illustrant différentes phases d'acquisition, d'exécution et de restitution par deux coeurs d'un processeur multi-coeurs. Sur la Figure 1, un système avionique 2 embarqué dans un aéronef 4 possède un calculateur 6 possédant un processeur 8 multi-coeurs comprenant plusieurs coeurs 10, des ressources communes 12 partagées par les coeurs 10, et une interconnexion 14 25 électronique 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. 30 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 35 de communication (non représenté), par exemple un bus de communication du système 3045866 5 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 5 du même et unique moyen formé par l'interconnexion 14. Chaque coeur 10 est apte à exécuter une ou plusieurs applications logicielles utiles, de préférence sous le contrôle d'un système d'exploitation informatique (ou « OS » pour « Operating System » en anglais), qui est une application logicielle particulière exécutée par le coeur 10 et qui contrôle l'utilisation des ressources logicielles ou 10 matérielles accessibles à ce coeur 10 (y compris les ressources communes 12) par les applications logicielles utiles. Chaque coeur 10 peut posséder son propre système d'exploitation individuel, mais aussi disposer d'un système d'exploitation partagé entre plusieurs coeurs 10. Dans la suite, le terme « application AP » désigne les applications logicielles utiles ou le système d'exploitation exécuté par un coeur 10. 15 Lors de son exécution, une application AP exécutée par un coeur 10 é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. Pour répondre à une requête d'une application AP exécutée par un coeur 10, le 20 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. Lors de l'exécution des applications AP par les coeurs 10, les coeurs 10 sont en concurrence pour l'utilisation des ressources communes 12. Or, chaque transaction entre 25 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 30 communes 12. Comme illustré sur la Figure 2, le calculateur 6 est configure pour mettre en oeuvre une politique de partage des ressources communes 12 basée sur une séquence de fenêtres temporelles F1, F2 incluant au moins une fenêtre temporelle pendant laquelle au moins un coeur 10 à un accès garanti à au moins une ressource commune 12 sans avoir 35 à demande une autorisation préalable, et au moins une fenêtre temporelle pendant laquelle plusieurs coeurs 10 ont accès sur demande à au moins une même ressource 3045866 6 commune 12, chaque coeur 10 étant autorisé ou non à accéder à la ressource commune 12 en fonction des demandes d'accès faites par les autres coeurs 10 et de règles d'accès prédéfinies. La séquence de fenêtre est périodique. 5 L'accès garanti ou sur demande de chaque coeur 10 à chaque ressource commune 12 pendant chaque fenêtre temporelle F1, F2, est prédéfini lors de la conception et de la configuration du calculateur 6. Dans chaque fenêtre temporelle, pour chaque ressource commune 12, chaque coeur 10 a sélectivement un accès garanti à cette ressource commune 12, un accès sur 10 demande à cette ressource commune 12 ou un accès interdit à cette ressource commune 12. Les règles d'accès définissent, pour chaque fenêtre temporelle F1, F2, chaque coeur 10 et chaque ressource commune 12, si, pendant la fenêtre temporelle F1, F2, le coeur 10 à un accès garanti à la ressource commune 12, un accès sur demande à la 15 ressource commune 12 ou un accès interdit à la ressource commune 12. Dans une mode de réalisation, pendant au moins une fenêtre temporelle, plusieurs coeurs 10 ont un accès garanti à une même ressource commune 12 et/ou pendant au moins une fenêtre temporelle, au moins un coeur 10 a un accès garanti à une ressource commune 12 et plusieurs autres coeurs 10 ont accès sur demande à cette même 20 ressource commune 12. Dans les deux cas, des coeurs 10 sont en concurrence pour l'accès à une même ressource commune 12. De préférence, dans chaque fenêtre temporelle pour laquelle un coeur 10 a un accès garanti à une ressource commune 12 déterminée, ce coeur 10 est le seul et unique coeur à avoir accès à cette ressource commune 12 déterminée. Ce coeur 10 à un accès 25 exclusif à cette ressource commune 12. Aucun autre coeur 10 n'a un accès garanti ou un accès sur demande à cette ressource commune 12. Tous les autres coeurs 10 ont un accès interdit à cette ressource commune 12. Dans un mode de réalisation, au moins dans une fenêtre temporelle, au moins un coeur 10 a un accès garanti à au moins une première ressource commune 12 et plusieurs 30 autres coeurs 10 ont accès sur demande à au moins une deuxième ressource commune 12, chaque première ressource commune 12 étant distincte de chaque deuxième ressource commune 12. Dans un mode de réalisation, au moins dans une fenêtre temporelle, et notamment dans une phase comprenant plusieurs fenêtre temporelles successives, un 35 premier groupe de coeurs 10 à un accès garanti ou sur demande à un premier groupe de ressource communes 12 selon un premier jeu de règles d'accès propres à ce premier 3045866 7 groupe de coeurs 10, et un deuxième groupe de coeurs 10, distincts de ceux du premier groupe de coeurs 10, a un accès garanti ou sur demande à un deuxième groupe de ressources communes 12 distinctes de celles du premier groupe de ressources communes 12, selon un deuxième jeu de règles d'accès propres à ce deuxième groupe 5 de coeurs 10 et indépendantes de celles du premier jeu de règles d'accès. De telles règles d'accès sont acceptables dès lors que l'accès aux ressources communes 12 n'entraine pas d'interférence dans l'interconnexion 14. De manière générale, chaque coeur 10 dispose, pour chaque ressource commune 12, d'au moins une fenêtre temporelle pendant laquelle il a un accès garanti ou un accès 10 sur demande à cette ressource commune 12. De manière générale, dans une même fenêtre temporelle, les règles d'accès de chaque coeur 10 aux ressources communes 12 sont différentes d'une ressource commune 12 à l'autre, ou identiques pour toutes les ressources communes 12. Dans une fenêtre temporelle, un coeur 10 peut avoir à un accès garanti à une ressource commune 15 et un accès sur demande à une autre ressource commune 12. Dans un mode de réalisation, dans chaque fenêtre temporelle, les règles d'accès de chaque coeur 10 aux ressources communes 12 sont identiques pour toutes les ressources communes 12. Ainsi, dans chaque fenêtre temporelle, chaque coeur 10 a sélectivement un accès garanti à chaque ressources communes 12, un accès sur 20 demande à chaque ressource commune 12 ou un accès interdit à chaque ressource commune 12. Dans le mode de réalisation de la Figure 2, dans chaque fenêtre temporelle, les règles d'accès de chaque coeur 10 aux ressources communes 12 sont identiques pour toutes les ressources communes 12. 25 Les fenêtres temporelles comprennent des fenêtres temporelles à accès garanti F1 et des fenêtres temporelles à accès régulé F2. De préférence, dans chaque fenêtre temporelle à accès garanti F1, un seul et unique coeur 10 auquel cette fenêtre est dite « allouée », a un accès garanti aux ressources communes 12. Tous les autres coeurs 10 ont un accès interdit aux ressources 30 communes 12. Dans chaque fenêtre temporelle à accès régulé F2, plusieurs coeurs 10 auxquels cette fenêtre est dite « allouée », ont accès sur demande aux ressources communes 12, l'accès de chaque coeur 10 ayant demandé à accéder aux ressources communes 12 étant autorisé ou interdit en fonction des demandes d'accès faites par les autres coeurs 10 35 et de règles d'accès prédéfinies. 3045866 8 Un coeur 10 auquel la fenêtre temporelle à accès régulé F2 n'est pas allouée, a un accès interdit au ressources communes 12. Lorsqu'un coeur 10, après demande, a un accès autorisé aux ressources communes 12 dans une fenêtre temporelle à accès régulé F2, cette fenêtre temporelle à 5 accès régulé F2 est dite « attribuée » à ce coeur 10. De préférence, chaque fenêtre temporelle à accès régulé F2 est attribuée en fonction des demandes d'accès faites par les coeurs 10 et de règles d'accès prédéfinies, à un seul et unique coeur 10 parmi les coeurs 10 demandant à accéder au ressources communes 12 pendant cette fenêtre temporelle à accès régulé F2. 10 L'autorisation d'accès dans une fenêtre temporelle à accès garanti F1 est invariable au cours du fonctionnement du calculateur 6. Elle ne peut pas être modifiée au cours du fonctionnement du calculateur 6. Seul le coeur 10 auquel cette fenêtre temporelle à accès garanti F1 est allouée est autorisé à accéder aux ressources communes 12 pendant cette fenêtre temporelle à accès garanti F1. 15 L'attribution d'une fenêtre temporelle à accès régulé F2 est obtenue sur demande d'un ou plusieurs coeurs) 10 auxquels la fenêtre temporelle à accès régulé F2 a été allouée, au cours du fonctionnement du calculateur 6. La séquence est périodique et la demande d'accès doit être réitérée à chaque occurrence de la fenêtre temporelle à accès régulé F2. 20 En option, la séquence comprend au moins une fenêtre temporelle à accès interdit F3, pendant laquelle chaque coeur 10 a un accès interdit aux ressources communes 12. Ceci permet par exemple de laisser un accès aux ressources communes 12 à un composant logiciel ou matériel extérieur non pris en charge par la politique de partage. En revenant à la Figure 1, l'application des règles d'accès aux ressources 25 communes 12 pendant les fenêtres temporelles est avantageusement réalisée de manière distribuée par les coeurs 10. Chaque coeur 10 possède une mémoire cache privée 16, qui est utilisée exclusivement par ce coeur 10, et qui est physiquement intégrée au coeur 10. Chaque coeur 10 comprend un contrôleur d'accès 18 logiciel pour contrôler l'accès 30 de ce coeur 10 aux ressources communes 12. Le contrôleur d'accès 18 est 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 contrôleur d'accès 18 est un programme informatique qui comprend des instructions de codes propres à ce programme. 35 Chaque coeur 10 exécute son propre contrôleur d'accès 18 localement, sans faire appel aux ressources communes 12. Le contrôleur d'accès 18 comprend des instructions 3045866 9 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 contrôleur d'accès 18. L'exécution du contrôleur d'accès 18 par le coeur 10 5 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. Le contrôleur d'accès 18 de chaque coeur 10 est configuré pour intercepter des requêtes adressées au coeur 10 par les applications AP exécutées par ce coeur 10, avant 10 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 allouée au coeur 10. Le contrôleur d'accès 18 de chaque coeur 10 est configuré pour mettre en oeuvre la politique de partage des ressources communes relativement au coeur 10 exécutant ce 15 contrôleur d'accès 18. Chaque contrôleur d'accès 18 applique des règles d'accès 20 stockées par exemple dans la mémoire vive 16 du coeur 10. Les contrôleurs d'accès 18 sont synchronisés sur une horloge commune 22. Ceci permet de s'assurer que chaque contrôleur d'accès 18 se situe dans la même fenêtre temporelle de la séquence à chaque instant. 20 Pour chaque fenêtre temporelle à accès garanti Fl, le contrôleur d'accès 18 de chaque coeur 10 auquel cette fenêtre temporelle à accès garanti F1est allouée, autorise l'accès de ce coeur 10 aux ressources communes 12. Les fenêtres temporelles à accès régulé F2 sont attribuables à un ou plusieurs coeur(s) 10, sur demande effectuée par ce(s) coeurs(s) 10. L'attribution effectuée sur 25 demande permet d'attribuer la fenêtre temporelle à un coeur 10 seulement sur demande de ce coeur 10, si une application AP exécutée par ce coeur 10 a émis une requête nécessitant l'émission d'une transaction. Le contrôleur d'accès 18 de chaque coeur 10 demande l'attribution de chaque fenêtre temporelle à accès régulé F2 allouée à ce coeur 10 si une application AP exécutée 30 par ce coeur 10 a besoin d'accéder aux ressources communes 12. Pour l'attribution d'une fenêtre temporelle à accès régulé F2, chaque contrôleur d'accès 18 ayant intercepté une requête, envoie une requête d'accès visible des contrôleurs d'accès 18 des autres coeurs 10, et chaque contrôleur d'accès 18 détermine localement si la fenêtre temporelle à accès régulé F2 est attribuée au coeur 10 35 correspondant par application de règles d'accès 20. Si la fenêtre temporelle à accès 3045866 10 régulé F2 est attribuée au coeur 10, le contrôleur d'accès 18 émet la transaction correspondant à la requête interceptée. Il est possible que plusieurs coeurs 10 demandent l'attribution d'une même fenêtre temporelle à accès régulé F2 qui n'est attribuable qu'à un nombre limité de coeurs 10 5 strictement inférieur aux nombre de coeurs 10 total du processeur 8. Pour régler ces cas, les règles d'accès 20 comprennent par exemple un ordre de priorité associé à chaque coeur 10 pour chaque fenêtre temporelle à accès régulé F2. Si deux coeurs 10 demandent l'accès à une même fenêtre temporelle à accès régulé F2, le coeur 10 ayant l'ordre de priorité le plus élevé se verra attribuer la fenêtre temporelle à 10 accès régulé F2 prioritairement. Même si chaque coeur 10 exécute un contrôleur d'accès 18 qui applique localement les règles d'accès 20 adaptées à ce coeur 10, les règles d'accès appliquées par les contrôleurs d'accès 18 des différents coeurs 10 sont bien entendu définies de façon cohérente. 15 Par exemple, pour une fenêtre temporelle donnée : - si l'accès aux ressources communes 12 doit être autorisé à un seul et unique coeur 10 identifié à la conception (i.e. il s'agit d'une fenêtre temporelle à accès garanti F1 allouée exclusivement à ce coeur 10), les règles d'accès définissent un accès garanti pour ce coeur 10 et un accès interdit pour tous les autres coeurs 10 ; 20 - si l'accès aux ressources communes doit être autorisé à plusieurs coeurs seulement identifiés à la conception (i.e. il s'agit d'une fenêtre temporelle à accès garanti F1 allouée à plusieurs coeurs 10), les règles d'accès définissent par exemple un accès garanti aux coeurs 10 en question et un accès interdit pour tous les autres coeurs 10; - si l'accès aux ressources communes 12 doit être autorisé à un seul coeur parmi 25 plusieurs coeurs pouvant en faire la demande, les règles d'accès définissent par exemple un accès sur demande pour certains coeurs 10 et un accès interdit pour tous les autres coeurs 10, les coeurs 10 ayant un accès autorisé sur demande ayant des priorités différentes ; - si l'accès aux ressources communes doit être autorisé à un coeur 10 particulier et 30 un seul autre coeur 10 sur demande, les règles d'accès définissent par exemple que le coeur 10 particulier a un accès garanti et que tous les autres coeurs 10 ont un accès sur demande ou un accès interdit, les coeurs 10 ayant un accès sur demande ayant des priorités différentes, - si l'accès aux ressources communes doit être autorisé à au plus deux coeurs 10 35 les règles d'accès définissent par exemple que tous les coeurs 10 ont un accès sur demande ou un accès interdit, la même priorité n'étant pas partagée par plus de deux 3045866 11 coeurs 10 ayant un accès sur demande ou que tous les coeurs 10 ont un accès sur demande ou un accès interdit, les coeurs 10 ayant un accès sur demande ayant des priorités différentes. La séquence de fenêtres temporelles et les règles d'accès peuvent être définies 5 lors de la conception, en fonction par exemple des applications AP exécutées par les coeurs 10 et de l'architecture électronique du calculateur 6, et en particulier de son interconnexion 14 et de ses ressources communes 12. Une séquence peut comprendre par exemple, pour chaque ressource commune 12 ou pour les ressources communes 12 dans leur ensemble, au moins une fenêtre 10 temporelle à accès garanti allouée exclusivement à un seul coeur, au moins une fenêtre temporelle à accès garanti allouée à plusieurs coeurs, au moins une fenêtre temporelle à accès régulé attribuable à un seul coeur à la fois et/ou au moins une fenêtre temporelle à accès régulé attribuable à plusieurs coeurs à la fois. Dans le mode de réalisation de la Figure 3, la séquence de fenêtres temporelles 15 comprend plusieurs phases dans lesquelles les configurations des fenêtres temporelles diffèrent. Plus particulièrement, la séquence de fenêtres temporelles comprend une première phase PH1 comprenant une première série SE1 de fenêtres temporelles cyclique répétée plusieurs fois pendant la première phase PH1, et une deuxième phase 20 PH2 comprenant une deuxième série SE2 de fenêtres temporelles cyclique répétée plusieurs fois pendant la deuxième phase PH2. La première série SE1 et la deuxième série SE2 diffèrent par l'ordre et le nombre de fenêtres temporelles. La première série SE1 comprend ici deux fenêtres temporelles à accès régulé F2 suivies d'une fenêtre temporelle à accès garanti F1. Les fenêtres 25 temporelles de la première série SE1 et de la deuxième série SE2 possèdent la même durée. Dans la variante de la Figure 4, les fenêtres temporelles de la première série SE1 possède une première durée égale pour toutes les fenêtres de la première série SE1, et les fenêtres temporelles de la deuxième série SE2 possèdent une deuxième durée égale 30 pour toutes les fenêtres temporelles de la deuxième série SE2, la première durée étant différente de la deuxième durée. Dans le mode de réalisation illustré sur la Figure 5, la séquence comprend une première phase PH1 au cours de laquelle l'accès aux ressources communes 12 est détermine selon un premier jeu de règles d'accès déterminé pour une premier groupe G1 35 de coeurs 10 et selon un deuxième jeu de règles d'accès pour les coeurs 10 d'un deuxième groupe G2 de coeurs 10 disjoint du premier groupe G1 de coeurs, le règles 3045866 12 d'accès du premier jeu étant indépendantes de celles du deuxième jeu, et une deuxième phase PH2 au cours de laquelle l'accès aux ressources communes 12 est déterminé pour l'ensemble des coeurs 10 selon des règles d'accès communes interdépendantes. Un tel mode de réalisation est possible notamment si du fait de l'architecture 5 électronique et/ou de la configuration des applications AP exécutée par les coeurs 10, il est possible de déterminer que les coeurs 10 du premier groupe G1 et les coeurs du deuxième groupe G2 ne tenteront pas d'accéder aux même ressources communes pendant la première phase PH1. Pour chaque fenêtre temporelle à accès régulé F2, chaque coeur 10 pouvant 10 demander un accès aux ressources communes 12 doit au préalable demander l'accès aux ressources communes 12 et déterminé si la fenêtre temporelle à accès régulé F2 lui est attribuée en fonction des éventuelles demandes des autres coeurs 10 et des règles d'accès. Comme illustré sur la Figure 6, chaque fenêtre temporelle à accès régulé F2 15 comprend une période de notification/réception P1 dans laquelle le contrôleur d'accès 18 de chaque coeur 10 notifie aux contrôleurs d'accès 16 de chaque autre coeur 10 s'il souhaite utiliser la fenêtre temporelle et reçoit les notifications des contrôleurs d'accès 18 des autres coeurs 10, une période de décision P2, dans laquelle le contrôleur d'accès 18 de chaque coeur 10 applique les règles d'accès pour déterminer si la fenêtre temporelle 20 est effectivement allouée à ce coeur 10, et une période utile P3 pendant laquelle chaque coeur 10 autorisé à utiliser la fenêtre temporelle émet des transactions. Avantageusement, le contrôleur d'accès 18 de chaque coeur 10 auquel une fenêtre temporelle à accès garanti est allouée ne met pas en oeuvre la période de notification/réception pour cette fenêtre temporelle. 25 Dans un mode de réalisation, le contrôleur d'accès 18 de chaque coeur 10 est configuré pour contrôler les requêtes de chaque application AP exécutée par chaque coeur 10 comme suit : le contrôleur d'accès 18 intercepte la requête et planifie la transaction (i.e. il détermine comment la transaction sera effectuée) ; 30 le contrôleur d'accès 18 se met en attente active de la prochaine fenêtre temporelle allouée au coeur 10, indépendamment du caractère garanti ou régulé des accès ; lorsque la fenêtre temporelle allouée au coeur 10 est active, le contrôleur d'accès 18 effectue la transaction planifiée ; 3045866 13 le contrôleur d'accès 18 termine la transaction en vérifiant que la transaction s'est correctement déroulé, en option, collecte des statistiques d'usage, puis il prépare la reprise de l'exécution de l'application AP. Pendant l'attente active, le contrôleur d'accès 18 en effectuant la routine suivante : 5 - recherche de la prochaine fenêtre temporelle ; - si la prochaine fenêtre temporelle est une fenêtre temporelle à accès garanti pour ce coeur 10 sans demande nécessaire, exécution de la transaction dans cette fenêtre temporelle ; - si la prochaine fenêtre temporelle est une fenêtre temporelle à accès régulé pour 10 ce coeur 10, et que le contrôleur d'accès 18 a été configuré pour utiliser cette fenêtre temporelle, demande de réservation de la fenêtre temporelle, - si la réservation a réussi, émission de la transaction dans la fenêtre temporelle, - sinon, retour à la recherche de la prochaine fenêtre temporelle. Le fonctionnement des coeurs 10 a été décrit précédemment pour des fenêtres 15 temporelles F1, F2 avec des règles d'accès identiques pour toutes les ressources communes 12. En variante, il est possible de prévoir dans chaque fenêtre temporelle des règles d'accès spécifiques pour chaque ressource commune 12, avec un fonctionnement analogue des coeurs 10 et notamment de leurs contrôleurs d'accès 18. L'accès des coeurs 10 en fonction d'une séquence comprenant des fenêtres 20 temporelles à accès garanti allouées de manière prédéfinie à un ou plusieurs coeur(s) 10 et de fenêtre temporelles à accès régulé attribuables sur demande à un ou plusieurs coeur(s), ces coeurs 10 effectuant ces demandes seulement si nécessaire et/ou seulement durant certaines phases d'exécution, permet de préserver le déterminisme en améliorant l'accès aux ressources communes 12 pour chaque coeur 10 en fonction des 25 besoins de ce coeur 10, aussi appelée « bande passante disponible à la demande ». Par exemple, dans un calculateur conforme au standard ARINC 653, chaque coeur 10 exécute un système d'exploitation en charge d'ordonnancer les applications utiles exécutées par le coeur 10. Les applications utiles sont réparties dans des conteneurs appelés partitions, chaque partition embarquant un ou plusieurs processus. 30 Le système d'exploitation est chargé d'ordonnancer les partitions et les processus au sein des partitions. Il doit garantir un partitionnement spatial et temporel strict entre partitions. Les partitions sont exécutées séquentiellement suivant une séquence périodique de fenêtres temporelles. Le système d'exploitation change régulièrement de partition et effectue 35 successivement les opérations suivantes lors du changement de partition : - la partition sortante est terminée et son contexte est sauvegardé ; 3045866 14 - la mémoire cache est vidée (« flushée ») du contenu appartenant à la partition sortante, - les communications inter-processus et inter-partitions sont effectuées dans des ports prévus à cet effet, par exemple dans une mémoire principale ; et 5 - l'exécution de la partition entrante est préparée. Le changement de partition doit être réalisé dans un temps borné, le plus court possible. Il est donc avantageux d'offrir une garantie élevée sur la bande passante disponible à chaque coeur 10 pendant le changement de partition. Le besoin de bande passante est le plus élevé pour les phases de flush de la mémoire cache et de 10 communication inter-partitions. La bande passante garantie des coeurs 10 est améliorée en décalant les phases de demande de bande passante fortes des coeurs 10, i.e. en décalant en particulier les phases de flush de la mémoire cache et de communication inter-partition des différents coeurs. 15 Grâce au partage des ressources communes proposé, cette bande passante garantie peut être améliorée lors des phases de flush de cache et de communication inter-partitions, où le besoin en bande passante est élevé. Par ailleurs, pour assurer le déterminisme d'un calculateur comprenant un processeur multi-coeurs, il est possible de configurer les applications logicielles AP 20 exécutées par chaque coeur 10 selon un modèle d'exécution dans lequel que chaque application logicielles AP est décomposées en phases d'exécution, lors desquelles le coeur 10 n'effectuera pas de transaction et en phases de communication, lors desquelles le coeur 10 effectuera des transactions, et de configurer un ordonnancement global des applications logicielles AP exécutées par les différents coeurs 10 assurant qu'au plus un 25 coeur 10 est en phase de communication à tout instant. Dans un mode de réalisation possible, chaque tâche à exécuter par une application logicielle AP est découpée en trois phases: acquisition A, exécution E et restitution R. Pendant l'acquisition A, chaque tâche rapatrie localement toutes les données 30 nécessaires au calcul. Pendant la phase d'exécution E, chaque tâche n'est autorisée qu'à accéder à des ressources privées du coeur 10, sans émission de transaction. Pendant la restitution R, chaque tâche fournit les résultats des calculs aux autres tâches pouvant en avoir besoin. Les transactions (et donc les interférences potentielles entre les coeurs 10) sont donc restreintes aux phases d'acquisition A et de restitution R. 35 Ce découpage permet de définir des ordonnancements des tâches au niveau du processeur 8 de telle sorte qu'à un instant donné, une seule phase de communication 3045866 15 (acquisition A ou restitution R) est en cours, conjointement avec une ou plusieurs phases d'exécution. S'il est possible d'obtenir un ordonnancement des tâches qui assure la séparation des phases de communication (acquisition A et restitution R) et d'exécution (exécution E), 5 durant ces tâches, il est possible d'optimiser le taux d'accès aux ressources communes 12 (ou « bande passante ») tout en préservant un partie de cette bande passante pour les coeurs 10 qui exécutent une phase d'exécution. Comme illustré sur la Figure 8, sur laquelle chaque graphique représente le besoin en bande passante d'un coeur 10 respectif au cours du temps, les besoins en bande 10 passante sont plus élevés dans les périodes de communication (acquisition A ou restitution R). Il est possible de prévoir plusieurs coeurs 10, chaque coeur 10 effectuant ses phases de communication en bande passante à la demande, i.e. dans des fenêtres temporelles à accès régulés allouée à ce coeur 10, et des phases d'exécution en bande 15 passante garantie, i.e. dans des fenêtres temporelles à accès garanti allouées à ce coeur 10. Pendant une phase de communication d'un coeur 10, la séquence de fenêtres temporelles comprend plusieurs fenêtres temporelles incluant une ou plusieurs fenêtre(s) temporelle(s) à accès régulé allouée(s) à ce coeur 10. 20 Pendant une phase d'exécution d'un coeur, la séquence de fenêtres temporelles comprend plusieurs fenêtres temporelles incluant une ou plusieurs fenêtre(s) temporelle(s) à accès garanti F1 allouée à ce coeur 10. Pour optimiser la bande passante, les coeurs 10 effectuent des phases de communication qui se chevauchent partiellement dans le temps (ici des phases 25 d'acquisition A). Ceci ne nécessite pas de reconfiguration d'un contrôleur d'accès 18 installé sur les coeurs 10. Grâce à un modèle d'exécution avec découpage des tâches, il est possible d'adapter les applications logicielles existantes pour obtenir des applications logicielles optimisées pour la mise en place d'un contrôle d'accès tel que proposé. 30 Le contrôle de l'accès des coeurs d'un processeur multi-coeurs à des ressources partagées au travers de fenêtres temporelles à allocation statique et de fenêtres temporelles à allocation dynamique permet d'améliorer l'accès des coeurs aux ressources communes. Cela permet de diminuer la latence d'exécution de certaines tâches. Des fenêtres temporelles non utilisées par certains coeurs peuvent être utilisées par d'autres 35 coeurs. De plus, ce contrôle d'accès permet une plus grande souplesse d'allocation de bande passante à certains coeurs, de manière variable au cours du temps. Ce contrôle 3045866 16 d'accès permet de faire migrer des applications vers une structuration de code informatique optimisée pour une exécution sur un processeur multi-coeurs en supportant une relaxation de la contrainte de séparation stricte entre les différentes phases (acquisition, exécution, restitution) en garantissant un trafic minimum pour les accès 5 pouvant intervenir au cours d'une phase d'exécution. REVENDICATIONS1.- Calculateur comprenant un processeur multi-coeurs possédant plusieurs coeurs (10) physiquement distincts et des ressources matérielles communes (12) partagées par les coeurs (10) et accessibles aux coeurs (10) selon une séquence de fenêtres temporelles et en fonction de règles d'accès prédéfinies enregistrées dans au moins une mémoire du calculateur (6) et mises en oeuvre par le calculateur (6) en cours de fonctionnement, selon lesquelles dans chaque fenêtre temporelle, chaque coeur (10) a, pour chaque ressource commune (12), un accès garanti, un accès sur demande ou un accès interdit à la ressource commune (12), la séquence incluant au moins une fenêtre temporelle pendant laquelle au moins un coeur (10) a un accès garanti à au moins une ressource commune (12) et au moins une fenêtre temporelle pendant laquelle plusieurs coeurs (10) ont un accès sur demande à une même ressource commune (12), l'accès à ladite même ressource commune (12) étant attribuable à un ou plusieurs coeurs (10) parmi lesdits plusieurs coeurs (10) ayant un accès sur demande, selon les règles d'accès et en fonction des demandes d'accès émises par lesdits plusieurs coeurs (10). 2.- Calculateur selon la revendication 1, dans lequel la séquence comprend au moins une fenêtre temporelle (F1) pendant laquelle l'accès à une ressource commune (12) ou à chaque ressource commune (12) est réservé exclusivement à un ou plusieurs coeurs (10) ayant un accès garanti à cette ressource commune (12) ou à chaque ressource commune (12). 3.- Calculateur selon la revendication 1 ou 2, dans lequel la séquence comprend au moins une fenêtre temporelle (F1) pendant laquelle l'accès à une ressource commune (12) ou à chaque ressource commune (12) est réservé exclusivement à un seul et unique coeurs (10) ayant un accès garanti à cette ressource commune (12) ou à chaque ressource commune (12). 4.- Calculateur selon l'une quelconque des revendications précédentes, dans lequel la séquence comprend au moins une fenêtre temporelle (F2) pendant laquelle l'accès à une ressource commune (12) ou à chaque ressource commune (12) est attribuable exclusivement à un ou plusieurs coeurs (10) parmi plusieurs coeurs (10) ayant un accès sur demande à cette ressource commune (12) ou à chaque ressource commune (12). 5.- Calculateur selon l'une quelconque des revendications précédentes, dans lequel la séquence comprend au moins une fenêtre temporelle (F2) pendant laquelle l'accès à une ressource commune (12) ou à chaque ressource commune (12) est attribuable exclusivement à un seul et unique coeur (10) parmi plusieurs coeurs (10) ayant 3045866 18 accès sur demande à cette ressource commune (12) ou à chaque ressource commune (12). 6.- Calculateur selon l'une quelconque des revendications précédentes, dans lequel la séquence comprend au moins une fenêtre temporelle pendant laquelle l'accès à 5 des premières ressources communes (12) est attribuable à au moins un coeur (10) d'un premier groupe de coeurs selon un premier jeu de règles d'accès et l'accès des deuxièmes ressources communes (12) distinctes de premières ressources communes (12) est attribuable à au moins un coeur d'un deuxième groupe de coeurs disjoint du premier groupe de coeurs selon un deuxième jeu de règles d'accès indépendantes de 10 celles du premier jeu de règles d'accès. 7.- Calculateur selon l'une quelconque des revendications précédentes, dans lequel la séquence comprend une première phase possédant des fenêtres temporelles ayant une même première durée et une deuxième phase possédant des fenêtres temporelles ayant une même deuxième durée différente de la première durée. 15 8.- Calculateur selon l'une quelconque des revendications précédentes, configuré de sorte que chaque coeur exécute un contrôleur d'accès (18) appliquant les règles d'accès pour déterminer, pour chaque fenêtre temporelle, si ce coeur est à un accès garanti ou un accès sur demande à une ressource commune ou à chaque ressource commune pendant cette fenêtre temporelle. 20 9.- Calculateur selon la revendication 8, dans lequel les contrôleurs d'accès (18) des différents coeurs (10) sont synchronisés à partir d'une horloge de référence commune aux coeurs. 10. Calculateur selon la revendication 9, dans lequel le contrôleur d'accès (18) de chaque coeur (10) est exécuté par le coeur (10) à partir d'une mémoire cache (16) du 25 coeur intégrée physiquement au coeur, sans accéder aux ressources communes (12). 11.- Calculateur selon la revendication 10, dans lequel chaque fenêtre temporelle pendant laquelle plusieurs coeurs (10) ont un accès sur demande à au moins une même ressource commune (12), comprend une période de notification pendant laquelle chaque coeur indique aux autres coeurs s'il souhaite ou non réserver la fenêtre temporelle, une 30 période de décision pendant laquelle chaque coeur détermine s'il est autorisé à accéder aux ressources partagées pendant la fenêtre temporelle, en fonction des demandes émises par les autres coeurs, et une période d'utilisation pendant laquelle chaque coeur autorisé peut accéder aux ressources partagées. 12.- Procédé de contrôle d'un processeur multi-coeurs possédant plusieurs coeurs 35 (10) physiquement distincts ayant accès à des ressources matérielles communes (12) partagées par les coeurs (10) et accessibles aux coeurs (10) selon une séquence de 3045866 19 fenêtres temporelles et en fonction de règles d'accès prédéfinies enregistrées dans au moins une mémoire du calculateur (6) et selon lesquelles, dans chaque fenêtre temporelle, chaque coeur (10) a, pour chaque ressource commune (12), un accès garanti, un accès sur demande ou un accès interdit à la ressource commune (12), la séquence 5 incluant au moins une fenêtre temporelle pendant laquelle au moins un coeur (10) a un accès garanti à au moins une ressource commune (12), et au moins une fenêtre temporelle pendant laquelle plusieurs coeurs (10) ont un accès sur demande à une même ressource commune (12), le procédé comprenant, au cours du fonctionnement du processeur (8), l'attribution de l'accès à ladite même ressource commune (12) à un ou 10 plusieurs coeurs (10) parmi lesdits plusieurs coeurs (10) ayant un accès sur demande, en fonction des demandes d'accès émises par lesdits plusieurs coeurs (10).