FR 2946442 A1 20101210 FR 0902750 A 20090605 La présente invention concerne l'architecture de systèmes de type avionique et plus particulièrement un procédé et un dispositif de chargement et d'exécution d'instructions à cycles déterministes dans un système avionique mufti-coeurs ayant un bus dont le temps d'accès est non prédictible. Les aéronefs modernes comprennent de plus en plus de systèmes électroniques et informatiques pour améliorer leurs performances et assister le pilote ainsi que les membres d'équipage lors de leurs missions. Ainsi, par exemple, les commandes de vol électriques permettent de réduire la complexité mécanique de la transmission des commandes aux actuateurs et donc la masse associée à ces commandes. De même, la présentation d'informations pertinentes permet au pilote d'optimiser les trajectoires de vol et de répondre rapidement à tout incident détecté. De telles informations sont notamment la vitesse, la position, le cap, des données de météorologie et de navigation. L'ensemble de ces systèmes électroniques et informatiques est généralement appelé l'avionique. Pour des raisons notamment de fiabilité, de simplicité et de certification, l'avionique a souvent été répartie de façon fonctionnelle par modules spécifiques, aussi appelé LRU (sigle de Line Replaceable Unit en terminologie anglo-saxonne). Ainsi, par exemple, les commandes de vol sont gérées dans un dispositif particulier tandis que l'alimentation électrique est gérée dans un autre. Une fonction spécifique est ainsi associée à chaque module. Par ailleurs, chaque module supportant une fonction critique est, de préférence, redondant de telle sorte que la défaillance d'un module n'entraîne pas la perte de la fonction associée. L'exploitation d'un aéronef utilisant un module redondant lorsque le module principal est défaillant nécessite une opération de maintenance. Afin d'améliorer les fonctionnalités des aéronefs, réduire le poids des équipements électroniques et faciliter les opérations de maintenance, l'avionique est maintenant de plus en plus intégrée selon une architecture appelée IMA (sigle d'lntegrated Modulai. Avionics en terminologie anglo- saxonne). Selon cette architecture, les fonctionnalités sont décorrélées des systèmes, c'est-à-dire des calculateurs ou des ressources de calcul, dans lesquels elles sont implémentées. Néanmoins, un système de ségrégation permet d'isoler chacune des fonctionnalités de telle sorte que la défaillance d'une fonction n'ait pas d'influence sur une autre. De tels systèmes mettent en oeuvre différents modules, en particulier des modules de traitement de données, appelés CPM (sigle de Core Processing Module en terminologie anglo-saxonne), des modules de commutation de données, appelés ASM (sigle d'Avionic Switch Module en terminologie anglo-saxonne), et des modules d'alimentation électrique, aussi appelés PSM (sigle de Power Supply Module en terminologie anglo-saxonne). Les modules de traitements de données comprennent des modules dits � hautes performances � pour les applications générales d'avionique, des modules dits � temps critique � pour les applications d'avionique ayant de forte contraintes de déterminisme temporel et des modules de type serveur pour les applications du monde ouvert, non critiques. Un module de traitement de données est généralement composé d'un ou de plusieurs processeurs, aussi appelés CPU (sigle de Central Processing Unit en terminologie anglo-saxonne), associés à un ou plusieurs bancs mémoire de type RAM (sigle de Random Access Memory en terminologie anglo-saxonne) et FLASH. Les communications entre plusieurs CPU d'un CPM sont, de préférence, assurées à l'aide de liens directs vers une mémoire partagée ou à travers une mémoire d'échange d'une interface de communication, par exemple une interface AFDX (sigle d'Avionic Full DupleX en terminologie anglo- saxonne). Afin de permettre le calcul du WCET (sigle de Worst Case Execution Time en terminologie anglo-saxonne) les modules de traitement de données dits temps critique doivent utiliser des processeurs et des architectures de mémoire permettant leur déterminisme temporel. Pour réaliser un module de traitement de données dit temps critique, appelés CPM TC (sigle de Core Processing Module Time Critical en terminologie anglo-saxonne) dans la suite de la description, un nombre important de processeurs relativement simples peut être utilisé, avec une exécution du code en mémoire RAM statique ou en mémoire de type flash afin de garantir le déterminisme temporel. La figure 1 illustre schématiquement un CPM mettant en oeuvre une telle architecture. Comme illustré, le CPM 100 comprend ici quatre processeurs � simple coeur � 105-1 à 105-4 et, associées à chaque processeur, des mémoires de type DDRAM (sigle de Double Data rate Random Access Memoty en terminologie anglo-saxonne), génériquement référencées 110, et de type flash, génériquement référencées 115. Par ailleurs, le CPM comprend un ensemble 120 de circuits logiques permettant notamment aux processeurs 105- à 105-4 d'échanger des données avec d'autres composants de l'aéronef via un module d'entrée/sortie 125. Cependant, l'utilisation d'un nombre important de processeurs augmente le risque de panne, ou MTBF (sigle de Mean Time Between Failures en terminologie anglo-saxonne), ainsi que le poids et les coûts de développement. Par ailleurs, en dépit de la puissance de calcul requise dans les CPM TC, des processeurs performants, super scalaires, qui exécutent des instructions de code depuis un banc de mémoire RAM dynamique ne sont pas ou mal utilisés à cause du temps de rafraîchissement de la mémoire, des changements de lignes, colonnes et/ou banques et surtout de la latence plus importante du contrôleur de mémoire. En d'autres termes, les CPM TC ne mettent généralement pas efficacement en oeuvre des processeurs basés sur des architectures mufti-coeurs utilisant des mémoires caches. En effet, les CPM TC ont besoin d'un déterminisme fort de leur temps d'exécution et leurs mémoires caches créent une variabilité difficilement déterminable due à un effet d'historique selon lequel, en fonction des événements passés, une information peut encore être ou non présente en mémoire cache. II peut alors être nécessaire de la recharger sans que cela soit déterminé à l'avance. Il en va de même pour les séquences d'instructions de type pipeline des coeurs des processeurs et des contrôleurs de mémoire pour lesquelles les instructions peuvent être réparties sur plusieurs cycles créant ainsi des dépendances historiques. Par conséquent, pour être déterministes, les CPM TC doivent écarter les mécanismes à l'origine de ces variabilités et utiliser des marges permettant de déterminer à l'avance les temps d'exécution rendant ainsi l'utilisation de processeurs multi-coeurs inefficace. L'invention permet de résoudre au moins un des problèmes exposés précédemment. Plus particulièrement, il est possible, selon l'invention, de déterminer à l'avance l'utilisation des mémoires caches de systèmes multicoeurs de telle sorte que la latence des mémoires ne soit plus un facteur limitant les performances. L'invention permet également, dans une architecture multicoeurs, multi-processeurs, ou plus généralement à bus processeur partagé, d'obtenir l'indépendance des coeurs de calcul et la détermination de WCET non pessimistes. De plus, l'indépendance vis-à-vis de la latence des mémoires caches autorise la détermination de WCET même si les modèles de mémoire et de contrôleur de mémoire sont imprécis. L'invention a ainsi pour objet un procédé de chargement et d'exécution à cycles d'exécution déterministes d'une pluralité d'instructions dans un système avionique comprenant au moins un processeur ayant au moins deux coeurs et au moins un contrôleur de mémoire, chacun desdits au moins deux coeurs disposant d'une mémoire privée, ladite pluralité d'instructions étant chargée et exécutée par tranches d'exécution, le procédé comprenant les étapes suivantes, durant une première tranche d'exécution, o autorisation d'accès audit au moins un contrôleur de mémoire à un premier desdits au moins deux coeurs, ledit premier coeur transmettant audit au moins un contrôleur de mémoire au moins une donnée mémorisée dans sa mémoire privée, préalablement modifiée, et recevant au moins une donnée et au moins une instruction de ladite pluralité d'instructions, ladite au moins une donnée et ladite au moins une instruction reçues étant mémorisées dans sa mémoire privée ; o interdiction d'accès audit au moins un contrôleur de mémoire à un second desdits au moins deux coeurs, ledit second coeur exécutant au moins une instruction préalablement mémorisée dans sa mémoire privée ; - durant une seconde tranche d'exécution, o interdiction d'accès audit au moins un contrôleur de mémoire audit premier coeur, ledit premier coeur exécutant au moins une instruction préalablement mémorisée dans sa mémoire privée ; et, o autorisation d'accès audit au moins un contrôleur de mémoire audit second coeur, ledit second coeur transmettant audit au moins un contrôleur de mémoire au moins une donnée mémorisée dans sa mémoire privée, préalablement modifiée, et recevant au moins une donnée et au moins une instruction de ladite pluralité d'instructions, ladite au moins une donnée et ladite au moins une instruction reçues étant mémorisées dans sa mémoire privée. Le procédé selon l'invention permet ainsi de mettre en oeuvre des technologies basées sur des processeurs mufti-coeurs ayant des bus dont le temps d'accès est non prédictible pour des applications ayant de forte contraintes de déterminisme temporel. En particulier, le procédé permet l'utilisation de mémoires de type DDRx fonctionnant en rafale (mode appelé burst en terminologie anglo-saxonne), de coeurs travaillant à des fréquences supérieures à 1 GHz, la mise en oeuvre d'architecture massivement parallèle et l'intégration électronique sous forme de composants uniques. Bien que le découpage de l'activité des coeurs en longues phases d'exécution, sans accès à une mémoire partagée et en longues phases d'accès à une mémoire partagée, sans calcul, semble inefficace à première vue, il l'est du fait des applications avioniques envisagées et du découpage des applications. Le temps des phases d'accès mémoire est avantageusement inférieur au temps total passé par un coeur à attendre la complétion de chacun de ces accès pour que le modèle d'exécution soit efficace. Un autre avantage significatif est la simplification et la forte réduction de pessimisme des calculs de WCET par analyse statique du fait de la présence en mémoire privée des données utilisées dans les phases de calcul. Un autre avantage concerne les outils d'analyse statique basés sur un modèle du processeur. L'outil n'ayant pas à considérer dans ses analyses les scénarii incluant les accès à la mémoire partagée, le modèle du processeur peut être réduit au seul coeur et à ses mémoires privées. Cette approche est également compatible et adaptée aux évolutions des technologies de mémoire qui évoluent vers des débits très élevés, sans réduire les latences en proportion, le but étant ici d'alimenter des mémoires privées de plus en plus importantes et nombreuses. Selon un mode de réalisation particulier, ledit au moins un processeur comprend en outre au moins un second contrôleur de mémoire, le procédé comprenant en outre les étapes suivantes, - durant une première phase de ladite première tranche d'exécution, autorisation d'accès à un premier desdits au moins deux contrôleurs de mémoire audit premier coeur et interdiction d'accès à un second desdits au moins deux contrôleurs de mémoire audit premier coeur ; - durant une seconde phase de ladite première tranche d'exécution, autorisation d'accès audit second contrôleur de mémoire audit premier coeur et interdiction d'accès audit premier contrôleur de mémoire audit premier coeur ; - durant une première phase de ladite seconde tranche d'exécution, autorisation d'accès audit premier contrôleur de mémoire audit second coeur et interdiction d'accès audit second contrôleur de mémoire audit second coeur ; et, - durant une seconde phase de ladite seconde tranche d'exécution, autorisation d'accès audit second contrôleur de mémoire audit second coeur et interdiction d'accès audit premier contrôleur de mémoire audit second coeur. Le procédé permet ainsi aux coeurs d'accéder à des mémoires partagées pour exécuter des instructions utilisant des données communes. Selon un mode de réalisation particulier, au moins un desdits au moins deux coeurs est dédié à des opérations de transmission et de réception de données vers et depuis une interface de communication réseau pour simplifier la modélisation du processeur. L'invention a également pour objet un procédé de traitement d'une pluralité d'instructions pour permettre le chargement et l'exécution à cycles d'exécution déterministes de ladite pluralité d'instructions selon le procédé décrit précédemment, le procédé de traitement comprenant une étape de découpage de ladite pluralité d'instructions en tranches d'exécution, chaque tranche d'exécution comprenant une séquence de transfert et une séquence d'exécution, ladite séquence de transfert permettant la transmission d'au moins une donnée préalablement mémorisée et la réception et la mémorisation d'au moins une donnée et d'au moins une instruction, ladite au moins une donnée reçue étant nécessaire à l'exécution de ladite au moins une instruction reçue et permettant l'exécution de ladite au moins une instruction reçue, de façon autonome, durant l'exécution de ladite séquence d'exécution. Le procédé de traitement permet ainsi de découper les instructions en tranches d'exécution pour optimiser le procédé de chargement et d'exécution décrit dont l'efficacité dépend de la capacité à déterminer précisément les informations nécessaires d'une prochaine phase d'exécution pour éviter de sous-estimer ou surestimer la quantité d'informations nécessaires ce qui a pour effet de requérir un accès à la mémoire partagée pour l'exécution des instructions ou d'engendrer une phase de chargement plus longue au temps que passerait le coeur à charger chaque donnée. Selon un mode de réalisation particulier, ladite étape de découpage est basée sur la résolution d'un système d'équations linéaires représentant des contraintes d'exécution des instructions de ladite pluralité d'instructions selon au moins une caractéristique dudit au moins un processeur. Le procédé selon l'invention permet ainsi d'optimiser l'organisation des tranches d'exécution et de simplifier leur détermination. La durée desdites tranches d'exécution est, de préférence, constante et prédéterminée. Cette durée est, par exemple, déterminée par le temps de transmission de données préalablement modifiées et le temps de réception de données et d'instructions à exécuter. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté dans un processeur, un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un aéronef comprenant le dispositif selon la revendication précédente. Les avantages procurés par un tel programme d'ordinateur et un tel dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un module de traitement 15 de données comprenant plusieurs processeurs simple coeur ; - la figure 2, comprenant les figures 2a à 2d, illustre schématiquement un diagramme de temps illustrant les activités d'un processeur comprenant huit coeurs, mis en oeuvre conformément à l'invention ; - la figure 3, comprenant les figures 3a et 3b, illustre un exemple 20 d'architecture mufti-coeurs adaptée à mettre en oeuvre l'invention ; - la figure 4, comprenant les figures 4a à 4d, illustre un exemple de mécanisme d'accès, par chaque coeur en phase de transfert d'un processeur mufti-coeurs, aux contrôleurs de mémoire de ce processeur ; et, - la figure 5 illustre schématiquement un module d'un système 25 avionique, dont l'architecture est fondée sur un processeur mufti-coeurs tel que celui présenté sur la figure 3b, adapté à mettre en oeuvre l'invention. Les processeurs mufti-coeurs de dernière génération, aussi appelés SoC multicores (sigle de System on Chip en terminologie anglo-saxonne), offrent un fort potentiel de puissance de calcul. Cependant, dans le contexte 30 des applications temps réel critique, ce potentiel est difficilement exploitable, notamment pour des raisons de déterminisme et de preuve ou test relatif à des exigences temporelles. Il est rappelé ici que la notion de temps réel implique une maîtrise précise du comportement temporel d'applications exécutées, notamment de leur WCET. Le qualificatif � critique � exige, dans le domaine de l'aéronautique, d'apporter une preuve forte de cette maîtrise. Cette problématique de déterminisme provient en partie de l'exécution d'une ou plusieurs applications en concurrence sur chacun des coeurs qui partagent certaines ressources en nombre insuffisant pour ségréguer physiquement tous les chemins de tous les coeurs, en particulier des bus d'échange de données et des mémoires utilisées. Si ces partages ne sont pas maîtrisés (idéalement des accès maîtrisés sont des accès temporellement exclusifs), ils introduisent des contentions généralement indénombrables. Alternativement, la majoration par une analyse de type pire éventualité, worstcase en terminologie anglo-saxonne, est trop pessimiste et conduit à une sous exploitation extrême du processeur mufti-coeurs. Une autre source d'indéterminisme provient de la complexité intrinsèque des SoC dont l'ensemble des composants crée des phénomènes d'historiques rendant prohibitif, en termes de coût de calcul, une analyse de type pire éventualité raisonnablement peu pessimiste. Le manque d'observabilité intra-SoC et l'absence de documentation concernant leur architecture rendent également impossible la création de modèles temporels et fiables adaptés aux analyses WCET. Le système selon l'invention permet de contourner ces difficultés. Il est tout d'abord rappelé qu'à l'intérieur des SoC, chaque coeur dispose d'une ou plusieurs mémoires caches privées. Typiquement, les coeurs envisagés dans les CPM possèdent trois mémoires caches privées par coeurs : une mémoire cache LI_I (ou LII) pour les instructions, une mémoire cache LI_D (ou L1 D) pour les données et une mémoire cache L2 unifiée pour les instructions et les données. S'il est important ici que chaque coeur dispose d'une mémoire cache individuelle et d'instructions pour les charger et les décharger, le nombre de niveaux des mémoires caches importe peu. Alternativement, chaque coeur peut accéder à une mémoire locale ayant une adresse sur le réseau coeur (core-network). De façon similaire, l'invention peut être mise en oeuvre avec un dispositif interne du SoC, externe aux coeurs, de type DMA SoC (DMA est le sigle de Direct Memory Access en terminologie anglo-saxonne), piloté par les coeurs ou activé à date fixe sur la base d'un calendrier de tâches, ce dispositif se chargeant de transférer les données dans les deux sens entre les mémoires associées aux coeurs, de type RAM, et les mémoires centrales de type DDR. Tant qu'une application s'exécute uniquement dans ces mémoires caches, il n'y a aucun problème de conflit de ressources dû à l'architecture mufti-coeurs. Les problèmes de complexité des SoC sont aussi, dans ce cas, fortement réduits car les modèles nécessaires à la détermination des WCET se limitent aux coeurs et à leurs mémoires caches. Cependant, les mémoires caches n'ont généralement pas une taille suffisante pour mémoriser les applications dans leur intégralité. De plus, les applications exécutées ont besoin, par nature, de recevoir et de transmettre des données à travers des interfaces d'entrée/sortie, appelées I/O (sigle d'input/Output en terminologie anglo-saxonne). Le principe du système selon l'invention est de créer des phases durant lesquelles les applications s'exécutent exclusivement à l'intérieur de leurs mémoires caches privées, aucune sollicitation externe (accès données ou surveillance) ne venant les affecter. Ce principe apporte les bénéfices suivants : - l'exécution des phases est entièrement indépendante de l'activité des autres coeurs et l'analyse WCET de ces phases peut suivre une démarche traditionnelle mono-coeur ; et, - la détermination des WCET ne nécessite pas d'autre modèle que celui des coeurs et de leurs mémoires caches privées. En particulier, un modèle des bus de données inter-coeurs et du contrôleur de mémoire n'est pas requis. Il convient cependant de noter que, comme invoqué précédemment, les applications ne peuvent généralement pas être entièrement contenues dans les mémoires caches privées des coeurs. Par ailleurs, un coeur n'est en général pas dédicacé à une application particulière. De plus, ses données ne sont pas locales, une application devant nécessairement consommer et produire des données utilisées par d'autres applications. Par conséquent, il est nécessaire de gérer les accès à une mémoire partagée et/ou des accès à un ou plusieurs réseaux pour charger et décharger des instructions de code et les données applicatives. Cependant, ces accès doivent être planifiés afin qu'ils soient exclusifs (idéalement) entre les coeurs ainsi que dénombrables et distribués de façon à ce que les conditions les pires soient le moins majorant possible en termes de temps de traitement. Une solution pour planifier ces accès consiste notamment à définir des points de rendez-vous entre lesquels un coeur dispose d'un accès a chaque ressource (par exemple un contrôleur de mémoire particulier), exclusif et partagé avec un minimum d'autres coeurs. En dehors de ces plages, le coeur ne peut pas accéder à ces ressources. II est ainsi nécessaire de distribuer les points de rendez-vous de façon à ce que chaque coeur dispose d'un accès équitable aux ressources. De façon avantageuse, ces points de rendez-vous sont placés de façon statique et régulière. Ainsi, par exemple, pour un processeur disposant de huit coeurs et de deux contrôleurs de mémoire, pour des durées d'exécution et d'accès mémoire équivalentes, quatre coeurs sont autorisés, à tout moment, à accéder à une mémoire via les deux contrôleurs de mémoire, cet accès étant interdit aux quatre autres coeurs. Avantageusement, parmi les quatre coeurs pouvant accéder aux contrôleurs de mémoire, à tout instant, deux et seulement deux accèdent à chaque contrôleur de mémoire. Une durée d'accès mémoire plus courte permet de dédier plus de temps à la phase d'exécution, sans accès mémoire, sans changer la durée totale du cycle mémoire et de l'exécution. Une durée d'accès mémoire plus courte permet de limiter le nombre de coeurs accédant à la mémoire à tout instant. La figure 2, comprenant les figures 2a et 2b, illustre schématiquement un diagramme de temps illustrant les activités d'un processeur comprenant huit coeurs, mis en oeuvre conformément à l'invention. Le type d'activité de chacun des coeurs est ici représenté selon l'axe des temps 200. La figure 2b reprend une partie de la figure 2a pour illustrer plus précisément les rôles d'un coeur particulier, ici le second. Les repères 205-i, 205-j et 205-k définissent des instants qui représentent des points de rendez-vous statiques et réguliers où les coeurs changent leur rôle. Ainsi, par exemple, à l'instant 205-i, le premier coeur exécute une série d'instructions préalablement mémorisées dans sa mémoire cache avec les données correspondantes (référence 210). A partir du même instant, le second coeur échange des données avec un contrôleur de mémoire. Dans un premier temps, il transmet des données mémorisées dans sa mémoire cache vers le contrôleur de mémoire (référence 215). Puis, dans un second temps, il reçoit des données et des instructions du contrôleur de mémoire qu'il mémorise dans sa mémoire cache (référence 220). Ainsi, le second coeur se prépare à une phase d'exécution autonome durant laquelle il n'aura pas besoin d'accéder aux contrôleurs de mémoire. La période séparant deux instants consécutifs auxquels chaque coeur change de rôle définit une tranche d'exécution notée T. Ensuite, à l'instant 205-j, le premier coeur transmet des données mémorisées dans sa mémoire cache vers le contrôleur de mémoire (référence 225) puis reçoit des données et des instructions du contrôleur de mémoire qu'il mémorise dans sa mémoire cache (référence 230). A partir du même instant 205-j, le second coeur exécute les instructions préalablement mémorisées dans sa mémoire cache avec les données correspondantes (référence 235). A nouveau, à l'instant 205-k, le premier coeur exécute les instructions préalablement reçues tandis que le second coeur transmet et reçoit des données et des instructions. Un mécanisme similaire est mis en oeuvre dans tous les coeurs. Comme indiqué précédemment, le SoC comprenant le processeur dont le fonctionnement est illustré sur la figure 2 comprend également, de préférence, deux contrôleurs de mémoire. Ainsi, les deux paires de coeurs 240 et 245 de l'ensemble 250 accèdent chacune à un contrôleur de mémoire différent de telle sorte qu'au sein de cet ensemble, chaque contrôleur de mémoire n'est accédé, à un instant donné, que par un seul coeur. De façon similaire, les deux paires de coeurs 255 et 260 de l'ensemble 265 accèdent chacune à un contrôleur de mémoire différent de telle sorte qu'au sein de cet ensemble, chaque contrôleur n'est accédé, à un instant donné, que par un seul coeur. Ainsi, à un instant donné, chaque contrôleur de mémoire est accédé par deux coeurs distincts. Il convient de remarquer ici que si le SoC dispose de plusieurs contrôleurs de mémoire, l'accès des coeurs à chacun des contrôleurs de mémoire est avantageusement équilibré. Cependant, un seul contrôleur de mémoire peut être utilisé, notamment s'il suffit à servir les besoins de performance du CPM TC. Dans ce cas, l'utilisation d'un seul contrôleur de mémoire permet d'améliorer les coûts de développement ainsi que la fiabilité, la masse et la dissipation thermique du SoC. L'ordonnancement des phases de transfert sur l'ensemble des coeurs est, de préférence, strictement synchrone, équilibré et planifié. L'usage des ressources partagées, notamment des contrôleurs de mémoire, est également, de préférence, strictement synchrone, équilibré et planifié. Ainsi, si le SoC contient deux contrôleurs de mémoire, la moitié des coeurs en phase de transfert accède, à tout instant, à l'un des contrôleurs de mémoire et l'autre moitié à l'autre contrôleur de mémoire. Si nécessaire, à des instants prédéfinis, tout ou partie des coeurs en phase de transfert peut changer de contrôleur de mémoire afin de maintenir l'exact équilibre. Deux stratégies peuvent être mise en oeuvre : - dédier un seul contrôleur de mémoire par tranche d'exécution, une tranche d'exécution représentant l'ensemble des instructions exécutées par un coeur entre deux points de rendez-vous consécutifs. Cependant, dans ce cas, la tranche d'exécution ne peut pas participer à des processus de calcul mettant en oeuvre des fonctions particulières utilisant l'autre contrôleur de mémoire. Une telle stratégie conduit à la création de domaines de calculs propres à chaque contrôleur de mémoire, avec une problématique de communication entre les contrôleurs de mémoire qui peut s'avérer délicate à gérer, notamment pour les I/O utilisant un coeur particulier ; et, - obliger chaque tranche d'exécution à communiquer de façon équitable avec chaque contrôleur de mémoire. Une telle contrainte d'équilibrage n'est pas difficile à atteindre. Les données sont généralement privées pour chaque tranche d'exécution. En outre, elles peuvent être dupliquées si nécessaire, tout comme les instructions. Par ailleurs, ces données peuvent être placées indifféremment sur l'un ou l'autre contrôleur de mémoire pour équilibrer le partage. Bien que le partage d'un contrôleur de mémoire entre deux coeurs ne soit pas une solution optimale vis-à-vis du coeur, cette solution est néanmoins préférable vis-à-vis du contrôleur de mémoire car un coeur seul ne peut généralement pas maintenir un pipeline de requêtes suffisamment long pour effacer entièrement la latence des mémoires utilisées. En effet, lorsque P coeurs fonctionnent en tandem, dans la mesure où chaque requête d'accès ne dépend pas de la complétion des N requêtes précédentes, N étant la profondeur du pipeline d'accès d'un coeur (c'est-à-dire la capacité de l'entité appelée Load Store Unit (LSU) en terminologie anglo-saxonne), le pipeline formé dans le contrôleur de mémoire a une longueur PxN qui permet d'atteindre l'optimum d'efficacité des mémoires utilisées (souvent considérées comme étant l'un des goulets d'étranglement majeur dans un système mufti-coeurs). A titre d'illustration, pour des coeurs disposant d'un pipeline de 5 (LSU), deux coeurs forment un pipeline de 10 requêtes dans le contrôleur de mémoire, soit 80 transferts de données de type burst de 8 données par requête. II suffit ainsi que la latence d'une requête soit inférieure à 40 cycles, en utilisant un taux de transfert double (double data rate) pour ne pas avoir de période d'inactivité dans le pipeline du contrôleur de mémoire. Concernant la longueur des tranches d'exécution, c'est-à-dire l'espacement de points de rendez-vous consécutifs, les références de temps 25 suivantes peuvent être identifiées, - temps le pire pour exécuter les instructions de code chargées en mémoire cache avec ses données associées. Bien que ce temps dépende de la nature de l'application exécutée, il est relativement constant pour des applications avioniques ; et, 30 - temps le pire pour transférer des données modifiées vers les contrôleurs de mémoire à partir des mémoires caches et pour charger, depuis les contrôleurs de mémoire, les instructions, constantes et variables d'une tranche d'exécution dans les mémoires caches. Ce temps dépend du nombre de coeur en concurrence. Il convient de remarquer ici que des points de rendez-vous rapprochés sont possibles mais augmentent le nombre de tranches d'exécution et la taille du problème de placement des instructions et de données pour le traitement en tranches d'exécution. Cette fragmentation des traitements augmente aussi le volume total des données à charger et à décharger des mémoires caches. Alors que les figures 2a et 2b illustrent un exemple de placement optimal lorsque la durée de la phase de déchargement/chargement est identique à celle de la phase d'exécution des instructions, de nombreuses autres répartitions sont possibles. A titre d'illustration, les figures 2c et 2d montrent des exemples de placement optimal lorsque la durée de la phase d'exécution des instructions est inférieure à trois fois celle de la phase de déchargement/chargement et supérieure ou égale à trois fois celle de la phase de déchargement/chargement, respectivement, A représentant la durée d'une tranche d'exécution. La figure 3, comprenant les figures 3a et 3b, illustre un exemple d'architecture mufti-coeurs adaptée à mettre en oeuvre l'invention. Le système mufti-coeurs 300 représenté schématiquement sur la figure 3a comprend ici huit coeurs référencés 305-1 à 305-8 reliés chacun à une mémoire locale à durée d'accès faible, invariante et indépendante de l'historique, c'est-à-dire de l'exécution antérieure de l'unité de calcul à laquelle elle est reliée. Ces mémoires locales portent ici les références 310-1 à 310-8. Elles peuvent être des mémoires caches locales ou des blocs de mémoire statique accessibles par adressage virtuel ou physique depuis les unités de calcul. Chaque mémoire locale est elle-même connectée à une unité de bus, dont les références sont 315-1 à 315-8, connectée à son tour à un bus commun 320 relié à une mémoire partagée 325. Les coeurs forment des unités de calcul arithmétique, logique, flottant ou autre qui exécutent les traitements complexes. Ils n'accèdent qu'à la mémoire locale à laquelle ils sont reliés. La problématique de calcul de WCET des coeurs formant le domaine 330 est décorrélée de la caractéristique mufti-coeurs et de la problématique de modélisation de la mémoire externe partagée et du réseau d'interconnexion des coeurs formant le domaine 335. Par ailleurs, les mémoires caches ou blocs de mémoire statique sont maintenus en cohérence et alimentés par un système à plusieurs acteurs plus simple que les coeurs. Notamment, la variabilité due aux entrées, la combinatoire due aux décisions de branchements, toutes les décisions spéculatives que peuvent prendre les unités d'exécution et toute la variabilité due aux incertitudes de synchronisme entre les coeurs sont ignorées du domaine 335. En pratique, du fait de l'absence de variabilité, il peut être considéré qu'une seule mesure suffit à déterminer l'unique temps nécessaire au chargement de chaque tranche. Cette invariabilité n'est cependant obtenue que si les opérations de rafraîchissement de la mémoire sont désactivées et que c'est la périodicité des accès du domaine 335, à chaque page de mémoire, qui assure le maintien de la mémoire partagée. La problématique WCET du domaine 330 consiste alors seulement à calculer le WCET de programmes arbitrairement complexes, considérés individuellement, pour chacune des tranches de calcul, et indépendamment de la complexité du domaine 335. Cette décomposition en domaines 330 et 335 peut être atteinte sur des processeurs mono ou mufti-coeurs classiques pourvus de mémoires caches et de jeux d'instructions adéquats en synchronisant les unités de bus des coeurs et en leur faisant jouer le rôle du système mis en oeuvre pour maintenir la cohérence des mémoires 310-1 à 310-8. La figure 3b illustre un exemple d'architecture d'un SoC mufti-coeurs adapté à mettre en oeuvre l'invention. Le SoC 300' comprend ici les huit coeurs 305'-1 à 305'-8, génériquement référencés 305, auxquels sont associés des mémoires caches privées génériquement référencées 340, 345 et 350. Par exemple, la mémoire cache LI_I, référencée 340-1, la mémoire cache L1_D, référencée 345-1, et la mémoire cache L2, référencée 350-1, sont associées au coeur 305'-1. De façon similaire, la mémoire cache LI_I, référencée 340-8, la mémoire cache LI_D, référencée 345-8, et la mémoire cache L2, référencée 350-8, sont associées au coeur 305'-8. II en est de même pour les autres coeurs. Chaque système formé d'un coeur et de la mémoire cache privée associée est relié à un bus de données rapide, référencé 320', qui est lui-même relié aux contrôleurs de mémoire 355-1 et 355-2, génériquement référencés 355. Il convient de remarquer ici que le coeur 305'-8 est ici dédié à la gestion des entrées/sorties physiques. A titre d'illustration, les coeurs 305'-1 à 305'-8 peuvent avoir une fréquence interne de 1,6 GHz. Le bus de données reliant les coeurs aux contrôleurs de mémoire peut également utiliser une fréquence de 1,6 GHz. Ainsi, si le volume de données échangées entre les contrôleurs de mémoire et les mémoires caches, comprenant les instructions, les données écrites et les données lues, est de 192 Ko, le temps de chargement/déchargement est alors d'environ 25 �s en comptant le partage du canal entre deux coeurs et les contrôleurs de mémoire ainsi qu'au surdébit, appelé overhead en terminologie anglo-saxonne, lié aux descripteurs de configuration de la tranche suivante. Toujours selon cet exemple, le temps d'exécution des instructions, représentant environ deux tiers des données échangées, avec un ratio d'une instruction par trois cycles d'un coeur, à 1,6 GHz, est d'environ 54 �s. Par ailleurs, les applications nécessitant généralement un espace mémoire supérieur à la capacité des mémoires caches propres à chaque coeur, celles-ci doivent être découpées en plusieurs phases. Chaque phase est traitée dans une tranche d'exécution. Les volumes d'instructions et de données impliquées dans chaque tranche doivent être compatible avec la capacité des différentes mémoires caches. Le découpage doit notamment parvenir à un nombre de tranches aussi réduit que possible, avec des tranches réalisant le plus de traitements possible. Ce découpage est, de préférence, réalisé préalablement à son exécution par un atelier de génération logiciel. La figure 4, comprenant les figures 4a à 4d, illustre un exemple de mécanisme d'accès, par chaque coeur en phase de transfert d'un processeur mufti-coeurs, aux contrôleurs de mémoire de ce processeur. Comme indiqué précédemment, pour ne pas spécialiser les coeurs sur une partie des applications, il est nécessaire de séparer les phases de chargement et déchargement en lots équilibrés sur chaque contrôleur de mémoire. Ce découpage doit aussi séparer les chargements et les déchargements afin de réduire et de simplifier les combinaisons d'accès obtenues en combinant deux coeurs (combinaisons réduites à tous les coeurs en phase de chargement ou à tous les coeurs en phase de déchargement). Une considération importante de la séparation des chargements et des déchargements est la facilité de construire un modèle du fonctionnement des unités de bus des coeurs, du réseau d'interconnexion des coeurs et des contrôleurs de mémoire. Pour les coeurs eux-mêmes, établir un modèle d'unité de bus entrelaçant de façon quelconque les accès mémoire serait très difficile, construire deux demi modèles, un pour les chargements et un pour les déchargements, apparaît plus facile. Ainsi, si un processeur est complexe, il est néanmoins possible de le � simplifier � en considérant son comportement seulement sur un programme simple, ici une séquence de chargement et une séquence de déchargement non corrélés, c'est-à-dire dont la complétion d'une instruction ne bloque pas les instructions suivantes. Comme illustré sur la figure 4a, dans un premier temps, une première moitié des coeurs en phase de transfert accède au premier contrôleur et la seconde moitié accède au second contrôleur. Ainsi, les coeurs 305'-1 et 305'-2 accèdent au contrôleur de mémoire 355-2 tandis que les coeurs 305'-3 et 305'-4 accèdent au contrôleur de mémoire 355-1 et que les coeurs 305'-5 à 305'-8 sont en phase d'exécution et ne peuvent accéder aux contrôleurs de mémoire 355-1 et 355-2. Dans un second temps, comme illustré sur la figure 4b, la seconde moitié des coeurs en phase de transfert accède au premier contrôleur et la première moitié accède au second contrôleur. Ainsi, les coeurs 305'-1 et 305'-2 accèdent au contrôleur de mémoire 355-1 tandis que les coeurs 305'-3 et 305'-4 accèdent au contrôleur de mémoire 355-2 et que les coeurs 305'-5 à 305'-8 sont toujours en phase d'exécution et ne peuvent toujours pas accéder aux contrôleurs de mémoire 355-1 et 355-2. Les premier et second temps illustrés sur les figures 4a et 4b sont répétés de telle sorte que, durant une première période, les contrôleurs de mémoire 355-1 et 355-2 sont utilisés pour le déchargement de données et que, durant une seconde période, les contrôleurs de mémoire 355-1 et 355-2 sont utilisés pour le chargement de données. La première et la seconde période ont ici une durée identique, la durée de la première période étant, comme celle de la seconde, identique pour chaque contrôleur de mémoire. Ainsi, la séquence d'opérations consiste à décharger toutes les données en croisant les liens entre les contrôleurs de mémoire et les coeurs en phase de transfert à un instant donné puis à charger les nouvelles données en croisant à nouveau les liens entre les contrôleurs de mémoire et les coeurs en phase de transfert à un instant donné. Ensuite, les coeurs changent de rôle. En d'autres termes, les coeurs qui étaient en phase de transfert passent en phase d'exécution tandis que les coeurs qui étaient en phase d'exécution passent en phase de transfert. Ainsi, dans un troisième temps, comme illustré sur la figure 4c, les coeurs 305'-5 et 305'-6 accèdent au contrôleur de mémoire 355-2 tandis que les coeurs 305'-7 et 305'-8 accèdent au contrôleur de mémoire 355-1 et que les coeurs 305'-1 à 305'-4 sont en phase d'exécution et ne peuvent accéder aux contrôleurs de mémoire 3355-1 et 355-2. Ensuite, dans un quatrième temps, comme illustré sur la figure 4d, les coeurs 305'-5 et 305'-6 accèdent au contrôleur de mémoire 355-1 tandis que les coeurs 305'-7 et 305'-8 accèdent au contrôleur de mémoire 355-2 et que les coeurs 305'-1 à 305'-4 sont toujours en phase d'exécution et ne peuvent toujours pas accéder aux contrôleurs de mémoire 355-1 et 355-2. A nouveau, les troisième et quatrième temps illustrés sur les figures 4c et 4d sont répétés de telle sorte que, durant une première période, les contrôleurs de mémoire 355-1 et 355-2 sont utilisés pour le déchargement de données et que, durant une seconde période, les contrôleurs de mémoire 355-1 et 355-2 sont utilisés pour le chargement de données. La première et la seconde période ont ici une durée identique, la durée de la première période étant, comme celle de la seconde, identique pour chaque contrôleur de mémoire. Ainsi, de façon similaire, la séquence d'opérations consiste à décharger toutes les données en croisant les liens entre les contrôleurs de mémoire et les coeurs en phase de transfert à un instant donné puis à charger les nouvelles données en croisant à nouveau les liens entre les contrôleurs de mémoire et les coeurs en phase de transfert à un instant donné. La maîtrise du dénombrement des changements de page au sein des mémoires utilisées impose que deux coeurs ne devraient pas accéder, dans une même phase de transfert, aux même banques. Cela impose des contraintes supplémentaires à deux coeurs travaillant en même temps pour une même application. En pratique, cela impose que deux coeurs n'accèdent pas en même temps à la mémoire utilisée pour une application. Le serveur d'I/O, présenté ci-dessous, est un cas particulier car, par définition, il accède à toutes les applications. L'objectif est alors de placer les accès des applications à leurs I/O à des dates différentes du serveur dl/O. Chaque coeur possède, de façon permanente, c'est-à-dire verrouillée en mémoire cache, une instance d'un logiciel de supervision qui a pour objet de séquencer l'ensemble des tranches à exécuter sur le coeur. Par exemple, il réalise, pour chaque tranche d'exécution, les opérations suivantes : - lecture dans une table de configuration mémorisée dans une mémoire accédée via un contrôleur de mémoire des informations de blocs à charger dans les mémoires caches et des informations à transmettre ; - chargement des instructions, des constantes et des données dans les mémoires cache ; - exécution du contenu de la tranche ; attente de la fin de la tranche d'exécution ; et, 30. - transmission via les contrôleurs de mémoire des données modifiées. La détermination du cas de transfert le pire peut être effectuée selon deux approches : - par mesure s'il existe peu de configurations temporelles, qu'il est possible de les mesurer et de prédire, pour chaque séquence d'accès, le temps 5 de chaque accès ; et, - par construction d'un modèle du système mufti-coeurs restreint aux séquences d'instructions dans le logiciel de supervision. Il est alors possible de connaître à tout instant l'état des coeurs. Cette approche suppose cependant que les informations de conception du SoC pour modéliser le processus de 10 transfert soient connues. ll convient de rappeler ici que, conformément à l'invention, les coeurs n'ont pas accès aux contrôleurs de mémoire durant leur phase d'exécution. En d'autres termes, les coeurs n'ont aucun accès aux adresses non déjà présentes en mémoires caches. La restriction de l'exécution aux seules données et 15 instructions chargées en mémoire cache a ainsi le même effet qu'une programmation de l'unité de gestion de la mémoire, appelée MMU (sigle de Memory Management Unit en terminologie anglo-saxonne), à la granularité des lignes des mémoires caches puisque tout accès en dehors des adresses déterminées par le résultat de placement aurait pour effet de déclencher une 20 exception de violation d'accès. Si une application est à l'origine d'une erreur dans une mémoire cache, que ce soit par bug, panne ou altération de type SEU (sigle de Single Event Upset en terminologie anglo-saxonne, représentant une altération de l'état d'un bit dans une mémoire ou un registre due au passage d'un rayon 25 cosmique), le coeur est susceptible d'initier un accès aux contrôleurs de mémoires. Cependant, cet accès est dénié et provoque une exception qui est reprise par le logiciel de supervision qui désactive la tranche, le coeur ou l'application à laquelle appartient la tranche. Bien entendu, il est admis ici qu'un tel mécanisme de protection puisse être établi sur le système multi-coeurs. Un 30 SoC explicitement conçu à cet usage offre très simplement cette opportunité. Alternativement, il est possible, au niveau du système d'arbitrage du bus, de dénier les requêtes des coeurs en exécution. Une autre solution consiste à déclencher une interruption sur un accès bus observé par un moyen normalement dédié au débogage. II est également possible de cartographier, du côté des coeurs, les contrôleurs de mémoire à des adresses différentes pour des coeurs accédant à la mémoire à des instants différents et de cartographier ensuite physiquement les contrôleurs de mémoire sur les adresses attendues par les coeurs ayant à cet instant l'accès à la mémoire. De façon générale, le plus simple est que le SoC dispose d'un DMA capable de charger dans les mémoires caches ou la mémoire locale de chaque coeur les données dont il a besoin pour la prochaine tranche. Les mémoires caches contiennent, de préférence, soit des données verrouillées indéfiniment, c'est-à-dire des données verrouillées durant toute la durée de la phase temps critique, soit des données verrouillées pour la durée d'une tranche. La mémoire cache la plus proche des coeurs, réservée aux instructions, est verrouillée avec les éléments de code les plus critiques, par exemple une bibliothèque de routines appelées fréquemment. La mémoire cache la plus lointaine contient avantageusement le code applicatif et les tables de constantes les plus volumineuses qui présentent le moindre ratio usage sur volume. Les données dépendantes des tranches sont chargées dans la mémoire cache à partir d'une table de descripteurs elle-même contenue dans la mémoire accessible via un contrôleur de mémoire et chargée en mémoire cache. Il est possible de construire des tables dont l'excédent, appelé overhead en terminologie anglo-saxonne, ne dépasse pas un pourcent en volume. En fin de tranche d'exécution, la table de descripteurs sert encore à transmettre les données attendues modifiées (opération de flush). Il faut s'assurer également qu'il ne puisse exister d'effet de bord dû aux données non modifiées restées en mémoire cache, par exemple en invalidant globalement les mémoires caches (après sauvegarde si nécessaire dans une autre mémoire cache des données rémanentes verrouillées). A titre d'illustration, les mémoires caches non LRU (sigle de Least Recently Used en terminologie anglo-saxonne) ne garantissent pas que les données de l'ancienne tranche disparaîtront nécessairement au profit des données de la nouvelle tranche. Un point important pour mettre en oeuvre l'invention réside dans le bon découpage des instructions et des données pour permettre la construction de tranches de calcul utilisant au mieux les ressources des coeurs. Ainsi, chaque tranche doit, de préférence, satisfaire les conditions suivantes : - l'exécution ne doit pas produire d'erreur dans les mémoires caches c'est-à-dire que toutes les données requises par une tranche d'exécution doivent être disponibles en mémoire cache ; - les volumes d'instructions et de données doivent respecter les tailles des mémoires caches ; - le temps d'exécution le pire, ou WCET, doit être inférieur à la durée des tranches d'exécution ; et, - l'exécution doit respecter les contraintes d'ordonnancement. De plus, les traitements doivent être raisonnablement sécables et non fortement séquentiels, afin de laisser quelques degrés de liberté à la solution de placement, et le ratio entre instructions et données, c'est-à-dire la densité de calcul, doit de préférence être élevé afin que la solution soit efficace. En d'autres termes, lorsque les mémoires caches sont chargées en instructions et en données, il doit être possible aux coeurs d'exécuter un grand nombre d'instructions avant de devoir revenir sur le bus pour mettre à jour leur mémoire cache. Ainsi, par exemple, il est souhaitable de ne pas utiliser de fonction nécessitant de grandes tables de données ce qui aurait pour effet de bloquer une grande partie de la mémoire cache pour seulement quelques instructions. Cependant, de nombreuses applications avioniques telles que les applications de commande de vol électrique sont écrites sous forme de planches, par exemple de planches SCADE (SCADE est une marque), qui possèdent de telles propriétés. De plus, à l'exception de certaines contraintes temporelles, l'ordonnancement des planches est libre. Le placement des traitements en tranches est réalisé hors ligne, c'est-à-dire avant l'exécution des tranches, par un outil de la chaîne de génération logicielle. Le principe est de recourir aux différentes méthodes disponibles d'optimisation multi-objectifs sous contraintes afin de résoudre de manière statique un placement d'instructions et de données. Le placement hors ligne des traitements en tranches d'exécution est essentiel pour trouver une solution aussi optimale que possible. II permet de produire une amélioration du WCET, voire l'obtention du minimum, pour l'application concernée tout en bénéficiant de l'amélioration du déterminisme due aux contraintes de localité des données définies précédemment. Avantageusement, l'application de résolution de contraintes permet de restreindre les expressions mathématiques à des équations linéaires afin de résoudre le système d'équations et optimiser une fonction (recherche opérationnelle). La solution est ici, de préférence, restreinte aux solutions entières. Une telle solution, appelée programmation linéaire en nombres entiers (PLNE) ou Integer Linear Programming (ILP) en terminologie anglo-saxonne, vise à exprimer un problème par système d'équations et/ou d'inéquations linéaires à solutions (partiellement) entières. Une résolution de type PLNE peut se faire par la méthode du 15 simplexe que peuvent proposer des outils d'optimisation combinatoire, complétée d'heuristiques pour rendre le problème calculable. Pour faciliter le travail de l'application de résolution de contraintes, il est préférable de simplifier le problème ou de le découper en plusieurs sous-problèmes plus simples. 20 Selon un mode de réalisation particulier, il est demandé à l'application de résolution de contrainte de choisir une tranche pour chaque planche. L'indice i, variant de 1 à s, désigne ici les numéros de tranches tandis que l'indice j, variant de 1 à N, désigne les numéros de planches aussi appelées noeuds, c'est à dire les fractions insécables de l'application. 25 Il est défini une variable booléenne N désignant l'état d'un noeud tel que Nj,i = 1 si le noeud j est placé dans la tranche i et que Nj,i = 0 si le noeud j n'est pas placé dans la tranche i. Nj,i est dit "variable de décision" indiquant la décision de placement du noeud Nj. Chaque noeud Nj est caractérisé par un volume d'instructions et de 30 constantes de taille importante, appelé L2j, propres au noeud j, à placer en mémoire cache L2 ainsi que par un volume de variables et de constantes de petite taille, appelé L1 j, propres au noeud j, à placer en la mémoire cache de données L1 D. Chaque noeud Nj est également caractérisé par une liste des variables partagées avec d'autres noeuds et par un pire temps d'exécution WCETj. Les constantes de taille importante, par exemple des tables d'interpolation, sont à placer dans la mémoire cache L2 afin de ne pas épuiser la capacité de la mémoire cache L1 D. Le choix du seuil de transition entre les mémoires caches L2 et L1 D est déterminé par l'outil de placement. L'expression des contraintes de taille sur les mémoires caches L2 et L1 D est donnée ici à titre d'exemple et correspond à un placement sur deux ressources ayant des caractéristiques différentes, l'une, rapide pour les données peu abondantes, est à réserver aux données critiques au temps d'exécution tandis que l'autre est à utiliser pour les instructions et les données moins critiques. Ce principe peut être adapté à d'autres répartitions des ressources. Il est alors nécessaire de prendre en considération les contraintes 15 suivantes, exprimées sous forme d'inéquations linéaires, - chaque tranche ne doit pas excéder la capacité MAXL2 de la mémoire cache L2 : pour tout i, L21 * N1,; + L22 * N2,1 + ... + L2N * NN,i MAXL2 N soit, Vi, E L2j x Ni , MAXL2 j=1 20 chaque tranche ne doit pas excéder la capacité MAXL1 D de la mémoire cache LI D : pour tout i, L11 * N1,1 + L12 * N2,1 + ... + LIN * NN,i + RESVLI D - chaque tranche ne doit pas excéder un temps maximum 25 d'exécution MAXWCET : pour tout i, WCETI * Nl,1 + WCET2 * N21 1 + ... + WCETN * NN,i _ Il est également nécessaire de forcer la solution de placement à inclure une et une seule fois chaque noeud dans chaque tranche, pour tout j, N1,1 + N1,2 + ... + Ni,s = 1 s soit, Vj,ENj; =1 i=i Il convient de noter ici que la mémoire cache L1 D n'est pas seulement utilisée pour les constantes de petite taille et les variables mais également pour les variables partagées entre plusieurs noeuds. La valeur RESVLI D représente cet espace. Dans une approche simplifiée du problème, séparant le problème de placement des noeuds du problème de placement des variables, il est conseillé de choisir une valeur fixe aboutissant à une solution réalisable et satisfaisante. Dans une solution combinant l'optimisation du placement des noeuds et des variables, RESVLI D est choisi comme représentant exactement l'occupation des variables en mémoire cache LI D. Lorsqu'une contrainte d'ordonnancement existe entre deux noeuds, par exemple si Nj doit être exécuté avant Nk, la série de contraintes suivante est ajoutée (il existe un Nk,i pour chaque tranche candidate au placement) : pour tout j, k tel que j doit précéder k, pour tout i >_ 2, Nk,; + Nk,;+1 + ...+ Nk,s >û Ni,i S soit E N/0 t=r Ainsi, si Nj est placé dans la tranche i, alors Nk doit aussi être placé dans la tranche i ou dans l'une des suivantes. S'il existe par ailleurs des contraintes interdisant le placement séparé de deux noeuds (noeuds insécables), ils peuvent alors partager la même variable de décision. Par ailleurs, en plus de partager des variables, les noeuds peuvent partager des constantes. Dans une représentation exhaustive du problème, il est possible d'exprimer de façon précise les décisions de placement de ces constantes. Cependant, le partage des constantes de petite taille n'est en général pas très dimensionnant et ne justifie pas de complexifier le problème. Les constantes de petite taille peuvent être dupliquées, c'est-à-dire trouver des solutions différentes dans chaque tranche, sans coût significatif, en utilisant des emplacements non utilisés dans la répartition des variables en mémoire. Les constantes de taille importante, généralement peu nombreuses, par exemple 26 des tables d'interpolation trigonométriques, justifient néanmoins une recherche d'optimisation. La variable Cc,i est définie comme égale à un si la constante Cc est référencée dans la tranche i. Dans le cas contraire elle est égale à zéro. Une contrainte sur Cc,i est ajoutée de la façon suivante, pour toute tranche i, pour tout noeud j référençant Cc, Cc,i Nj,i Ainsi, à partir du moment où le noeud j utilisant Cc est placé dans la tranche i, Cc,i est forcé à 1. Il convient de remarquer que Cc,i n'est pas réellement une variable de décision, c'est une conséquence de la décision de placement des noeuds Nj. Les constantes de taille importante étant, par exemple, placées en mémoire cache L2, la contrainte sur la mémoire cache L2 est reformulée de la façon suivante, pour tout i, L21 * Nl,1 + L22 * N2,i + ... + L2N * NN,; + ... + sizeof(Cc) * Cc,i + ... Le même formalisme peut être appliqué pour toute variable partagée 20 Vv. En d'autres terme, Vv,i = 1 si la variable Vv est référencée dans la tranche i sinon Vv,i = 0. Une contrainte est également ajoutée sur Vv,i de la façon suivante, pour toute tranche i, pour tout noeud j référençant Vv, Vv,i Nj,i Pour restreindre la complexité globale du placement, il est possible 25 de subdiviser le problème en recherchant d'abord une solution de placement des noeuds présentant des critères de regroupement des références aux variables (et constantes) et en recherchant une solution minimisant la somme des Vv,i sur toutes les variables Vv et toutes les tranches i. Il est ainsi nécessaire de minimiser la relation suivante, N S 30 EV = E E VL, j=I II convient de remarquer que cette fonction n'a pas pour objet de minimiser le cas le pire de remplissage des tranches. En pratique, minimiser le nombre de références aux variables consiste au contraire à maximiser l'occupation de certaines tranches. Il peut être souhaitable cependant de conserver une certaine marge dans la mémoire cache dans chaque tranche afin d'accepter des modifications du logiciel à placer sans avoir à relancer l'outil de placement et obtenir éventuellement un placement complètement différent du précédent. Ceci est notamment utile dans une optique de qualification et vérification incrémentale où il n'est alors pas nécessaire de tester à nouveau les parties de logiciel non modifiées. Pour le placement des variables, des variables de décision sont définies de la façon suivante : Mv,b = 1 si la variable Vv est placée dans le bloc b sinon Mv,b = 0, b étant un index de bloc variant de 1 à B (un bloc est ici une ligne de mémoire cache ou un groupe de lignes de mémoire cache). Plus les blocs sont grands, plus il est difficile de trouver des placements utilisant efficacement l'espace des blocs. Par contre, la complexité du problème est réduite (moins de variable de décision) et l'efficacité des opérations de mémoire cache améliorée. Il en résulte les contraintes suivantes, exprimées sous forme 20 d'équations linéaires : - ne pas allouer de variables dans un bloc au-delà de sa capacité MAXBLOC, pour tout bloc b, sizeof(VI) * M1,b + ... + taille(Vv) * M,,,b + ... Pour une optimisation conjointe du placement des noeuds et des variables, il est alors possible de compléter la seconde contrainte évoquée en remplaçant la valeur RESVLI D par l'allocation de blocs destinés aux variables. II est alors nécessaire de minimiser la valeur USAGE (où USAGE MAXL1 D) en respectant les contraintes suivantes, pour tout i, L11 * Nl,1 + L12 * N2,; + ...+ LIN * NN,; + BLK SZ * (Hl,1 + ...+ HB,; - B) Selon un mode de réalisation particulier, il est possible de simplifier le problème en découpant les noeuds ou les variables en plusieurs sous-ensembles. Ce choix de découpage préalable peut être orienté par le concepteur du logiciel à placer, par exemple parce qu'il sait que son application est composée de trois sous-systèmes largement indépendants, ou par l'outil de placement suivant des heuristiques, par exemple en identifiant des noeuds référençant les même variables. Chaque sous problème fait alors l'objet d'un placement indépendant de ses noeuds et de ses variables propres. Un dernier placement des variables partagées termine la résolution du problème. Par exemple, les noeuds peuvent être découpés en plusieurs sous-ensembles selon des périodicités. Les tranches sont alors ordonnancées à la périodicité des noeuds. Il est également possible de découper la spécification utilisée en blocs fonctionnels relativement indépendants. D'autres alternatives sont possibles, notamment en exprimant un système préalable de contraintes visant à distribuer les noeuds en un petit nombre de sous-systèmes plutôt que de distribuer directement les noeuds dans un grand nombre de tranches. L'optimum recherché pouvant être dégradé par les heuristiques (choix de simplification) mises en places, des méthodes non exhaustives peuvent être employées afin de résoudre le problème d'optimisation combinatoire que représente le problème de placement. Tout en conservant les fonctions objectifs précédemment décrites et les contraintes liées à l'architecture mise en oeuvre, des méthodes d'optimisation telles que l'algorithme d'estimation de distribution, appelé estimation of distribution algorithm en terminologie anglo-saxonne, les méthodes basées sur le principe d'algorithme évolutionnaire (ou algorithme génétique), les réseaux de neurones ou bien un algorithme à essaim de particules, appelé particle swarm optimizer en terminologie anglo-saxonne, peuvent être utilisées. L'optimisation combinatoire étant un sujet de recherche fortement 30 exploré et en constante évolution, de nombreuses approches sont disponibles, offrant chacune leurs avantages et inconvénients. S'agissant d'un algorithme d'estimation de distribution, l'idée est ici de rechercher une optimisation de placements de noeuds puis de variables, ou même de variables uniquement, les fonctions objectifs permettant la recherche itérative d'une meilleure solution étant notamment les objectifs de minimalité d'échanges de données entre les tranches et les objectifs de minimisation du temps d'exécution par une localisation très fine des données (minimiser le nombre de lignes de mémoires caches qu'une séquence de calcul doit charger ou décharger au niveau d'une mémoire cache LI au sein d'une tranche d'exécution). La présence de contraintes de différentes natures peut conduire à envisager une recherche d'optimum s'appuyant sur plusieurs méthodes d'optimisation. Par exemple, concernant l'application de commande de vol, il est possible de distinguer des objectifs et contraintes visant à améliorer le WCET par une localisation fine des données des contraintes d'ordonnancement et de séquentialité d'ensembles de traitements. Ces dernières présentant plus de difficultés pour un algorithme d'estimation de distribution mais ne concernant pas l'ensemble des traitements, elles peuvent faire l'objet d'un traitement différent. Là encore, l'état de l'art concernant l'optimisation combinatoire permet d'adopter un ensemble de démarches donnant des résultats plus ou moins satisfaisants selon les contraintes de l'application considérée et de l'architecture matérielle envisagée afin d'obtenir le découpage en tranches de calculs recherché. Selon le système de l'invention, les tranches de calcul n'ont aucun accès aux entrées/sorties, appelées I/O, physiques. Elles ne peuvent accéder qu'aux variables ayant été transférées en mémoire cache par le logiciel de supervision. Ainsi, comme illustré sur la figure 3b, un coeur, ou plusieurs si nécessaire, est de préférence dédié à la gestion des I/O physiques. Ce coeur, appelé coeur I/O, héberge une fonction de type � serveur d'I/O � par opposition aux autres coeurs qui peuvent être considérés comme des � serveurs de calcul �. Le coeur I/O produit les variables correspondant aux entrées déformatées du module et consomme les variables correspondant aux sorties non formatées du module. Si la charge de calcul due aux fonctions de formatage du coeur I/O est trop importante, il est envisageable d'attribuer ces formatages aux coeurs de calcul et de laisser uniquement les transferts de données sur les bus externes du SoC au serveur dl/O. Vu des coeurs de calcul, le coeur I/O est un coeur producteur et consommateur de données banalisées. Les activités du serveur d'I/O couvrent les opérations d'accès aux registres physiques et aux contrôleurs de bus, par exemple à des contrôleurs Ethernet, PCIe ou à une mémoire non volatile, et les opérations de vérification et de conversion de données vers les structures et types de données connues des applications. Ces opérations sont définies par des tables de configuration, chargées durant les tranches de transfert, planifiées par l'outil de placement, en même temps que la planification des chargements des tranches de calcul. Le coeur I/O possède son logiciel et certaines données, de façon résidente, et utilise ses phases de transfert pour charger et décharger les valeurs des entrées et sorties proprement dites ainsi que les éléments de table de configuration nécessaires à leur traitement. Le coeur I/O est, de préférence, le seul coeur ayant accès aux bus de type PCIe, Ethernet ou autre. Etant le seul, et sous réserve que ses accès ne perturbent pas les accès des coeurs de calcul aux contrôleurs de mémoire, le coeur I/O dispose de l'usage de ces bus à temps plein. Par contre, étant banalisé du point de vue des accès aux contrôleurs de mémoire, il dispose de tranches et de plages d'accès strictement statiques, planifiées en même temps que la planification des accès des coeurs de calcul. Par ailleurs, si des contrôleurs de bus doivent effectuer des transferts de données de type DMA, ils doivent pouvoir atteindre des cibles mémoires sans perturber les coeurs de calcul en phase de transfert. Ainsi, selon un mode de réalisation particulier, un composant mémoire doit être disponible afin que ces transferts DMA puisse être réalisés sans affecter la mémoire utilisée par les coeurs de calcul. Ce composant peut être la mémoire cache, de préférence dans celle du coeur I/O, qui est utilisée comme cible. Ce peut être aussi une autre mémoire cache ou zone mémoire accessible par adressage dans le SoC, éventuellement même un plan de mémoire externe adressé par un contrôleur mémoire dédié. Les activités du serveur dl/0 sont découpées en tranches d'exécution et de transfert, strictement synchrones, équilibrées et planifiées, comme les activités des coeurs de calcul (ou coeurs applicatifs). Le coeur I/O utilise ses tranches de transfert pour lire les tables de configuration, déposer les entrées en mémoire et récupérer les sorties. Les tranches d'exécution sont dédiées au pilotage des contrôleurs de bus. La distribution des opérations par tranche est réalisée par l'outil hors ligne de placements décrit précédemment, dans le respect des capacités de traitement du coeur I/O et des contrôleurs de bus, en cohérence de temps avec les applications. A ces fins, l'architecture du SoC doit offrir une ségrégation suffisante de chemins pour les échanges entres le coeur I/O et les contrôleurs de bus durant les tranches d'exécution pour éviter d'interférer avec les échanges entre la mémoire et les coeurs de calcul en phase de transfert. Les entrées physiques du serveur d'I/O peuvent être classées en deux familles : - les entrées synchrones des applications qui sont acquises sur l'initiative des applications et qui peuvent être placées à temps dans des tranches du serveur dl/O. Ces entrées consistent généralement en la lecture d'un ou de plusieurs registres pour recevoir une information ; et, - les entrées asynchrones des applications qui sont acquises selon des évènements extérieurs, non corrélés avec l'exécution des applications. Leur acquisition ne peut donc être planifiée de façon entièrement déterministe comme les traitements applicatifs ou les entrées synchrones. Ces entrées consistent généralement en trames ou messages reçus sur des bus numériques tel qu'Ethernet. Seules les sorties synchrones, c'est-à-dire les sorties émises ou générées sur l'initiative des applications, sont ici considérées. Cependant, pour les éventuelles sorties asynchrones, par exemple une sortie d'un dispositif interrogé par le contrôleur d'un bus asynchrone du séquencement des tranches, il est possible de considérer que le dispositif dispose d'une boîte aux lettres conservant les données déposées. La dépose de données en boîte aux lettres est synchrone des tranches tandis que l'émission sur le bus est asynchrone. Ainsi, hormis les entrées asynchrones, il est possible d'établir une planification statique, via l'outil hors ligne, pour déterminer les accès aux tables de configuration, aux variables d'entrées/sorties et les activités de pilotage des contrôleurs d'I/O. Pour les entrées asynchrones, le serveur dl/0 doit disposer d'un élément de tables de configuration à résidence dans ses mémoires caches privées. Cet élément doit lui permettre de corréler l'arrivée non planifiée de l'événement avec une requête d'accès à une zone mémoire précise, puis d'utiliser ultérieurement une date planifiée d'accès à cette zone pour acquérir, si nécessaire, les éléments supplémentaires de tables de configuration et déposer les données reformatées ou non correspondant à l'événement. Les données brutes doivent être conservées en mémoire cache entre l'instant d'arrivée et l'ouverture de l'accès mémoire. L'arrivée de l'événement est non planifiée dans le sens où l'instant auquel il doit arriver est inconnu. Cependant, l'existence même de l'événement est planifiée des adresses en mémoire et des opportunités d'accès planifiés à la mémoire lui ont été attribuées. Si les tranches d'exécution sur les coeurs de calcul sont regroupées de façon à ce qu'une seule application soit active à la fois sur l'ensemble des coeurs, il est possible de réserver sur le serveur dl/0 une tranche prologue pour les entrées et une tranche épilogue pour les sorties de façon à ce que le serveur dl/0 puisse être considéré pendant toute cette durée à l'usage exclusif de l'application active. Cette alternative selon laquelle tous les coeurs sont dédiés à une application pendant une durée déterminée, c'est-à-dire plusieurs tranches, nécessite que soient résolu les problèmes de déterminisme des contrôleurs de mémoire dus aux changements de page. II peut l'être, par exemple, par l'utilisation d'un modèle suffisamment précis des contrôleurs de mémoire appliqué aux listes de transferts mémoire requis par chaque tranche. Cette alternative nécessite également que les applications ainsi distribuées disposent d'une liberté d'ordonnancement suffisante pour pouvoir être distribuées efficacement sur tous les coeurs de façon parallèle. Alternativement, la mixité des applications sur les différents coeurs de calcul peut être autorisée. Dans ce cas, les tranches du serveur dl/0 précédant ou suivant les tranches de calcul sont dotées de ressources de temps CPU et d'accès bus statiques (équivalents à des micropartitions). Ces ressources sont connues de l'outil de placement des applications de façon à ce que celles-ci n'excèdent pas leurs ressources attribuées. Si le SoC dispose de plusieurs contrôleurs Ethernet, il est possible de réaliser des entrées/sorties AFDX ou Erebus de façon logicielle. Ces implémentations doivent cependant rester compatibles avec les contraintes de staticité et de déterminisme nécessaires au découpage en tranches de calcul. A ces fins, les contrôleurs Ethernet ne doivent pas accéder à la mémoire centrale utilisée par les coeurs de calcul et doivent travailler avec une mémoire et des ressources bus indépendantes. Les ressources type bus peuvent éventuellement être partagées s'il existe une gestion de priorités � instantanée � capable de servir les requêtes des coeurs applicatifs sans préemption, or retard observable, en cas de conflit, avec les accès des contrôleurs Ethernet ou le serveur d'I/O, et sans mettre en défaut les analyses WCET du serveur dl/O. Cette approche implique que les accès des contrôleurs Ethernet puissent être transparents vis-à-vis des coeurs de calcul. Pour des raisons de performance, il est aussi souhaitable que les données écrites par les bus externes, par exemple Ethernet ou PCle, soient transférées dans la mémoire locale du serveur dl/O. Ce transfert peut être réalisé soit directement par le DMA du contrôleur Ethernet soit par un mécanisme équivalent à celui utilisé pour le pré-chargement des mémoires caches. Les opérations d'émission et de réception AFDX sont de préférence adaptées pour être réalisées dans le coeur IO en respectant les contraintes suivantes : - le coeur IO doit respecter le concept de tranches de communication et de tranches de traitement ; - les contrôleurs Ethernet ne doivent pas perturber les contrôleurs de mémoire ni les autres coeurs ; et, - les mémoires caches du coeur IO étant trop petites pour stocker entièrement la configuration et les variables liées à l'interface AFDX, elles 5 doivent être chargées par portions. Durant la réception de données, les paquets reçus par les contrôleurs Ethernet sont stockés dans la mémoire du coeur 10. Ils sont analysés au fur et à mesure de leur réception puis transférés dans d'autres files d'attente. Une table de configuration résidant dans la mémoire locale du 10 serveur dl/0 est utilisée pour associer les identifiants des liens virtuels (ou VL, sigle de Virtual Link en terminologie anglo-saxonne), appelés VLID, des trames reçues à une ou plusieurs des fenêtres planifiées d'accès à la mémoire pour le serveur d'I/O. Il existe une fenêtre pour déposer la partie applicative de la trame en mémoire et, éventuellement, une ou plusieurs autres fenêtres pour lire les 15 éléments de tables de configuration nécessaires à l'identification et au traitement complet de la trame tels que les adresses IP/UDP (sigle d'internet Protocol / User Datagram Protocol en terminologie anglo-saxonne) de destination pour l'identification du port de destination, le type et l'adresse de stockage du port en mémoire et les informations de surveillance du réseau. La 20 table de configuration résidant dans la mémoire locale du serveur d'I/O, dont la taille est de l'ordre de quelques kilos octets, est utilisée pour chaque trame Ethernet reçue. La gestion de la redondance et de l'intégrité utilise avantageusement des ressources également conservées dans la mémoire locale du serveur d'I/O. Si la recherche des ports nécessite une table trop 25 grande pour être stockée en mémoire locale, les éléments de cette table, nécessaires au traitement du VL identifié par la table de configuration résidant dans la mémoire locale du serveur d'I/O, sont chargés dans les tranches de lecture mémoire du serveur d'I/O autorisées à ce VL et seuls les paquets en attente correspondant à ces VLs sont traités. Si la capacité de la mémoire 30 locale du serveur d'I/O le permet, il est préférable pour des raisons de simplicité et réduction de latence de laisser à résidence ces tables dans le serveur dl/O. Les activités d'émission du serveur dl/0 sont planifiées par l'outil de placement utilisé pour le placement des traitements applicatifs dans les tranches et pour le placement des tranches sur les coeurs. Durant l'émission, la configuration associée à un VL est chargée dans la mémoire locale au cycle planifié, ainsi que l'état des ports qui lui sont associés. Si les conditions d'émission sont respectées, l'émission est déclenchée dans le cycle à un instant définit par la configuration. De façon similaire, si la mémoire locale du serveur d'I/O le permet, il est préférable de laisser à résidence les tables de configuration nécessaires aux émissions. La figure 5 illustre schématiquement un CPM, dont l'architecture est fondée sur un processeur mufti-coeurs tel que celui présenté sur la figure 3b, adapté à mettre en oeuvre l'invention où les fonctions AFDX sont gérées de façon logicielle dans le processeur multi-coeurs. Comme illustré, le CPM 500 comprend le processeur mufti-coeurs 505 ayant ici, en particulier, huit coeurs et deux contrôleurs de mémoire. Ces contrôleurs de mémoire sont utilisés comme interface entre les coeurs et les mémoires 510-1 et 510-2. Le CPM 500 comprend en outre une mémoire 515, par exemple une mémoire flash, pour stocker, par exemple, certaines des applications devant être exécutées par les coeurs du processeur 505. Le CPM 500 comprend en outre une interface réseau pour recevoir et transmettre des données, en particulier une interface AFDX, ainsi que la logique nécessaire au fonctionnement du CPM. La fonction AFDX est ici réalisée par le processeur mufti-coeurs, c'est-à-dire de façon logicielle. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS1. Procédé de chargement et d'exécution à cycles d'exécution déterministes d'une pluralité d'instructions dans un système avionique comprenant au moins un processeur ayant au moins deux coeurs (305, 305') et au moins un contrôleur de mémoire (355), chacun desdits au moins deux coeurs disposant d'une mémoire privée (310, 340, 345, 350), ce procédé étant caractérisé en ce que ladite pluralité d'instructions est chargée et exécutée par tranches d'exécution et en ce qu'il comprend les étapes suivantes, - durant une première tranche d'exécution, o autorisation d'accès audit au moins un contrôleur de mémoire à un premier desdits au moins deux coeurs, ledit premier coeur transmettant (215) audit au moins un contrôleur de mémoire au moins une donnée mémorisée dans sa mémoire privée, préalablement modifiée, et recevant (220) au moins une donnée et au moins une instruction de ladite pluralité d'instructions, ladite au moins une donnée et ladite au moins une instruction reçues étant mémorisées dans sa mémoire privée ; o interdiction d'accès audit au moins un contrôleur de mémoire à un second desdits au moins deux coeurs, ledit second coeur exécutant (210) au moins une instruction préalablement mémorisée dans sa mémoire privée ; durant une seconde tranche d'exécution, o interdiction d'accès audit au moins un contrôleur de mémoire audit premier coeur, ledit premier coeur exécutant (235) au moins une instruction préalablement mémorisée dans sa mémoire privée ; et, o autorisation d'accès audit au moins un contrôleur de mémoire audit second coeur, ledit second coeur transmettant (225) audit au moins un contrôleur de mémoire au moins une donnée mémorisée dans sa mémoire privée, préalablement modifiée, et 20 25 30recevant (230) au moins une donnée et au moins une instruction de ladite pluralité d'instructions, ladite au moins une donnée et ladite au moins une instruction reçues étant mémorisées dans sa mémoire privée. 2. Procédé selon la revendication 1 selon lequel ledit au moins un processeur comprend en outre au moins un second contrôleur de mémoire, le procédé comprenant en outre les étapes suivantes, - durant une première phase de ladite première tranche d'exécution, autorisation d'accès à un premier desdits au moins deux contrôleurs de mémoire audit premier coeur et interdiction d'accès à un second desdits au moins deux contrôleurs de mémoire audit premier coeur ; - durant une seconde phase de ladite première tranche d'exécution, autorisation d'accès audit second contrôleur de mémoire audit premier coeur et interdiction d'accès audit premier contrôleur de mémoire audit premier coeur ; - durant une première phase de ladite seconde tranche d'exécution, autorisation d'accès audit premier contrôleur de mémoire audit second coeur et interdiction d'accès audit second contrôleur de mémoire audit second coeur ; et, - durant une seconde phase de ladite seconde tranche d'exécution, autorisation d'accès audit second contrôleur de mémoire audit second coeur et interdiction d'accès audit premier contrôleur de mémoire audit second coeur. 3. Procédé selon la revendication 1 ou la revendication 2 selon lequel au moins un desdits au moins deux coeurs est dédié à des opérations de transmission et de réception de données vers et depuis une interface de communication réseau. 4. Procédé de traitement d'une pluralité d'instructions pour permettre le chargement et l'exécution à cycles d'exécution déterministes de ladite pluralité d'instructions selon l'une quelconque des revendications précédentes, le procédé de traitement comprenant une étape de découpage de ladite pluralité d'instructions en tranches d'exécution, chaque tranche d'exécution comprenant une séquence de transfert et une séquence d'exécution, ladite séquence de transfert permettant la transmission d'au moins une donnée préalablement mémorisée et la réception et la mémorisation d'aumoins une donnée et d'au moins une instruction, ladite au moins une donnée reçue étant nécessaire à l'exécution de ladite au moins une instruction reçue et permettant l'exécution de ladite au moins une instruction reçue, de façon autonome, durant l'exécution de ladite séquence d'exécution. 5. Procédé selon la revendication précédente selon lequel ladite étape de découpage est basée sur la résolution d'un système d'équations linéaires représentant des contraintes d'exécution des instructions de ladite pluralité d'instructions selon au moins une caractéristique d'un processeur adapté à exécuter lesdites tranches d'exécution. 6. Procédé selon la revendication 4 ou la revendication 5 selon lequel la durée desdites tranches d'exécution est constante et prédéterminée. 7. Procédé selon la revendication précédente selon lequel ladite durée est déterminée par le temps de transmission de données préalablement modifiées et le temps de réception de données et d'instructions à exécuter. 8. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté un processeur. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre 20 de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 7. 10. Aéronef comprenant le dispositif selon la revendication précédente.