FR 2937439 A1 20100423 FR 0805770 A 20081017 Procédé d'exécution déterministe et de synchronisation d'un système de traitement de l'information comportant plusieurs coeurs de traitement exécutant des tâches systèmes La présente invention concerne un système de traitement de l'information comportant au moins deux coeurs de traitement : un coeur de calcul exécutant des tâches systèmes relatives à la commutation des tâches sur le coeur de calcul et un coeur de contrôle exécutant des tâches systèmes relatives au contrôle de l'ordre d'allocation des tâches au coeur de calcul. Elle s'applique notamment dans le domaine de la microélectronique ou dans le domaine des systèmes électroniques embarqués à forte puissance de calcul. L'industrie des semi-conducteurs se trouve devant un constat décevant : il n'y a plus de pistes crédibles pour augmenter de façon significative les performances des processeurs, en tout cas pas au niveau individuel. Seuls les systèmes utilisant plusieurs processeurs fonctionnant en parallèle semblent encore constituer une piste encourageante pour augmenter la puissance de calcul des systèmes. En effet, des études menées dans les années 1960 ont montré que le rapport entre la puissance de calcul et l'efficacité des systèmes de calculs est potentiellement beaucoup plus élevée pour les systèmes parallèles que pour les systèmes séquentiels. La question peut alors se poser de savoir pourquoi les systèmes parallèles ne se sont pas banalisés plus tôt, surtout dans le domaine des systèmes embarqués qui sont par principe très centrés sur l'optimisation et l'efficacité. D'une part, la technologie ne permettait pas l'intégration de structures massivement parallèles sur un même composant, à l'exception des structures SIMD (� Single Instruction, Multiple Data �) facilement programmables lorsque l'application est adaptée à ce type de parallélisme. D'autre part, de façon générale, les systèmes parallèles sont beaucoup plus difficiles à programmer et à mettre au point. C'est notamment le cas des systèmes symétriques, également appelés systèmes homogènes, basés sur la réplication du même coeur de traitement et possédant des interfaces d'accès et de communication identiques et homogènes. C'est cependant moins le cas pour les systèmes asymétriques, également appelés systèmes hétérogènes, qui utilisent plusieurs processeurs spécialisés pour des traitements et des interfaces particulières. Les systèmes asymétriques se sont banalisés depuis longtemps, par exemple pour des périphériques classiques du type des puces réseaux ou vidéo, mais ils restent quand même limités quant au nombre de processeurs mis en parallèle. II faut remarquer que, de manière générale, cette banalisation s'est faite dans des domaines applicatifs peu complexes au niveau du contrôle des traitements, c'est-à-dire dans lesquels l'hétérogénéité des ressources limite non seulement la complexité du placement des traitements mais également la flexibilité du placement des traitements. Toutefois, des systèmes multitraitements spécialisés sont également apparus dans des systèmes embarqués. Dans le domaine de la téléphonie mobile, des � multicores � sur une seule puce sont apparus qui peuvent contenir des DSP (� Digital Signal Processor �) pour le traitement du signal, des GPU (� General Purpose Processing Unit �) pour les traitements ordinaires, ainsi que des blocs analogiques d'entrées/sorties. Dans le domaine des baladeurs ou des lecteurs multimédias, des coeurs de décodage dédiés à l'audio (� MPEG Audio Layer �, � Dolby D �, � DTS �) ou à la vidéo (� MPEG �, � H264 �) sont apparus en plus du processeur généraliste. Les systèmes parallèles symétriques se sont quant à eux moins développés, notamment à cause de la difficulté de prise en main de la programmation et à cause de l'inextricabilité de la mise au point des programmes. De manière générale, ces difficultés de programmation et de mise au point sont exacerbées par la complexité toujours croissante des applications. Dans les systèmes embarqués, ces difficultés sont également exacerbées par la volonté d'intégrer toujours plus de fonctionnalités et par l'accroissement permanent des volumes de données à traiter. Par exemple, les téléphones mobiles associent des fonctions de télécommunication avec des fonctions multimédias, de positionnement, ou encore des jeux. Les téléphones mobiles utilisent des capteurs vidéos de capacité toujours plus grande et des convertisseurs à débit toujours plus élevé. Par ailleurs des tâches de calculs intensifs côtoient des tâches dominées par le contrôle, avec des interactions très fortes entre ces différents éléments des applications. Les nouvelles applications dans les domaines tels que le multimédia, la communication, ou les systèmes de traitement temps réels exigent de plus en plus de puissance de calcul pour des puissances consommées et des surfaces maîtrisées. Comme déjà explicité précédemment, faute de pouvoir augmenter les puissances de traitement des coeurs de calcul de façon isolée, la seule solution réaliste est de multiplier les coeurs de calculs et de les faire fonctionner en parallèle. Dans ce cadre, un concept nouveau est en train de faire son apparition, celui de système parallèle sur puce. Les systèmes parallèles sur puce permettent en théorie d'utiliser de façon plus efficace les transistors supplémentaires intégrables sur une même puce du fait des progrès effectués dans les techniques de gravures. Même dans le cadre assez spécialisé des processeurs pour les systèmes embarqués, cette tendance à l'augmentation du nombre de coeurs d'exécution sur une même puce est très marquée. Cette tendance devrait marquer à moyen terme l'introduction voire la banalisation des systèmes avec plusieurs dizaines voire centaines de coeurs d'exécution. Parmi ces systèmes peuvent être cités les systèmes multiprocesseurs sur puce, usuellement désignés par l'acronyme anglo-saxon � MPSoC � signifiant � Multi-Processsor System on Chip �. Les MPSoC sont des systèmes complets qui intègrent au minimum des coeurs de calcul pouvant fonctionner en parallèle et une architecture complète de communication sur puce. L'architecture de communication des MPSoC actuels reproduit une architecture système de connexion d'un système composé de plusieurs éléments macroscopiques. Elle peut comporter des bus de communication, des réseaux dédiés sur puce, usuellement désignés par l'acronyme anglo-saxon � NoC � signifiant � Network on Chip �, des systèmes de commutation d'interconnexions dédiés, usuellement désignés par l'expression anglo-saxonne � crossbars �, des interfaces d'entrées/sorties, de la mémoire vive, usuellement désignées par l'acronyme anglo-saxon � RAM �, des mémoires locales, des mémoires caches ou � scratchpad �. Mais la plupart du temps, l'architecture de communication d'un MPSoC comporte une combinaison de tout cela. Le problème essentiel du mimétisme des architectures de communication sur puce vis-à-vis des architectures macroscopiques, c'est que les architectures macroscopiques sont prévues pour des traitements très réguliers, que ce soit des traitements de calculs massivement parallèles, des traitements de flux ou des tâches de serveur. Or, les applications sur les systèmes embarqués tendent de plus en plus vers des traitements beaucoup moins réguliers et beaucoup moins prédictibles. L'architecture de communication des MPSoC doit donc être repensée. En effet, la mise en oeuvre de systèmes parallèles sur puce efficaces et à haut niveau de performance comme les MPSoC nécessite de faire fonctionner de concert des dizaines voire des centaines de coeurs de traitement. Si ce n'est pas le cas, alors l'utilisation du parallélisme n'est pas optimale. Ceci signifie que plusieurs dizaines voire plusieurs centaines de coeurs de traitement ne sont pas utilisés correctement, c'est-à-dire qu'ils ont un taux d'utilisation pas assez élevé. Mais pour exploiter de manière optimale le parallélisme, les difficultés sont multiples. Au niveau logiciel, une difficulté est de fournir au programmeur des outils simples et accessibles pour exprimer dans du code l'ensemble du parallélisme potentiel d'une application. Une autre difficulté au niveau logiciel est de pouvoir en tirer le meilleur profit à la compilation de ce code. Pour exploiter efficacement une architecture parallèle, il faut aborder le problème sous le triple aspect de la maîtrise de l'indéterminisme, de la maîtrise des communications et de la maîtrise des contrôles. Car une fois qu'un parallélisme potentiel a été extrait d'une application et exprimé dans un programme, encore faut-il être capable de mettre en oeuvre effectivement ce parallélisme dans une architecture matérielle donnée. Dans un MPSoC par exemple, afin de tirer le meilleur profit du travail d'extraction du parallélisme applicatif fait par le programmeur, il faut réussir à répartir sur l'ensemble des ressources de la puce de nombreuses séquences de traitements, ces séquences étant liées entre elles par des dépendances de données ou de contrôle d'exécution. Par la suite ces séquences seront appellées tâches d'exécution. Une tâche d'exécution concerne donc l'exécution d'un traitement sur un coeur de traitement. Elle est généralement appelée � thread � ou � fil d'exécution � par les spécialistes du logiciel. Par défaut dans le reste de la présente demande, le terme � tâche � seul fait référence à une tâche d'exécution. En l'absence d'une réflexion portant d'une part sur la façon de choisir les coeurs de traitement et d'autre part sur la façon de les faire fonctionner ensemble, il est fort peu probable que l'architecture puisse effectivement mettre en oeuvre tout le parallélisme exprimé dans le programme. En quelque sorte, de la même manière que le programme exprime le potentiel de parallélisme de l'application, il faut trouver un moyen d'exprimer le potentiel de parallélisme de l'architecture par un contrôle approprié des tâches. La réflexion doit prendre en compte toutes les situations qui peuvent nuire à une bonne utilisation du parallélisme potentiel de l'architecture. II s'agit d'abord des risques d'être limité par l'accès à une ressource partagée essentielle comme la mémoire centrale, un réseau, un bus de communication ou un gestionnaire de tâches. Il s'agit également des risques de ne pas pouvoir gérer de façon suffisamment fine les interdépendances entre les tâches, ou de ne pas pouvoir les gérer sans adaptation au caractère particulièrement dynamique de certaines applications. Il s'agit enfin des risques de ne pas pouvoir maîtriser les indéterminismes de l'exécution parallèle, rendant complexe et délicate la mise au point des programmes. La réflexion doit aboutir à un modèle d'exécution, qui définit la façon de choisir les coeurs de traitement et la façon de les faire fonctionner ensemble. Mis en oeuvre par le logiciel système ou système d'exploitation, qui sera appelé � noyau � par la suite, ce modèle d'exécution doit permettre de faire fonctionner ensemble et de manière efficace plusieurs dizaines voire plusieurs centaines de coeurs de traitement au sein d'une seule et même puce. Il s'agit là de l'un des défis majeurs auquel l'industrie microélectronique ait à faire face actuellement et auquel la présente invention se propose d'apporter une solution. Une solution existante propose d'utiliser les coeurs de traitement de manière symétrique pour exécuter le noyau. Elle est mise en oeuvre dans les architectures de type � Symmetric MultiProcessing � (SMP). Par exemple, il peut s'agir d'avoir un noyau identique du type Linux ou Windows (Marque Déposée) exécuté sur deux coeurs de traitement distincts. Cependant, un inconvénient majeur est qu'un noyau du type Linux ou Windows (Marque Déposée) ne peut pas s'exécuter sur deux coeurs distincts de manière réellement simultanée, au moins en ce qui concerne les fonctions critiques du noyau. Le parallélisme est donc limité aux fonctions non critiques du noyau. II s'agit là de l'un des problèmes techniques que la présente invention se propose de résoudre en répartissant une partie des fonctions critiques du noyau sur plusieurs coeurs de traitement. Il existe également des solutions dites de � partition �, qui proposent que chaque coeur de traitement soit dédié à des activités qui s'ignorent mutuellement. Des échanges ne peuvent avoir lieu que par le partage d'un espace mémoire. Par exemple, la demande de brevet No WO/2007/038011 de titre � REAL-TIME THREADING SERVICE FOR PARTITIONED MULTIPROCESSOR SYSTEMS� décrit comment un coeur temps-réel peut être dédié à l'exécution de tâches temps-réel pour une application exécutée grâce à un noyau non temps-réel exécuté sur un autre coeur. De même, il existe des architectures matérielles bi-coeurs, comme par exemple l'architecture Freescale S12XE (Marque Déposée), dont l'un des coeurs est dédié aux prises d'interruption d'entrées/sorties et l'autre coeur est dédié au calcul. Ce dernier inclut le noyau permettant d'effectuer les calculs sur des données asynchrones provenant des entrées/sorties mises à disposition par le coeur de prise d'interruption. Une interruption correspond à l'occurrence d'un événement externe au programme, ledit évènement déclenchant l'arrêt temporaire de l'exécution d'une tâche en cours afin d'exécuter une autre tâche plus prioritaire (ce changement de contexte d'exécution est appelé commutation). L'événement externe peut être l'avancement d'une horloge réelle ou simulée, la tâche plus prioritaire pouvant être déclenchée par un temporisateur. C'est notamment le cas des tâches temps-réel qui sont contraintes dans le temps ou � Time Triggered � (TT) : dans la mesure où une tâche temps réel doit être terminée avant une date donnée, elles doit aussi être commencée avant une date donnée qui dépend de la durée d'exécution de la tâche. Les tâches temps réel sont déclenchées par un temporisateur physiquement cadencé par un quartz, formant ainsi une horloge réelle. L'événement externe peut également être la complétion d'un transfert de données, la tâche plus prioritaire est alors dite � Event Triggered � (ET) sous interruption d'entrées-sorties. Dans ce type de conception relativement classique, le coeur de prise d'interruption et le coeur de calcul sont faiblement couplés. Ce type de solution se rapproche alors des architectures avec co-processeurs. Un avantage de cette solution est d'offrir une bonne réactivité aux entrées/sorties rapides, c'est-à-dire qu'elle permet de faire les calculs élémentaires associés sans pour autant perturber l'ordonnancement des traitements sur le coeur de calcul. Elle est efficace lorsque les tâches à exécuter sont indépendantes les unes des autres, c'est-à-dire lorsqu'elles nécessitent peu ou pas d'échanges et/ou de synchronisations. Cependant, lorsque les entrées/sorties nécessitent des synchronisations fortes avec les calculs ou lorsqu'il existe de nombreuses entrées/sorties avec des rythmes différents, ce type de solution est peu efficace. II s'agit là encore de l'un des problèmes techniques que la présente invention se propose de résoudre. Une autre solution existante propose d'utiliser les coeurs de traitement de manière asymétrique pour exécuter le noyau. Elle est mise en oeuvre par exemple dans les architectures de type � maître/esclaves �, où le noyau est exécuté sur un seul processeur dit � processeur maître �. Ainsi, celui-ci prend complètement en charge et synchronise le contrôle et l'allocation aux traitements à réaliser des autres processeurs dits � processeurs esclaves �. La demande de brevet américain No US005978838A de titre � Coordination and synchronization of an asymmetric, single-chip, dual multiprocessor � divulgue une telle solution. Mais ce type d'architecture peut être amélioré grâce à une organisation hiérarchique des processeurs, comme divulgué dans la demande internationale de brevet No WO/2008/021024 de titre � MULTIPROCESSOR ARCHITECTURE WITH HIERARCHICAL PROCESSOR ORGANIZATION �. Cependant, si le processeur maître est bloqué pour une raison ou pour une autre, tous les processeurs esclaves se retrouvent bloqués également, et réciproquement. Une telle solution apparaît donc beaucoup trop centralisée. Il s'agit là encore de l'un des problèmes techniques que la présente invention se propose de résoudre. L'invention a notamment pour but de pallier les inconvénients précités, en proposant un système à micro-noyau avec une répartition optimum sur les coeurs de traitement des fonctions systèmes, en particulier une répartition optimum des fonctions de cadencement et de gestion du temps. Ainsi, l'invention propose de partionner les fonctions de bas-niveau du noyau et de les répartir sur les différents coeurs de traitement, de telle sorte qu'un coeur soit dédié aux prises d'interruption et qu'il se comporte comme un coeur de contrôle partiel du ou des coeurs de calcul. Une idée directrice à l'origine de l'invention est de mettre en oeuvre une stratégie par événements très réactive pour les entrées/sorties rapides sur le processeur dédié aux prises d'interruption et de l'utiliser aussi pour contrôler le système de cadencement qui régit les processeurs de calcul, de manière à décharger ces derniers des traitements des entrées/sorties rapides et de certains traitements de bas-niveau liés à l'ordonnancement des tâches. A cet effet, l'invention a pour objet un système de traitement de l'information comportant au moins deux coeurs de traitement, un coeur de calcul exécutant des tâches systèmes relatives à la commutation des tâches sur le coeur de calcul et un coeur de contrôle exécutant des tâches systèmes relatives au contrôle de l'ordre d'allocation des tâches au coeur de calcul. Avantageusement, le coeur de contrôle peut exécuter des tâches applicatives déclenchées par des interruptions d'entrées/sorties. Dans un mode de réalisation préférentiel, les tâches systèmes exécutées par le coeur de calcul relatives à la commutation des tâches peuvent inclure la mise à jour pour chaque tâche d'un état indiquant si ladite tâche est exécutable ou pas, l'état pouvant par exemple prendre une valeur indiquant que la tâche est prête, une valeur indiquant que la tâche est au repos ou une valeur indiquant que la tâche est en erreur. Dans un mode de réalisation préférentiel, les tâches systèmes exécutées par le coeur de contrôle relatives au contrôle de l'ordre d'allocation des tâches au coeur de calcul peuvent inclure la gestion d'une liste ordonnée des tâches prêtes, d'une liste ordonnée des tâches au repos ou encore d'une liste des tâches en erreur. Avantageusement, chaque tâche peut être associée à un contexte d'exécution regroupant les données d'exécution de ladite tâche, incluant l'état indiquant si elle est exécutable. Les tâches systèmes exécutées par le coeur de calcul relatives à la commutation des tâches peuvent alors inclure par exemple, sur réception d'une interruption par le coeur de calcul, le chargement du contexte d'exécution d'une tâche parmi les tâches prêtes ou encore le déclenchement de l'exécution de ladite tâche. Par exemple, le coeur de calcul peut charger le contexte d'exécution de la première tâche dans la liste des tâches prêtes. Dans un mode de réalisation préférentiel, les tâches systèmes exécutées par le coeur de calcul relatives à la commutation des tâches peuvent inclure la mise à jour, dans le contexte d'exécution de chaque tâche, d'une date de début d'exécution au plus tôt, d'une date de fin d'exécution au plus tard ou encore d'un quota de temps d'exécution restant, de sorte que le coeur de contrôle peut ordonner les tâches dans la liste des tâches prêtes dans un ordre qui permet d'exécuter chaque tâche dans le respect de ses dates limites d'exécution et dans le respect de son quota de temps d'exécution. Avantageusement, l'interruption peut être générée par un temporisateur implémenté par le coeur de contrôle. Cadencé par une horloge à quartz, il peut alors avantageusement déclencher l'exécution par le coeur de calcul de tâches applicatives temps-réel. Le coeur de calcul peut également exécuter les tâches systèmes relatives aux communications entre les tâches, un espace mémoire pouvant par exemple être partagé par le coeur de contrôle et le coeur de calcul. Par exemple, le coeur de contrôle et le coeur de calcul peuvent être des processeurs de types différents implantés sur une même puce, de sorte à former un système asymétrique multi-coeur sur puce. L'invention a encore pour principaux avantages que la partition du noyau permet de soulager le coeur de calcul de la prise en compte de traitements sous interruption d'entrées-sorties rapides, évitant ainsi des changements de contexte fréquents entre les tâches de calculs et les traitements sous interruption. Mise en oeuvre sur une puce, les performances atteignables sont accrues tout en garantissait un haut niveau de sécurité entre les différents traitements d'acquisitions ou de calculs sur l'architecture matérielle mufti-coeur. Cela permet de plus au sein d'un même multi-coeur sur puce de faire coexister des traitements de calculs cadencés par le temps et des routines associées aux entrées-sorties cadencées par les événements. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent : la figure 1, par un chronogramme diagramme, une illustration d'un exemple de répartition selon l'invention des activités d'un micro-noyau sur deux coeurs de traitement ; - la figure 2, par un diagramme de blocs fontionnels, une illustration d'un exemple selon l'invention d'interruptions à destination d'un coeur de contrôle ; la figure 3, par un diagramme de blocs fontionnels, une illustration d'un exemple selon l'invention d'interruption logicielle venant du coeur de contrôle à destination du coeur de calcul ; - la figure 4, par un diagramme de blocs fontionnels, une illustration d'un exemple selon l'invention d'interruption d'entrées/sorties à destination du coeur de contrôle ; la figure 5, par un diagramme de blocs fontionnels, une illustration d'un exemple selon l'invention d'interruption logicielle du coeur de calcul à destination du coeur de calcul ; - la figure 6, par un chronogramme, une illustration d'un exemple de scénario de fonctionnement de deux coeurs en parallèle selon l'invention. La présente demande décrit un système de traitement de l'information qui permet d'exécuter efficacement, c'est-à-dire de manière sécurisée et déterministe, plusieurs tâches cadencées par le temps ainsi que des traitements spécifiques liés à des entrées/sorties rapides. Dans le présent exemple de réalisation, le système comporte par exemple un coeur de calcul de type CISC orienté calculs algorithmiques et un coeur de contrôle de type RISC orienté prise d'interruptions et traitements simples, implantés sur une même puce. Mais sans déroger aux principes de l'invention, il pourrait comporter plus de deux coeurs, qu'ils soient identiques ou pas, implantés sur plusieurs puces distinctes. L'invention s'appuie sur une répartition efficace des différentes fonctions de bas-niveau du noyau sur le coeur de calcul et le coeur de contrôle. Pour définir cette répartition efficace selon l'invention, deux types d'activités ont été distingués au sein du noyau : • un îlot ET (� Event Triggered �) qui regroupe les activités déclenchées par des interruptions d'entrées-sorties et où sont donc exécutées les tâches sous interruption d'entrées-sorties ; • un îlot TT (� Time Triggered �) qui regroupe les activités cadencées par le temps et où sont exécutées les tâches temps-réel. Pour définir cette répartition efficace selon l'invention, ont également été distinguées deux parties distinctes au sein du noyau dans le présent ~o exemple de réalisation : • une couche système qui peut être une couche générique de gestion du cadencement par un temporisateur et des communications entre les tâches : elle contient alors la description du cadencement par le temporisateur de l'exécution des tâches, elle peut permettre en outre de 15 mettre en oeuvre les communications entre les tâches ; • un micro-noyau qui est une couche gérant l'allocation de la ressource de traitement, la gestion des exceptions et la datation temps-réel. Par exemple, le temporisateur peut être cadencé par une horloge à quartz, de manière à déclencher l'exécution par le coeur de calcul de tâches temps- 20 réel. Le coeur de calcul est dédié à l'exécution des tâches temps-réel de l'îlot TT, mais il implémente également les fonctions du micro-noyau relatives à la commutation et à la mise à jour de contexte des tâches. Le coeur de contrôle est dédié à l'exécution des traitements sous interruption de l'îlot ET, mais il implémente également les fonctions du micro-noyau relatives au contrôle de 25 l'ordre d'allocation des traitements au coeur de calcul. Le coeur de contrôle déclenche également dans le coeur de calcul des fonctions du micro-noyau relatives à la surveillance des temps d'allocation. Il s'agit là de l'un des principes essentiels de l'invention, à savoir l'utilisation du coeur de contrôle pour déterminer et surveiller la manière avec laquelle le coeur de calcul est 30 utilisé par les tâches temps-réel d'une application. L'invention permet de gagner en performance, en soulageant le coeur de calcul des activités systèmes liées à la mise à jour des listes de tâches (tâches prêtes, tâches au repos et tâches en erreur) dans le présent exemple de réalisation, ainsi qu'en le soulageant des activités systèmes liées au choix d'allocation du coeur de 35 calcul parmi les tâches prêtes. L'invention permet en fait de répartir sur les deux coeurs les activités systèmes qui mettent en oeuvre l'allocation des tâches. Dans le présent exemple de réalisation, la partie du micro-noyau sur le coeur de calcul est chargée de la gestion des commutations de tâches sur le coeur de calcul. Il peut notamment s'agir de mettre à jour le contenu des contextes d'exécution des tâches, par exemple en termes de temps d'exécution effectif et de quota restant (un quota est un majorant de temps d'exécution reservé pour l'exécution de la tâche en question). Il peut également s'agir de déclencher l'exécution des tâches sur interruption du temporisateur, par exemple grâce à des dates de début au plus tôt et à des échéances connues à la compilation. Lorsqu'une telle tâche arrive à la fin de son traitement applicatif, elle passe la main au micro-noyau sur le coeur de calcul grâce à une interruption dite � logicielle �, soit pour repousser son échéance au plus tard soit pour ajuster sa prochaine date de réveil. Avantageusement, la partie du noyau sur le coeur de calcul peut également être chargée de la gestion des communications entre les tâches. Dans le présent exemple de réalisation, la partie du micronoyau sur le coeur de contrôle est avantageusement chargée d'ordonner des listes de tâches : une liste des tâches prêtes, une liste des tâches au repos et une liste des tâches en erreur. Ainsi, la partie du micronoyau sur le coeur de calcul peut avantageusement accorder son CPU (� Central Processing Unit �) dans l'ordre des tâches dans la liste des tâches prêtes, et calculer le temps d'exécution effectif de chaque tâche. La partie du micro-noyau sur le coeur de contrôle peut également être chargée d'entretenir l'heure courante, utile au système de cadencement par le temporisateur pour le réveil des tâches. Elle peut également activer les contrôles de temps d'exécution effectifs sur le coeur de calcul. Elle peut aussi déclencher l'exécution des tâches sous interruptions d'entrées-sorties et horodater leurs résultats pour les mettre à la disposition des tâches applicatives du coeur de calcul. La figure 1 illustre un exemple de répartition selon l'invention des activités d'un micro-noyau (� pNoyau �) sur un coeur de contrôle et un coeur de calcul, lors de l'exécution de tâches applicatives Al et A2. Comme illustré par la figure 1, l'exécution du micro-noyau peut être déclenchée sur occurrence d'une interruption (� IT �) venant du temporisateur (� IT temporisateur �), ce qui correspond au réveil de la tâche. L'exécution du micro-noyau peut également être déclenchée sur occurrence d'une interruption logicielle (� IT logicielle �). Elle peut enfin être déclenchée sur occurrence d'une interruption liée à une entrée-sortie rapide (� IT d'E/S �). Comme l'exécution du micro-noyau est répartie sur les deux coeurs, les entrées dans le micro-noyau suite à des interruptions du temporisateur et suite à des interruptions d'entrées-sorties peuvent se faire directement sur le coeur de contrôle. Comme détaillé par la suite, les entrées dans le micro-noyau suite à des interruptions se répartissent entre le coeur de calcul où les tâches sont exécutées et le coeur de contrôle. Un intérêt majeur de la partition du noyau selon l'invention est qu'elle permet au coeur de calcul d'anticiper l'exécution d'une tâche. En effet, lorsqu'une première tâche a terminé son traitement avant l'occurrence de l'interruption temporisateur, cela signifie que le temps prévu mais non consommé est disponible pour d'autres tâches prêtes dans le respect de leurs paramètres temporels. Cela revient alors à consommer tout le temps de traitement restant qui était affecté à la première tâche en exécutant d'autres tâches prêtes. Il faut noter que dans le présent exemple de réalisation, une tâche est toujours bien exécutée entre ses deux bornes temporelles et dans le respect de son quota de temps. Dans le présent exemple de réalisation, le coeur de contrôle s'exécutant de manière asynchrone sur occurrence d'interruptions du temporisateur, une entrée supplémentaire dans le micro-noyau sur le coeur de calcul permet avantageusement de signaler un changement dans les listes de tâches à prendre en compte ou un contrôle de quota à effectuer. De manière corrélée, le contrôle du temps d'exécution effectif grâce au quota étant alors délégué pour partie au coeur de calcul, il est nécessaire d'avoir une entrée supplémentaire associée dans le micro-noyau sur le coeur de contrôle, déclenchée par une interruption en provenance du coeur de calcul, pour lui signaler le résultat du contrôle du temps d'exécution effectif. Dans un autre mode de réalisation, afin d'éviter de gérer des écarts entre les mesures de quota sur le coeur de calcul et sur le coeur de contrôle, les interruptions pour contrôle de quota peuvent être complètement gérées par le coeur de calcul. En suivant les principes énoncés ci-dessus, il y a plusieurs façons de coordonner les deux coeurs relativement aux activités de contrôle du temps d'exécution effectif. Une première méthode consiste à mettre en place un unique aller-retour d'interruption entre les deux coeurs : une interruption du coeur de contrôle vers le coeur de calcul, comme la prise en compte de changements dans la liste des tâches par exemple, et ensuite une seconde interruption du coeur de calcul vers le coeur de contrôle lorsque le contrôle est réalisé. Une deuxième méthode sans aller-retour peut être définie, mais elle provoque potentiellement plus d'interruptions du coeur de calcul vers celui de contrôle : à chaque fin de tâche, une interruption peut être systématiquement déclenchée du coeur de calcul vers le coeur de contrôle avant que le coeur de calcul ne continue à exécuter les tâches suivantes de calcul. C'est la première méthode de coordination qui a été retenue dans la description détaillée qui suit. Dans le présent exemple de réalisation, une variable d'état du micro-noyau appelée natlnt est donc systématiquement positionnée à la sortie de toute routine du micro-noyau sur le coeur de contrôle, afin de connaître la nature de la prochaine interruption attendue. Elle est propre au coeur de contrôle. Par exemple, lorsque natlnt vaut 0, cela signifie que l'interruption attendue est celle du coeur de calcul. Les traitements associés sur le coeur de contrôle peuvent avantageusement comprendre la mise à jour de la liste des tâches prêtes, des tâches au repos et des tâches en erreur, ainsi que l'armement de la prochaine interruption du temporisateur. Par exemple, lorsque natlnt vaut 1, cela signifie que l'interruption attendue est une interruption du temporisateur pour le contrôle du temps d'exécution effectif de la tâche activée. Les traitements associés sur le coeur de contrôle comprennent le déclenchement d'une interruption sur le coeur de calcul pour contrôle effectif. Par exemple, lorsque natlnt vaut 2, cela signifie que l'interruption attendue est une interruption du temporisateur pour le réveil d'une tâche au repos. Les traitements associés sur le coeur de contrôle peuvent avantageusement comprendre la mise à jour de la liste des tâches prêtes, des tâches au repos et des tâches en erreur, le déclenchement d'une interruption sur le coeur de calcul, ainsi que l'armement de la prochaine interruption du temporisateur. Dans le présent exemple de réalisation, une variable d'état du micro-noyau appelée natAlert est donc positionnée avant tout déclenchement d'une interruption depuis le coeur de contrôle vers le coeur de calcul. Elle est mise à jour par le coeur de contrôle et consultée par le coeur de calcul. Par exemple, lorsque natAlert vaut 0, cela signifie que l'interruption du coeur de contrôle correspond à un réveil de tâche. Les traitements associés sur le coeur de calcul comprennent la prise en compte des nouvelles listes. Par exemple, lorsque natAlert vaut 1, cela signifie que l'interruption du coeur de contrôle correspond à un contrôle du temps d'exécution effectif. Avantageusement, les traitements associés sur le coeur de calcul peuvent comprendre le contrôle des temps d'exécution effectifs de toutes les tâches qui ont été activées, puis le positionnement de l'état de chaque tâche, puis le déclenchement de l'interruption du coeur de calcul vers le coeur de contrôle. La figure 1 fait bien apparaître les traitements en parallèle effectués par le coeur de contrôle et le coeur de calcul. La figure 2 illustre un exemple selon l'invention d'une interruption venant du temporisateur, traitée par le coeur de contrôle. Cette interruption peut avantageusement être implémentée par le coeur de contrôle lui-même, comme illustré par un bloc 20, à chacune des terminaisons de la routine associée. Elle permet donc de surveiller l'évolution temporelle des traitements sur le coeur de calcul, comme illustré par un bloc 21. L'interruption du temporisateur correspond alors soit au réveil par le temporisateur d'une tâche (� réveil TT �), soit au contrôle du respect des contraintes temporelles de la tâche activée, en termes de quota ou d'échéance par exemple. Les dates de réveil ou les contraintes temporelles, en termes de d'échéance ou de quota, s'expriment comme des dates du système de cadencement par le temporisateur. Elles peuvent être codées sur un certain nombre de bits, par exemple sur 32 bits. Dans le cas où le temporisateur ne permet pas l'expression directe d'une contrainte temporelle, c'est-à-dire lorsque la prochaine interruption à armer, comme illustré par un bloc 24, correspond à une contrainte temporelle dont la valeur est plus grande que la capacité du temporisateur, le micro-noyau peut alors avoir à sa charge la gestion de la transcription des dates du système de cadencement par le temporisateur dans la base de temps du temporisateur. Dans ce cas, le micro-noyau gère des interruptions intermédiaires, comme illustré par un bloc 23, pour décompter le temps avant l'occurrence de la dernière interruption, qui correspond à l'interruption finale de la contrainte temporelle considérée. L'interruption finale conduit au traitement de mise à jour de la liste des tâches prêtes et de la liste des tâches au repos, puis au déclenchement d'une interruption sur le coeur de calcul, comme illustré par un bloc 22, afin de lui faire prendre en compte l'événement temporel pour lequel s'est activé le micro-noyau, suivant la valeur de natlnt (1 ou 2). Le coeur de contrôle étant le gestionnaire de l'interruption du temporisateur dans le présent exemple de réalisation, il est alors en charge de l'ordonnancement et du contrôle de l'allocation du coeur de calcul aux tâches. Ainsi, lorsque la liste des contextes prêts est mise à jour ou quand une interruption de contrôle de quota est produite, il interrompt le coeur de calcul à l'aide d'une interruption logicielle du coeur de contrôle vers le coeur de calcul et lui indique la nature de son intervention, grâce à natAlert. Le coeur de calcul peut alors avantageusement effectuer la mise à jour et le contrôle du quota de la tâche active, puis éventuellement entreprendre la commutation de contexte en prenant connaissance de la nouvelle tâche prête et en chargeant son contexte d'exécution, comme illustré par un bloc 33 sur la figure 3. Puis, lorsque l'interruption de fin de contrôle de quota est traité par le coeur de contrôle, comme illustré par un bloc 25, la prochaine interruption liée au cadencement est armée (bloc 24) Dans la figure 2 et les suivantes, l'acronyme anglo-saxon � RTI � représente l'instruction de retour d'interruption (� ReTurn from Interrupt �). Comme illustré par des blocs 30 et 31 dans la figure 3, dans le présent exemple de réalisation, lorsqu'il s'agit d'une demande de contrôle du quota, le coeur de contrôle attend le résultat de l'analyse du quota de la part du coeur de calcul. Le coeur de calcul lui annonce alors la fin de ce traitement en déclenchant à son tour une interruption à l'attention du coeur de contrôle, comme illustré par un bloc 32. A partir de là, comme illustré dans la figure 2 par le bloc 25 et le bloc 24, le coeur de contrôle peut alors activer à nouveau la prochaine interruption du temporisateur. Que ce soit pour un contrôle de quota ou un réveil par le temporisateur (changement dans les listes de tâches prêtes, au repos ou en erreur), le coeur de calcul prend connaissance de la nouvelle tâche prête et charge son contexte d'exécution (bloc 33). Comme illustré par la figure 4, le coeur de contrôle peut avantageusement implémenter le gestionnaire des interruptions d'entrées/sorties. Il peut alors avoir en charge l'activation d'une routine associée à l'interruption d'entrées/sorties. Cette routine peut comporter une partie initiale générique de contrôle d'occurrence de l'interruption, comme illustré par un bloc 40, et une partie de traitement applicatif spécifique incluant la possibilité de signaler que le résultat qui a été élaboré et qui est lié à cette entrée/sortie peut être mis par le noyau à disposition des tâches sur le coeur de calcul, comme illustré par un bloc 41. Par exemple, il peut avantageusement être mis dans une zone mémoire partagée entre les deux coeurs par exemple. La stratégie de contrôle d'occurrence d'interruption dépend du domaine industriel visé et du type de surveillance à mettre en place. Cette stratégie peut par exemple exploiter un nombre maximum autorisé d'interruptions d'entrées/sorties ou un temps minimum ou maximum autorisé entre deux interruptions d'entrées/sorties. En cas de non respect de l'un de ces critères, le contrôle doit aussi préciser la stratégie de gestion de � défaillance � associée. Cette stratégie peut elle aussi être de différentes natures, pouvant aller de la remise à zéro du module de gestion de cette entrée/sortie jusqu'à l'inhibition temporaire ou définitive de son fonctionnement. La mise à disposition par le noyau des données élaborées se fait dans le traitement applicatif par l'appel à une fonction système. Cette fonction a pour rôle de dater le résultat et d'associer à cet ensemble un indice signalant sa position dans un tampon à disposition du noyau du côté du coeur de calcul. Le tampon est dimensionné en fonction des occurrences d'interruptions d'entrées/sorties attendues et de l'exploitation de ces données par la tâche temps-réel applicative associée. Il est à noter que la datation du résultat élaboré par le noyau doit être atomique par rapport à l'entretien de l'heure courante par l'intermédiaire de l'interruption du temporisateur. Suivant la nature du processeur utilisé comme coeur de contrôle, ceci peut être garanti par l'atomicité matérielle d'une instruction manipulant un mot du processeur, lorsque ce mot contient l'heure courante. Si ce n'est pas possible, ceci peut être garanti par le masquage des interruptions pendant la mise à jour de l'heure courante par le micro-noyau. L'accès par le coeur de calcul au résultat daté peut quant à lui être directement garanti par l'atomicité matérielle d'une instruction manipulant un mot du processeur du coeur de contrôle. Côté coeur de calcul, la cohérence de la lecture est vérifiée par une programmation défensive sur la taille du tampon par l'intermédiaire de l'indice accédé, de la date du résultat et de l'heure courante. Comme illustré par la figure 5, une interruption logicielle en provenance d'une tâche est déclenchée pour signaler un appel système, par exemple l'arrivée à destination d'un noeud du graphe d'exécution. Dans le présent exemple de réalisation, le coeur de calcul peut alors opérer les modifications de contexte d'exécution, comme illustré par un bloc 50, pour permettre l'exécution de la couche système de la tâche appelante, comme illustré par un bloc 51. Au cours de son traitement, la couche système peut être amenée à modifier les contraintes temporelles de la tâche en conformité avec son graphe d'exécution. Cette opération amène alors la couche système à entreprendre une gestion du quota consommé, comme illustré par un bloc 52, puis peut amener, si nécessaire, le micro-noyau à effectuer une commutation de tâches sur le coeur de calcul, comme illustré par un bloc 53. Une fonction peut positionner une variable d'état dans la zone de communication ainsi qu'un indicateur associé à l'entrée d'origine, puis transférer les arguments et les dates de prise et de libération du coeur de calcul dans le contexte de la tâche qui était en cours d'exécution. Ensuite, il peut y avoir appel au module de commutation pour activer la tâche prête suivante. L'évaluation du quota de CPU consommé est faite par calcul de la différence entre l'heure à laquelle la tâche abandonne le CPU, ou l'heure à laquelle on le lui retire, et l'heure à laquelle il lui a été donné. Le calcul est fait par le coeur de contrôle à partir des informations fournies par le coeur de calcul. En effet, lors de la préemption d'une tâche n'entrainant pas de changement d'état de ladite tâche, qui reste donc activable, l'information de quota consommé associée et contenue dans le contexte de la tâche peut avantageusement être mise à jour par le coeur de calcul. Afin de se synchroniser, le coeur de calcul et le coeur de contrôle partagent des données comme celles définies par exemple dans le tableau 1 qui suit. Cependant, il n'y a qu'un seul écrivain pour une donnée. Donnes Ecrivain natAlert Coeur de contrôle Nature de l'interruption coeur de contrôle entrante sur le coeur de calcul : 0 => réveil tâche ; 1 => contrôle quota. contexPret Coeur de contrôle Liste des tâches prêtes contexDerout Coeur de contrôle Liste des tâches en erreur contexRepos Coeur de contrôle Liste des tâches au repos heureComptO Coeur de contrôle Valeur de l'heure courante du temporisateur (quand le compteur du temporisateur associé passe par 0) Tableau 1: exemple de données de synchronisation selon l'invention La structure des contextes d'exécution des tâches dispose de champs comme ceux définis à titre d'exemple dans le tableau 2 qui suit. Le contenu de ces champs est mis a jour par un seul écrivain, qui peut être soit le coeur de contrôle, soit par le coeur de calcul. II faut noter que, dans le présent exemple de réalisation, le coeur de calcul met avantageusement à jour une variable � etat � qui indique notamment si une tâche prête activable passe au repos ou en erreur. Le coeur de contrôle est le seul à pouvoir la faire revenir à l'état activable lors de la mise à jour des listes de tâches. Champ Ecrivain Description suiv Coeur de contrôle Pour gestion de la liste des contextes ag --- Pointeur sur le descripteur statique de la tâche datPret Coeur de contrôle Date d'activation effective Champ Ecrivain Description datFin Coeur de contrôle Date d'inactivation effective quota Coeur de contrôle Quota effectif pour la tâche applicative en cours datPretS Coeur de calcul Nouvelle date d'activation au plus tôt datFinS Coeur de calcul Nouvelle date de fin au plus tard quotaS Coeur de calcul Nouvelle valeur du quota pour la tâche applicative quotaM Coeur de calcul Nouvelle valeur du quota devant rester a l'issue du traitement de la tâche applicative datOcc Coeur de calcul Date de début d'occupation du CPU datLib Coeur de calcul Date de libération du CPU etat Coeur de calcul et coeur de État de la tâche : contrôle PRETREPOS : tâche au repos, repositionner la fenêtre d'exécution ; DATETARD : repousser la date limite ; DEROUT : tâche en erreur ; ACTIVABLE : tâche prête, pouvant être exécutée. Tableau 2: exemple de structure de contexte selon l'invention Dans le présent exemple de réalisation, la liste contexPret est 5 accédée en lecture par le coeur de calcul et entretenue par le coeur de contrôle, c'est-à-dire accédée en lecture et en écriture. Notamment, le coeur de calcul lit la liste contexPret : • après une interruption venant du coeur de contrôle pour contrôle du quota ou un réveil. Pour un contrôle de quota, la tête de liste 10 contexPret est comparée à la tâche en cours d'exécution pour déterminer si on est face à un dépassement de quota ou non. Pour un réveil, la tête de la liste contexPret est accédée pour en faire la nouvelle tâche à exécuter; • sur l'entrée système par l'intermédiaire d'une interruption logicielle 15 depuis la couche système, pour modifier les contraintes temporelles. Seul le pointeur suivant de la tâche en cours d'exécution est alors lu pour la suite de l'exécution. Du côté du coeur de contrôle, l'insertion d'un contexte A entre deux contextes B et C se fait en modifiant d'abord le suivant de A (qui sera égal à c), puis en modifiant le suivant de B (qui sera égal à A). Dans le présent exemple de réalisation, l'extraction des contextes peut être effectuée en considérant les contextes qui ne sont plus activables. Le contrôle s'opère donc de contexPret à la première tâche activable (cette dernière étant exclue). Les extractions sont invisibles pour le coeur de calcul, car si le contexte n'est plus activable, cela signifie que le coeur de calcul les a déjà exécutés, donc la tâche en cours d'exécution sur le coeur de calcul est ~o égale à la première tâche activable ou à un de ses suivants. Il n'y reviendra donc plus. Concernant la gestion de l'état DATETARD, il faut remarquer que cette opération a pour objectif de repousser la date limite d'un contexte lors son exécution. Lorsque ce report de date limite a lieu, le coeur de calcul 15 passe au suivant de ce contexte. Or, si la date limite est toujours en amont du suivant malgré ce report, la tâche ne sera pas ré-exécutable jusqu'à la prochaine interruption en provenance du coeur de contrôle avec natAlert valant o. Pour la mise à disposition du résultat des routines applicatives de 20 gestion des interruptions d'entrées/sorties sur le coeur de contrôle, comme expliqué précédemment, un tampon est mis à disposition en lecture de la couche système d'une tâche de calcul. L'indiçage dans ce tableau permet à la couche système côté coeur de calcul de maintenir et d'identifier les résultats d'entrées/sorties rapatriés ou non par la tâche. 25 La figure 6 illustre un exemple de scénario de fonctionnement selon l'invention de deux coeurs en parallèle, l'acronyme CS signifiant � couche système �, l'acronyme agMN signifiant � passage du mode tâche 30 applicative (agent ù ag) à micro-noyau (MN) et l'acronyme csMN signifiant � passage du mode tâche système (couche système ù cs) à micro-noyau (MN) �. A un instant to : • des tâches AGI et AG2 sont dans la liste des tâches prêtes ; • la tâche AGI est celle qui est en cours d'exécution et son quota va au-delà d'un instant t1 ; • la prochaine interruption finale est pour l'instant t1, date de réveil par le temporisateur d'une tâche AG3 ; • la tâche AG3 est dans la liste des tâches au repos. Entre l'instant to et l'instant t1 : • il y a trois interruptions intermédiaires sur le coeur de contrôle ; • la tâche AGI termine son activité élémentaire avant que son quota ne soit atteint. Le micro-noyau du coeur de calcul commute et exécute la tâche AG2 avec le quota de la tâche AGI . A l'instant t1 : • l'interruption par le temporisateur arrive pour le réveil de la tâche AG3, • le coeur de contrôle place la tâche AGI dans la liste des tâches au repos, place la tâche AG3 en tête de la liste des tâches prêtes, arme le temporisateur avec le quota de la tâche AG3 qui correspond à un instant t2, positionne natAlert à 0 et notifie par une interruption vers le coeur de calcul des nouvelles listes de tâches à prendre en compte. Le coeur de calcul effectue alors le contrôle de quota concernant la tâche AG2 puis donne la main à la tâche AG3. Entre l'instant t1 et l'instant t2 • il y a une interruption intermédiaire sur le coeur de contrôle ; • la tâche AG3 termine son activité élémentaire avant que son quota ne soit atteint. Le micro-noyau du coeur de calcul commute puis continue d'exécuter la tâche AG2 avec le quota de la tâche AG3. A l'instant t2 : • l'interruption par le temporisateur arrive pour le contrôle de quota de la tâche AG3 ; • le coeur de contrôle positionne natAlert à 1, notifie par une interruption vers le coeur de calcul les contrôles de quota à effectuer ; • le coeur de calcul passe en mode micro-noyau à réception de l'interruption du coeur de contrôle et modifie le contenu du contexte de la tâche en cours d'exécution pour contrôle de quota (la tâche AG3 avait terminé son activité), notifie par une interruption vers le coeur de calcul les mises à jour puis redonne la main à la seule tâche prête et activable, la tâche AG2 ; • le coeur de contrôle place la tâche AG3 dans la liste des tâches au repos et arme le temporisateur pour le réveil de la tâche AG3 (plus proche que l'épuisement du quota restant à AG2) à un instant t3. A l'instant t3 : • l'interruption du temporisateur arrive pour le réveil de la tâche AG3 ; • le coeur de contrôle place la tâche AG3 dans la liste des tâches prêtes (après la tâche AG2), arme le temporisateur avec le quota restant ~o autorisé de la tâche AG2 qui correspond à un instant t4, positionne natAlert à 0 et notifie par une interruption vers le coeur de calcul les nouvelles listes de tâches à prendre en compte. Le coeur de calcul effectue alors le contrôle de quota concernant la tâche AG2 puis donne la main à la tâche AG3 15 Entre l'instant t3 et l'instant t4 • il y a une interruption intermédiaire sur le coeur de contrôle. A l'instant t4 : • l'interrution du temporisateur arrive pour le contrôle de quota de la tâche AG2 ; 20 • le coeur de contrôle positionne natAlert à 1, notifie par une interruption vers le coeur de calcul les contrôles de quota à effectuer ; • le coeur de calcul passe en mode micro-noyau à réception de l'interruption du coeur de contrôle et modifie le contenu du contexte de la tâche en cours d'exécution (la tâche AG2 a dépassé son quota), 25 notifie par une interruption vers le coeur de calcul les mises à jour puis donne la main à la seule tâche prête et activable, la tâche AG3 ; • le coeur de contrôle place la tâche AG2 dans la liste des tâches en erreur et arme le temporisateur pour le réveil de la tâche AGI (plus proche que l'épuisement du quota restant à AG3) à un instant t5. 30 Entre l'instant ta et l'instant t5 : • la tâche AG3 termine son activité élémentaire avant que son quota ne soit atteint. Le micro-noyau du coeur de calcul passe en mode oisif. A l'instant t5 : • l'interruption du temporisateur arrive pour le réveil de la tâche AGI ; • le coeur de contrôle place la tâche AG3 dans la liste des tâches au repos et la tâche AGI dans la liste des tâches prêtes, arme le temporisateur avec le quota de la tâche AGI, positionne natAlert à 0 et notifie par une interruption vers le coeur de calcul les nouvelles listes de tâches à prendre en compte. En déportant sur un coeur dédié au contrôle un sous ensemble de fonctions du noyau que sont l'ordonnancement des tâches, la gestion du temps et la gestion des entrées-sorties sous interruption, l'invention décrite précédemment permet d'exploiter pleinement et de tirer au mieux parti du parallélisme effectif d'une architecture matérielle mufti-coeur. La répartition asymétrique des fonctions du noyau proposée par l'invention permet également de sécuriser l'exécution temps-réel de tâches de calcul cadencées par le temps ainsi que l'exécution des routines sous interruption d'entrées-sorties. En effet, la répartition asymétrique des fonctions du noyau proposée par l'invention assure une séparation spatiale et temporelle entre l'îlot ET exécuté sur le coeur de contrôle et le ou les îlots TT exécutés sur un ou plusieurs coeurs de calcul. Ainsi, la gestion des traitements sous interruption n'est pas imputée au coeur de calcul, notamment les traitements d'entrées-sorties, ne perturbant en aucun cas les performances atteignables par les tâches de calcul. Du point de vue de la mémoire, les placements mémoire et éventuellement les protections mémoires empêchent le coeur de contrôle d'accéder aux zones mémoires des tâches de calculs. Les contrôles d'occurrence d'interruptions d'entrées-sorties sur le coeur de contrôle et les contrôles de temps d'exécution effectifs sur le ou les coeurs de calcul permettent de surveiller les interruptions et de détecter d'éventuelles anomalies de comportement temporel. L'invention décrite précédemment a encore pour principaux avantages qu'il permet l'exécution performante, maîtrisée et sécurisée d'un système complet temps-réel embarqué, pour des applications dans le domaine de l'automobile par exemple. En effet, l'invention permet de tirer au mieux parti des architectures matérielles embarquées, autorisant un très haut degré d'intégration en terme de nombres de tâches ou de fonctionnalités par processeur. Le procédé d'exécution multitâche associé intégrant la coordination des coeurs, l'invention permet également d'exécuter de manière transparente au développeur sur des architectures mufti-coeurs de taille quelconque une application comportant un ensemble de tâches et de routines sous interruption d'entrées-sorties. Le développeur n'a en effet plus à se soucier de la localisation des tâches ou des routines grâce aux interfaces et aux éléments partagés dans le noyau qui ont été définies pour gérer son partitionnement asymétrique sur les coeurs.10 REVENDICATIONS1. Système de traitement de l'information comportant au moins deux coeurs de traitement, l'exécution d'une application par le système incluant l'exécution de tâches applicatives et l'exécution de tâches systèmes, le système de traitement étant caractérisé en ce qu'il comporte : - un coeur de calcul exécutant des tâches systèmes relatives à la commutation des tâches sur le coeur de calcul ; un coeur de contrôle exécutant des tâches systèmes relatives au contrôle de l'ordre d'allocation des tâches au coeur de calcul. 2. Système selon la revendication 1, caractérisé en ce que le coeur de contrôle exécute des tâches applicatives déclenchées par des interruptions d'entrées/sorties. 3. Système selon la revendication 1, caractérisé en ce que les tâches systèmes exécutées par le coeur de calcul relatives à la commutation des tâches incluent la mise à jour pour chaque tâche d'un état indiquant si ladite tâche est exécutable ou pas. 4. Système selon la revendication 3, caractérisé en ce que l'état indiquant si la tâche est exécutable peut prendre : - une valeur indiquant que la tâche est prête ; - une valeur indiquant que la tâche est au repos ; - une valeur indiquant que la tâche est en erreur. 5. Système selon la revendication 4, caractérisé en ce que les tâches systèmes exécutées par le coeur de contrôle relatives au contrôle de l'ordre d'allocation des tâches au coeur de calcul incluent la gestion : d'une liste ordonnée des tâches prêtes, et/ou ; - d'une liste ordonnée des tâches au repos, et/ou ; d'une liste des tâches en erreur. 6. Système selon la revendication 3, caractérisé en ce que chaque tâche est associée à un contexte d'exécution regroupant des données d'exécution de ladite tâche, incluant l'état indiquant si elle est exécutable. 7. Système selon la revendication 6, caractérisé en ce que les tâches systèmes exécutées par le coeur de calcul relatives à la commutation des tâches incluent, sur réception d'une interruption par le coeur de calcul : - le chargement du contexte d'exécution d'une tâche parmi les tâches prêtes ; - le déclenchement de l'exécution de ladite tâche. 8. Système selon les revendications 5 et 7, caractérisé en ce que, sur 10 réception d'une interruption, le coeur de calcul charge le contexte d'exécution de la première tâche dans la liste des tâches prêtes. 9. Système selon les revendications 5 et 6, caractérisé en ce que les tâches systèmes exécutées par le coeur de calcul relatives à la commutation des 15 tâches incluent la mise à jour dans le contexte d'exécution de chaque tâche : - d'une date limite de début d'exécution au plus tôt et/ou d'une date limite de fin d'exécution au plus tard ; d'un quota de temps d'exécution restant ; 20 de sorte que le coeur de contrôle ordonne les tâches dans la liste des tâches prêtes dans un ordre qui permet d'exécuter chaque tâche dans le respect de ses dates limites d'exécution et dans le respect de son quota de temps d'exécution. 25 10. Système selon la revendication 7, caractérisé en ce que l'interruption est générée par un temporisateur implémenté par le coeur de contrôle. 11. Système selon la revendication 10, caractérisé en ce que le temporisateur est cadencé par une horloge à quartz, de manière à 30 déclencher l'exécution par le coeur de calcul de tâches applicatives temps-réel. 12. Système selon la revendication 1, caractérisé en ce que le coeur de calcul exécute les tâches systèmes relatives aux communications entre les 35 tâches. 13.Système selon la revendication 1, caractérisé en ce qu'il comporte un espace mémoire partagé par le coeur de contrôle et le coeur de calcul. 14. Système selon la revendication 1, caractérisé en ce que le coeur de contrôle et le coeur de calcul sont des processeurs de types différents. 15. Système selon la revendication 14, caractérisé en ce que les processeurs sont implantés sur une puce.10