Par processeur, on entend dans le présent document toute unité de ressource d'exécution. L'invention n'est pas limitée aux seuls processeurs logiciels et matériels, utilisés dans les systèmes électroniques et informatiques, mais s'applique également aux processeurs mécaniques (par exemple un robot qui exécute une ou plusieurs tâches) ou humains (par exemple un opérateur qui exécute une ou plusieurs tâches).

Par ailleurs, dans le présent document, on entend par ordonnanceur une fonction capable d'établir un ordre d'exécution de fonctions ou tâches pour un processeur utilisé comme ressource. Cette fonction peut être réalisée sous forme logicielle et/ou matérielle, pour les processeurs matériels et logiciels, ou par toute autre technique pour les autres types de processeurs (mécaniques et humains).

Ces systèmes complexes permettent notamment, mais non exclusivement, de faire fonctionner des programmes informatiques, aussi appelés applications ou logiciels. Plus précisément, l'invention concerne une technique de simulation d'un tel système complexe. En d'autres termes, la technique de l'invention concerne la conception et l'exploration des architectures des systèmes complexes.

La technique de l'invention a été développée pour l'étude des architectures des systèmes électroniques complexes, qu'il s'agisse de cartes ou de systèmes intégrés dans une puce (ou SoC, pour « System-on-Chip »). Ces systèmes intègrent systématiquement du matériel et du logiciel.

Cependant, du fait que la technique de l'invention repose sur des concepts généraux de tâche (fonction), de processeur (et donc de ressource d'exécution) et d'ordonnanceur, elle a une application plus large que celle des microprocesseurs. Elle couvre tout type de processeurs (voir la définition ci-dessus) devant assurer du partage de ressources.

La technique de l'invention se veut tout particulièrement adaptée aux technologies nouvelles des télécommunications et du multimédia. L'évolution des standards et leur stabilisation progressive conduisent à devoir créer des équipements évolutifs et donc « téléconfigurables ». La configuration dynamique et donc l'ordonnancement dynamique sont des solutions permettant de répondre à l'évolution des fonctionnalités des produits.

Dans les systèmes électroniques et informatiques, les systèmes complexes sont réalisés par assemblage de composants matériels : processeurs standards (ou CPU, pour « Central Processing Unit »), microprocesseurs (ou MCU, pour « Microcontroller Unit »), processeurs de traitement du signal (ou DSP, pour « Digital Signal Processor »), circuits intégrés à application spécifique (ou ASIC, pour « Application-specific Integrated Circuits »), réseaux logiques programmables, notamment réseaux prédiffusés programmables (ou FPGA pour « Field Programmable Gâte Arrays »), constituant ainsi la plate-forme matérielle du système. S'ajoute à cette plate-forme un ensemble de logiciels (généralement des systèmes d'exploitation temps réel, comprenant notamment un ordonnanceur) développés pour chaque processeur logiciel (CPU, MCU, DSP), ainsi que la configuration des processeurs matériels (ASIC, FPGA). L'ensemble de ces constituants (matériels et logiciels) une fois intégrés (tendance vers les systèmes sur silicium - « System-On-Chip ») constitue un système complexe dont il est quasi impossible de prévoir le comportement détaillé ainsi que certaines propriétés, telles que leurs performances.

La conception de systèmes complexes est une activité en amont de la réalisation, intégration et test, qui requiert de la part des ingénieurs de prévoir très tôt les propriétés du système à développer afin de décider toutes les caractéristiques des constituants. Avec l'accroissement de la complexité et la réduction du temps de développement, les concepteurs doivent disposer d'outils d'aide à la conception (CAO). La technologie de l'invention répond à un tel besoin.

La prévision des propriétés de tels systèmes en termes de performances au sens général, résulte de la simulation de modèles abstraits représentant au mieux les systèmes électroniques complexes pouvant mixer des processeur matériels (FPGA, ASIC) et des processeurs logiciels (CPU, MCU, DSP). La nature même des systèmes électroniques

actuels et ceux du futur, qui résultent de l'intégration de logiciels temps réel s'exécutant sur un ou plusieurs processeurs eux-mêmes couplés avec un environnement matériel complexe et très varié, conduit à devoir disposer de techniques de simulation rapides et performantes afin de vérifier et valider le plus efficacement et le plus tôt possible les solutions durant leur conception. Pour cette raison, les technologies de simulation sont très critiques pour l'industrie de la conception électronique assistée par ordinateur (ou EDA, pour « Electronic Design Automation »). 2. Art antérieur

Un moyen actuel de pouvoir résoudre le problème de la prédiction des performances durant la conception des systèmes complexes consiste à construire des modèles de ces systèmes en amont du développement, et ceci à des niveaux d'abstraction de plus en plus hauts. Partant d'un modèle purement comportemental décrit par des blocs fonctionnels et/ou des algorithmes en C, C++, SystemC, le modèle est progressivement enrichi par des propriétés temporelles ainsi que par la description des constituants de la plate-forme matérielle, afin de pouvoir conduire des études d'architectures et effectuer l'analyse de leurs performances.

La technique usuelle consiste à utiliser les langages informatiques C++/SystemC comme moyen de description des modèles de systèmes au niveau d'abstraction dit transactionnel. Chaque modèle se développe plutôt d'une manière manuelle par écriture directe du code source C++. La création du modèle pour l'étude architecturale se développe par raffinements ou enrichissements successifs, ce qui conduit à un modèle complexe nécessitant un temps important de création, vérification, ceci avant son utilisation pour extraire des résultats.

La technique actuelle de simulation pour la modélisation de l'effet d'un exécutif temps réel (ou d'un système d'exploitation), qui gère le partage de la ressource CPU et l'ordonnancement des tâches demandant la ressource, se fait généralement en utilisant directement le code objet (ou machine) de cet exécutif temps réel (ou de ce système d'exploitation). Cette technique de simulation est dite native du fait que le code de l'exécutif temps réel (ou du système d'exploitation) est exécuté directement sur le calculateur de simulation. Dans ce cas, il faut disposer d'un modèle du processeur du niveau jeu d'instructions, aussi appelé modèle ISS (« Instruction Set Simulator »). Une

autre solution connue de simulation native consiste à utiliser un simulateur d'exécutif temps réel (ou de système d'exploitation) sur une station de travail de type PC ou UNIX (marque déposée).

De plus, la création d'un modèle architectural mixant le comportement de l'application avec le comportement du système complexe (y inclus les exécutifs temps réel et/ou les systèmes d'exploitation) est une tâche laborieuse et très coûteuse en temps. Ainsi, toute modification de l'application ou du système complexe nécessite du temps de développement et de vérification. L'emploi mixte de processeurs logiciels (chacun exploitant un exécutif temps réel ou un système d'exploitation) et de processeurs matériels (par exemple des processeurs programmables et reconfigurables du type

FPGA) complique encore le travail de création de modèles. Cette difficulté freine sérieusement les entreprises à investir dans de tels développements, ce qui veut dire que l'exploration d'architectures ne se fait pas et qu'en conséquence, les performances des choix architecturaux ne se découvrent que très tard dans le cycle de développement avec un risque très important de voir des contraintes non satisfaites.

Un premier inconvénient majeur des techniques connues est le temps important et la forte compétence requis pour développer de tels modèles du fait du développement manuel.

Un deuxième inconvénient essentiel des techniques connues résulte du fait que le modèle développé est monolithique dans sa construction, c'est-à-dire que le modèle contient tous les aspects d'une manière fortement imbriquée : le modèle fonctionnel, les propriétés temporelles, les composants processeurs, les interconnexions entre ces processeurs, le modèle de simulation d'un exécutif temps réel ou d'un système d'exploitation pour les processeurs matériels (CPU, MCU et DSP). Un troisième inconvénient est que la simulation avec un système d'exploitation

(ou un exécutif temps réel) nécessite de disposer du code objet de ce système d'exploitation (ou de cet exécutif temps réel) et du modèle ISS du processeur utilisé comme support d'exécution. Une telle technique de simulation est, d'une part coûteuse car ces constituants sont payants, d'autre part très lente (facteur 1000 par rapport à la technique de l'invention) puisque la simulation est du niveau cycle machine (« cycle- accurate » ou « cycle-approximate »). Bien entendu, elle est assez précise.

Un quatrième inconvénient des techniques connues est que la technique de simulation dite native (exécution directe, sur le calculateur de simulation, du code du système d'exploitation ou d'un exécutif temps réel, ou encore d'un modèle approximatif de celui-ci (et donc sans un modèle ISS du processeur dans ce dernier cas)) n'existe que pour un seul niveau de tâches géré par un ordonnanceur. Le Déposant de la présente demande dispose de cette technique connue qui a été ajoutée au langage SystemC 2.0. Des équipes universitaires telles que TIMA, INPG de Grenoble et CECS, University of Irvine, CA, disposent d'une technique assez similaire.

A la connaissance des inventeurs de la présente invention, il n'existe donc aujourd'hui aucune technique connue de simulation par exécution de modèles en natif pour une hiérarchie d'ordonnanceurs pour des processeurs (de type logiciel, matériel, mécanique, humain...). En d'autres termes, on ne connaît aucune technique de simulation par exécution de modèles pour plusieurs exécutifs ou systèmes d'exploitation utilisés d'une manière hiérarchique (une tâche gérée par un exécutif ou un système d'exploitation est elle-même un exécutif ou un système d'exploitation) pour des taches qu'il supporte.

Or, il existe un besoin en ce sens car de plus en plus d'applications, notamment temps réel, vont exploiter l'ordonnancement hiérarchique. La modélisation et la simulation des systèmes complexes exécutant ces applications vont donc probablement devenir incontournables. On peut citer par exemple des téléphones portables exécutant plusieurs systèmes d'exploitation spécialisés imbriqués, ou la capacité de toute application logicielle exécutée sur un système d'exploitation (OS) basé sur UNIX (marque déposée) ou Linux (marque déposée) et utilisant les notions de tâches (également appelées processus, ou « process » en anglais) et processus légers (« threads » en anglais) de ces systèmes d'exploitation.

Les inconvénients ci-dessus conduisent à la situation que les concepteurs ne réalisent pas d'exploration des architectures possibles pour leurs systèmes, ceci pour des raisons de coût et par manque de temps, et donc tablent plus sur leur expérience et même leur intuition pour décider des choix d'architectures. 3. Objectifs de l'invention

L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.

Plus précisément, l'un des objectifs de la présente invention est de fournir une technique de simulation d'un système complexe comprenant une hiérarchie d'ordonnanceurs pour un ou plusieurs processeurs.

L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique de simulation qui s'applique quel que soit le type, matériel, logiciel, mécanique ou humain, du ou des processeurs compris dans le système complexe à simuler. L'invention a aussi pour objectif, dans au moins un mode de réalisation, de fournir une telle technique de simulation qui soit très rapide d'exécution et ne nécessite pas de disposer du code objet du système d'exploitation (ou de l'exécutif temps réel) et du modèle ISS de chaque processeur logiciel utilisé comme support d'exécution.

Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique de simulation permettant de réduire le temps et les compétences requis pour développer le modèle du système complexe à simuler.

Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique de simulation permettant de générer un modèle du système complexe qui soit monolithique dans son utilisation mais pas dans sa construction.

4. Résumé de l'invention

Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de simulation d'un système complexe comprenant au moins un processeur exécutant un ensemble de fonctions sous le contrôle d'un ensemble hiérarchisé d'ordonnanceurs. Selon l'invention, ledit procédé comprend une étape de construction d'un modèle architectural du système complexe comprenant un ensemble hiérarchisé de composants, chacun des composants étant une instance d'une classe d'objet appartenant au groupe comprenant : une première classe, appelée classe « Processeur », représentant un modèle abstrait de tout processeur compris dans le système complexe, chaque instance de la classe « Processeur » étant appelée processeur modélisé ;

une deuxième classe, appelée classe « Fonction », représentant un modèle abstrait de toute fonction exécutée par le système complexe, chaque instance de la classe « Fonction » étant appelée fonction modélisée ; une troisième classe, appelée classe « Ordonnanceur », représentant un modèle abstrait de tout ordonnanceur compris dans le système complexe, chaque instance de la classe « Ordonnanceur » étant appelée ordonnanceur modélisé et se chargeant de gérer des composants, fonction(s) modélisée(s) et/ou autre(s) ordonnanceur(s) modélisé(s), qui lui sont internes ; chaque instance étant initialisée avec au moins un attribut caractérisant son comportement souhaité .

Le principe général de l'invention consiste donc à construire un modèle architectural du système complexe, structuré sous la forme d'une hiérarchie d'objets (processeurs modélisés, fonctions modélisées et ordonnanceurs modélisés), incluant une hiérarchie d'ordonnanceurs modélisés. Ainsi, le code source de chaque ordonnanceur n'est pas nécessaire puisqu'il est modélisé d'une manière abstraite par quelques paramètres (détaillés ci-après). Il n'est pas non plus nécessaire de disposer du modèle ISS de chaque processeur logiciel utilisé comme support d'exécution.

Cette structure du modèle permet une technique de simulation de type native, donc très rapide puisqu'elle consiste à exécuter directement les algorithmes du modèle sur le moteur de simulation.

Cette structure du modèle n'est pas limitée à la modélisation des processeurs logiciels (CPU, MCU et DSP par exemple), mais permet aussi la modélisation de processeurs matériels (FPGA et ASIC par exemple), mécaniques ou humains. On rappelle que les processeurs matériels peuvent utiliser la technique de reconfiguration dynamique afin d'assurer le partage du matériel par plusieurs fonctions, et que dans ce cas les fonctions nécessitent d'être ordonnancées.

De façon avantageuse, l'étape de construction du modèle architectural est effectuée en respectant les règles suivantes : un processeur modélisé peut inclure un ou plusieurs autres processeurs modélisés, un processeur modélisé n'incluant aucun autre processeur modélisé est appelé processeur modélisé élémentaire ;

un processeur modélisé élémentaire inclut, outre son propre ordonnanceur modélisé, au moins une fonction modélisée et/ou au moins un autre ordonnanceur modélisé ; un ordonnanceur modélisé inclut au moins une fonction modélisée et/ou au moins un autre ordonnanceur modélisé ; une fonction modélisée peut inclure une ou plusieurs autres fonctions modélisées.

Le respect de ces règles permet de construire un modèle architectural optimal.

Avantageusement, l'étape de construction d'un modèle architectural comprend les étapes suivantes : génération d'un modèle fonctionnel du système complexe, comprenant lesdites fonctions modélisées et des canaux de communication entre lesdites fonctions modélisées ; génération d'un modèle de plate-forme matérielle du système complexe, comprenant le ou lesdits processeurs modélisés et le ou lesdits ordonnanceurs modélisés ; allocation du modèle fonctionnel sur le modèle de plate-forme, pour obtenir ledit modèle architectural du système complexe.

De cette façon, le modèle architectural produit par la technique de l'invention est monolithique pour la simulation (les constituants fonctionnels et de plate-forme sont dans le même modèle) mais pas dans sa construction. En effet, sa construction résulte de la fusion judicieuse d'un modèle de plate-forme et d'un modèle fonctionnel totalement indépendants, et donc chacun plus facile à optimiser séparément.

Comme expliqué en détail par la suite, il est possible de réduire au maximum le développement manuel nécessaire pour générer le modèle fonctionnel et le modèle de plate-forme. L'invention prévoit pour cela, dans un mode de réalisation particulier, de générer les modèles voulus avec un générateur de modèle, que l'utilisateur renseigne avec une description graphique de ces modèles sur la base de quelques symboles, à laquelle s'ajoutent les algorithmes en C des fonctions de l'application. Les propriétés des constituants, en particulier les propriétés temporelles sont aussi introduites automatiquement dans le modèle produit.

De plus, la technique de génération selon l'invention introduit automatiquement les exécutifs nécessaires pour le modèle, en fonction de l'allocation (ou « mapping » en anglais) des fonctions sur les processeurs et sur les ordonnanceurs souhaités.

Selon une caractéristique avantageuse, ledit modèle fonctionnel comprend au moins un couple de fonctions modélisées, appelées fonction source et fonction consommatrice, liées par un canal de communication, la fonction source générant des messages à destination de la fonction consommatrice qui en assure la consommation.

Avantageusement, l'étape d'allocation du modèle fonctionnel sur le modèle de plate-forme est effectuée en respectant les règles suivantes : - une fonction modélisée peut être allouée sur un processeur modélisé ou un ordonnanceur modélisé ; deux fonctions modélisées liées par un canal de communication et allouées sur des processeurs modélisés différents induisent une interface de communication dans chacun desdits processeurs modélisés, lesdites interfaces de communication étant assimilées à des fonctions modélisées supplémentaires à ordonnancer ; un canal de communication liant deux fonctions modélisées allouées sur un même processeur modélisé est géré par les ordonnanceurs modélisés gérant lesdites fonctions modélisées.

Le respect de ces règles permet de construire un modèle architectural optimal. Préférentiellement, chaque fonction modélisée est initialisée avec au moins un attribut appartenant au groupe comprenant : un temps d'exécution de ladite fonction modélisée ; une priorité pour le partage du processeur modélisé qui exécute ladite fonction modélisée. De façon préférentielle, chaque processeur modélisé est initialisé avec au moins l'attribut suivant : le type, processeur matériel ou processeur logiciel, dudit processeur modélisé.

Préférentiellement, chaque ordonnanceur modélisé est initialisé avec au moins les attributs suivants : une politique d'ordonnancement et au moins un paramètre temporel associé.

Par paramètres temporels associés à une politique d'ordonnancement, on entend par exemple des temps de commutation des tâches, un temps d'élection de la tâche à exécuter par l'ordonnanceur, et une durée de tranches de temps permettant le partage d'un processeur modélisé pour des tâches de même priorité. Avantageusement, ledit au moins un processeur appartient au groupe comprenant : des microprocesseurs, des microcontrôleurs, des processeurs de traitement du signal (DSP), des processeurs réseaux, des circuits intégrés à application spécifique (ASIC), des réseaux logiques programmables, notamment des réseaux prédiffusés programmables (FPGA), des processeurs mécaniques et des processeurs humains. De façon avantageuse, le procédé comprend en outre une étape de simulation native comprenant les étapes suivantes : obtention d'un code binaire du modèle architectural, par compilation d'un code source dudit modèle architectural, et exécution directe du code binaire du modèle architectural par un moteur de simulation.

Ainsi, la technique de simulation de l'invention est du type native et donc très rapide car elle consiste à exécuter directement les algorithmes de l'application, par exemple comme code C++ compilé, sur le calculateur de simulation. Le code source de chaque ordonnanceur n'est pas nécessaire. Il est modélisé d'une manière abstraite par quelques paramètres que sont : la politique d'ordonnancement des tâches, les temps de commutation de tâches, le temps d'élection de la tâche à exécuter par l'ordonnanceur. Avantageusement, l'étape d'exécution directe du code binaire du modèle architectural comprend les étapes suivantes : le moteur de simulation part du composant le plus englobant dudit ensemble hiérarchisé de composants et descend dans les processeurs modélisés jusqu'au(x) processeur(s) modélisé(s) élémentaire(s) n'incluant pas de processeur modélisé ; - pour chaque processeur modélisé élémentaire :

* le moteur de simulation analyse l'état des fonctions modélisées et des ordonnanceurs modélisés situés au plus haut niveau hiérarchique au sein dudit processeur modélisé ;

* en fonction d'une première politique d'ordonnancement avec laquelle a été initialisé un ordonnanceur modélisé associé audit processeur modélisé élémentaire, le moteur de simulation sélectionne la fonction modélisée ou

l'ordonnanceur modélisé le plus prioritaire au sein dudit processeur modélisé ;

* le moteur de simulation active le composant sélectionné, en appliquant au moins un paramètre temporel associé à ladite première politique d'ordonnancement.

On notera que la structure même du modèle architectural induit le principe de simulation.

Selon une caractéristique avantageuse, pour chaque composant activé qui est un ordonnanceur modélisé : * le moteur de simulation analyse l'état de toutes les fonctions modélisées et tous les ordonnanceurs modélisés situés au plus haut niveau hiérarchique au sein dudit ordonnanceur modélisé activé ;

* en fonction d'une seconde politique d'ordonnancement avec laquelle a été initialisé ledit ordonnanceur modélisé activé, le moteur de simulation sélectionne la fonction modélisée ou l'ordonnanceur modélisé le plus prioritaire au sein dudit ordonnanceur modélisé activé ;

* le moteur de simulation active le composant sélectionné, en appliquant au moins un paramètre temporel associé à ladite seconde politique d' ordonnancement. L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précité selon l'invention, lorsque ledit programme est exécuté sur un ordinateur.

L'invention concerne aussi un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en œuvre le procédé précité selon l'invention. 5. Liste des figures

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels :

la figure 1 illustre un exemple de système complexe, réduit à un seul processeur, pouvant faire l'objet d'une simulation selon le procédé de l'invention ; la figure 2 présente un organigramme d'un mode de réalisation particulier du procédé de simulation selon l'invention ; - la figure 3 illustre à travers un exemple l'étape de construction d'un modèle architectural apparaissant sur l'organigramme de la figure 2, avec la génération d'un modèle fonctionnel et d'un modèle de plate-forme matérielle du système complexe, ainsi qu'une allocation de l'un de ces deux modèles sur l'autre ; la figure 4 illustre un exemple de modèle architectural, obtenu à l'issue de l'allocation illustrée sur la figure 3 ; et la figure 5 illustre un exemple d'outil logiciel d'édition des attributs des composants d'un modèle architectural, à travers l'exemple du modèle architectural de la figure 4. 6. Description détaillée L'invention concerne donc un procédé de simulation d'un système complexe comprenant au moins un processeur exécutant un ensemble de fonctions sous le contrôle d'un ensemble hiérarchisé d'ordonnanceurs.

On présente maintenant, en relation avec la figure 1, un exemple de système complexe, réduit à un seul processeur (CPU), pouvant faire l'objet d'une simulation selon le procédé de l'invention.

Le microprocesseur (CPU) 11 est chargé d'exécuter un ensemble de tâches de premier niveau : Task Al, Task A2, ... Task Am. Un exécutif temps réel (ordonnanceur principal, par exemple non-préemptif) 12 est ajouté à cet ensemble de tâches de manière à ordonnancer le séquencement d'exécution des tâches par le CPU. Dans cet exemple, la tâche Task A2 est en fait un groupe de deux tâches élémentaires (aussi appelées fonctions) : F4 et F5. Un exécutif temps réel (ordonnanceur, par exemple préemptif) 13 est aussi associé à ce groupe pour son ordonnancement.

De même, la tâche Task Am est en fait un groupe de trois tâches : Task Bl, Task B2, Task B3. Un exécutif temps réel (ordonnanceur, par exemple préemptif) 14 est aussi associé à ce groupe pour son ordonnancement.

La hiérarchie peut se poursuivre, ce qui est montré pour la tâche Task Bl qui inclut un groupe de trois tâches élémentaires (fonctions) Fl, F2, F3, et un exécutif temps réel (ordonnanceur) 15 est associé à ce groupe.

Enfin, dans cet exemple, la tâche Task B2 inclut une unique tâche élémentaire (fonction) FlO et la tâche Task B 3 inclut une unique tâche élémentaire (fonction) FIl.

Comme illustration d'exemples réels, un processeur peut supporter un ensemble initial de tâches temps réel géré par un exécutif temps réel tel que VxWorks (marque déposée) de la société Wind River Systems. L'une des tâches sert pour l'exécution du système d'exploitation Linux (marque déposée) qui lui-même exécute un ensemble de tâches. Une autre tâche peut servir à l'exécution de la machine virtuelle Java (marque déposée), elle même se chargeant d'exécuter un ensemble de tâches ou de processus légers (« threads »). Dans le domaine des mobiles, une tâche est par exemple utilisée pour faire tourner le système d'exploitation Symbian (marque déposée) gérant lui-même un ensemble de tâches. Comme illustré sur la figure 2, le procédé de simulation selon l'invention comprend une étape 21 de construction d'un modèle architectural du système complexe et une étape 22 de simulation native à partir de ce modèle architectural.

Le principe général de l'invention consiste à construire un modèle architectural comprenant une hiérarchie de composants, chacun étant une instance d'une classe d'objet.

Les classes d'objets utilisées sont : une première classe, appelée classe « Processeur » (ou « Processor » en anglais), représentant un modèle abstrait de tout processeur (matériel ou logiciel) compris dans le système complexe, chaque instance de la classe « Processeur » étant appelée processeur modélisé ; une deuxième classe, appelée classe « Fonction » (ou « Function » en anglais), représentant un modèle abstrait de toute fonction (tâche élémentaire) exécutée par le système complexe, chaque instance de la classe « Fonction » étant appelée fonction modélisée ; - une troisième classe, appelée classe « Ordonnanceur » (ou « Scheduler » en anglais), représentant un modèle abstrait de tout ordonnanceur compris dans le

système complexe, chaque instance de la classe « Ordonnanceur » étant appelée ordonnanceur modélisé et se chargeant de gérer des composants, fonction(s) modélisée(s) et/ou autre(s) ordonnanceur(s) modélisé(s), qui lui sont internes.

Chaque instance est initialisée avec au moins un attribut caractérisant son comportement souhaité (voir détails ci-après).

Les classes d'objets sont par exemple développées sous SystemC 2.0. Mais l'invention n'est pas limitée à l'emploi de ce langage.

La création du modèle architectural respecte les règles suivantes : un processeur modélisé peut inclure un ou plusieurs autres processeurs modélisés, un processeur modélisé n'incluant aucun autre processeur modélisé est appelé processeur modélisé élémentaire ; un processeur modélisé élémentaire inclut, outre son propre ordonnanceur modélisé (voir l'ordonnanceur principal 12 sur la figure 1), au moins une fonction modélisée et/ou au moins un autre ordonnanceur modélisé ; - un ordonnanceur modélisé inclut au moins une fonction modélisée et/ou au moins un autre ordonnanceur modélisé ; une fonction modélisée peut inclure une ou plusieurs autres fonctions modélisées.

Dans le mode de réalisation particulier de l'invention illustré sur la figure 2, l'étape 21 de construction d'un modèle architectural comprend elle-même : une étape 211 de génération d'un modèle fonctionnel du système complexe, comprenant les fonctions modélisées et des canaux de communication entre ces fonctions modélisées ; une étape 212 de génération d'un modèle de plate-forme matérielle du système complexe, comprenant le ou les processeurs modélisés et le ou les ordonnanceur modélisés ; une étape 213 d'allocation du modèle fonctionnel sur le modèle de plate-forme, pour obtenir le modèle architectural du système complexe.

Par ailleurs, dans ce mode de réalisation particulier, l'étape 22 de simulation native comprend elle-même une étape 221 d'obtention d'un code binaire du modèle architectural, par compilation d'un code source de ce modèle architectural, et une étape

222 d'exécution directe du code binaire du modèle architectural par un moteur de simulation. Cette dernière étape 222 est discutée plus en détail dans la suite de la description.

La figure 3 illustre à travers un exemple l'étape de construction d'un modèle architectural apparaissant sur l'organigramme de la figure 2, avec l'allocation d'un modèle fonctionnel sur un modèle de plate-forme matérielle du système complexe, ces deux modèles étant préalablement générés indépendamment l'un de l'autre.

Un éditeur graphique sert par exemple à capturer le modèle fonctionnel 31 et le modèle de plate-forme matérielle 32, nécessaires en entrée de l'outil de génération du modèle architectural 33.

La partie gauche de la figure 3 montre l'exemple considéré pour le modèle fonctionnel 31. Celui-ci est composé de fonctions modélisées simples (hiérarchie possible), référencées FctO à Fct9, et de canaux de communication modélisés (aussi appelés relations fonctionnelles ou files de messages), référencée ChannelO à Channel4. Les fonctions modélisées sont regroupées par couple : chaque fonction modélisée de gauche (FctO, Fctl, Fct4, Fct6, Fct8) est un générateur de messages à destination de la fonction modélisée de droite (Fct2, Fct3, Fct5, Fct7, Fct9) qui en assure la consommation.

La partie droite de la figure 3 représente un exemple de modèle de plate-forme 32. Il est composé de deux processeurs modélisés (hiérarchie possible), référencés ProO et Prol, et d'un nœud de communication modélisé, référencé NodeO, représentant le bus physique d'interconnexion. Les processeurs modélisés peuvent être de type matériel ou logiciel. Chaque processeur modélisé inclut plusieurs ordonnanceurs modélisés : le processeur modélisé référencé ProO inclut les ordonnanceurs modélisés référencés SchedulerOl et SchedulerO2. Le processeur modélisé référencé Prol inclut les ordonnanceurs modélisés référencés Schedulerl l, Schedulerl2 et Schedulerl21. La hiérarchie des ordonnanceurs modélisés est considérée dans l'exemple. Ainsi, l'ordonnanceur modélisé référencé Schedulerl21 est inclus dans celui référencé Schedulerl2.

Chaque modèle 31, 32 est enrichi par des propriétés appelées attributs. Ces attributs, et notamment ceux du modèle de plate-forme 32, sont importants pour la génération du modèle architectural 33. Les attributs essentiels sont : pour une fonction modélisée : ses temps d'exécution, sa priorité pour le partage du processeur modélisé qui exécute cette fonction modélisée ; pour un processeur modélisé : son type, soit processeur matériel ou processeur logiciel (exécutant du logiciel, ce qui est le cas des microprocesseurs) ; pour un ordonnanceur modélisé : sa politique d'ordonnancement et les paramètres temporels associés. L'opération d'allocation 34 (aussi appelée « mapping » en anglais), du modèle fonctionnel 31 sur le modèle de plate-forme 32 est par exemple réalisée d'une manière interactive, avec un outil logiciel adapté (dont les fonctionnalités sont discutées ci- après). Cette opération conduit à l'obtention automatique du modèle architectural 33 permettant l'évaluation de ses performances et l'exploration d'architectures. La figure 4 illustre un exemple de modèle architectural, obtenu à l'issue de l'allocation illustrée sur la figure 3.

Les éléments communs aux figures 3 et 4 conservent les mêmes références

(processeurs modélisés référencés ProO et Prol, fonctions modélisées référencées FctO à

Fct9, canaux de communication modélisés référencés ChannelO à Channel4, ordonnanceurs référencés SchedulerOl, SchedulerO2, Schedulerl l, Schedulerl2 et

Schedulerl21).

L'étape d'allocation 34 du modèle fonctionnel 31 sur le modèle de plate-forme 32 est effectuée en respectant les règles suivantes : une fonction modélisée peut être allouée sur un processeur modélisé (cas des fonctions modélisées référencées Fct3 et Fct4) ou un ordonnanceur modélisé (cas des autres fonctions modélisées) ; deux fonctions modélisées liées par un canal de communication et allouées sur des processeurs modélisés différents (cas des couples de fonctions suivants :

(FctO, Fct2), (Fctl, Fct3), (Fct6, Fct7)) induisent une interface de communication dans chacun des processeurs modélisés impliqués. Ces interfaces de communication sont assimilées à des fonctions modélisées supplémentaires à

ordonnancer. Elles sont référencées ChOout Interface, ChI out Interface, Ch3out

Interface et NodeOIn Interface ; un canal de communication liant deux fonctions modélisées allouées sur un même processeur modélisé (cas des canaux référencés Channel2 et ChanneW) est géré par les ordonnanceurs modélisés gérant ces fonctions modélisées.

Dans cet exemple, la hiérarchie d'ordonnanceurs modélisés est bien représentée pour le processeur modélisé référencé Prol, qui est un processeur logiciel. En effet, ce dernier possède son propre ordonnanceur (non représenté, et appelé ci-dessus ordonnanceur principal), qui gère les fonctions modélisées référencées Fct3 et Fct4 ainsi que les deux ordonnanceurs référencés Schedulerl l et Schedulerl2. L'ordonnanceur référencé Schedulerl2 gère lui-même la fonction modélisée référencée Fct2 et l'ordonnanceur modélisé référencé Schedulerl21.

On présente maintenant, en relation avec la figure 5, un exemple d'outil logiciel d'édition des attributs des composants d'un modèle architectural, à travers l'exemple du modèle architectural de la figure 4.

La fenêtre de gauche 51 affiche la hiérarchie du modèle architectural (les noms des éléments sont identiques à ceux de la figure 4) ainsi que l'élément de cette hiérarchie couramment sélectionné (il apparaît dans un cadre grisé) et dont les attributs peuvent donc être définis. La fenêtre de droite 52 affiche les attributs de l'élément sélectionné dans la fenêtre de gauche 51. Dans l'exemple illustré, c'est l'ordonnanceur référencé SchedulerOl. La fenêtre de droite 52 comprend quatre colonnes, qui indiquent respectivement, pour chaque attribut : la catégorie d'attributs à laquelle appartient cet attribut, le nom de cet attribut, la valeur de cet attribut et l'unité dans laquelle s'exprime cette valeur.

Parmi les différents attributs d'un ordonnanceur, on notera notamment les suivants, qui caractérisent un système d'exploitation temps réel (ou RTOS, pour « Real Time Operating System ») : un premier attribut (« SchedulingPolicy ») 53 qui définit la politique d'ordonnancement des tâches. Les plus usuelles sont : ordonnancement selon la

priorité, selon une échéance, ceci en mode préemptif ou non préemptif, fonctionnement du type partage de temps (« time sharing ») ; un deuxième attribut (« SchedulingDuration ») 54 qui représente le temps requis par l'ordonnanceur pour décider de la tâche à exécuter ; - des troisième et quatrième attributs (« TaskContextLoad » et

« TaskContextSave ») 55 et 56 qui représentent les temps de commutation de tâches ; un cinquième attribut (« TimeSlicePeriod ») 57 qui permet pour des tâches de même priorité d'assurer le partage du processeur par allocation de tranches de temps.

Les ordonnanceurs peuvent avoir des politiques d'ordonnancement différentes.

Les politiques d'ordonnancement pour un processeur matériel sont un peu différentes.

En particulier, le caractère préemptif n'apparaît pas aujourd'hui justifié. L'homme du métier saura définir précisément les différentes politiques d'ordonnancement pouvant être retenues. L'invention n'est pas liée à une politique d'ordonnancement particulière.

On présente maintenant plus en détail un mode de réalisation particulier de l'étape (référencée 222 sur la figure 2) d'exécution directe du code binaire du modèle architectural par un moteur de simulation.

La structure même du modèle architectural sous la forme d'une hiérarchie d'objets induit le principe de simulation.

Le moteur de simulation part du composant le plus englobant de l'ensemble hiérarchisé de composants et descend dans les processeurs modélisés jusqu'aux processeurs modélisés élémentaires (processeurs n'incluant pas de processeur modélisé, mais uniquement des fonctions modélisées et/ou des ordonnanceurs modélisés). Pour chaque processeur modélisé élémentaire, le moteur de simulation analyse l'état des fonctions modélisées et des ordonnanceurs modélisés situés au plus haut niveau hiérarchique au sein de ce processeur modélisé. Chaque ordonnanceur est considéré comme une tâche. Puis, en fonction de la politique d'ordonnancement de ce processeur modélisé (ou plus précisément de l'ordonnanceur principal associé à ce processeur modélisé), le moteur de simulation sélectionne la fonction modélisée ou l'ordonnanceur modélisé le plus prioritaire au sein de ce processeur modélisé. Enfin, le

moteur de simulation active le composant sélectionné, en appliquant les paramètres temporels (« SchedulingDuration » et « TaskContextLoad ») associé à cette politique d' ordonnancement.

Si le composant activé est un ordonnanceur modélisé, le moteur de simulation analyse l'état de toutes les fonctions modélisées et tous les ordonnanceurs modélisés situés au plus haut niveau hiérarchique au sein de cet ordonnanceur modélisé activé. Puis, en fonction de la politique d'ordonnancement avec laquelle a été initialisé cet ordonnanceur modélisé activé, le moteur de simulation sélectionne la fonction modélisée ou l'ordonnanceur modélisé le plus prioritaire au sein de cet ordonnanceur modélisé activé. Enfin, le moteur de simulation active le composant sélectionné, en appliquant les paramètres temporels associés à la politique d'ordonnancement suivie par l'ordonnanceur modélisé activé.

La récurrence est poursuivie de cette manière pour toute la hiérarchie jusqu'aux fonctions modélisées (tâches élémentaires). La complexité de la technique de l'invention provient de l'aspect prioritaire du processeur ou d'un ordonnanceur englobant. Une préemption peut survenir (interruption externe, tranche de temps allouée et écoulée, disponibilité d'un message...). Dans ce cas, au niveau de la hiérarchie où apparaît l'événement, la tâche ou ordonnanceur en cours est suspendu et par conséquent pour un ordonnanceur toutes les tâches incluses sont suspendues récursivement en respectant les paramètres temporels

(« TaskContextLoad »). L'allocation est alors considérée par l'ordonnanceur du niveau, ce qui induit une relance pour la hiérarchie descendante.

La technique de l'invention, basée sur une implantation objet, est ouverte. Ceci permet toute adaptation future aux besoins nouveaux des concepteurs. En effet, l'algorithme d'ordonnancement est implanté comme une méthode de la classe

« Processeur », et l'ordonnanceur modélisé est une classe héritée de la classe « Processeur ». Ainsi, la méthode d'ordonnancement peut à tout moment être surchargée par une méthode pouvant être décrite par le concepteur du modèle afin de répondre à son besoin particulier. II est à noter que l'invention n'est pas limitée aux processeurs du type microprocesseur. Elle s'applique d'une manière similaire aux processeurs matériels que

sont par exemple les circuits programmables reconfigurables du type FPGA. Ceci est très important pour le futur. En effet, la reconfigurabilité des circuits programmables amène à la possibilité de partager une même zone matérielle (portes et bistables) pour plusieurs fonctions ou algorithmes à la condition qu'elles s'exécutent de manière exclusive. Pour assurer cette exigence, il faut donc un ordonnanceur. L'ordonnanceur est alors matériel puisque interne au FPGA.

On rappelle que l'invention permet une simulation très performante, car native, de toute hiérarchie d'exécutifs temps réel. Les raisons de cette performance sont notamment : - la simulation ne nécessite par l'emploi d'un modèle du niveau instruction

(Instruction Set Simulator) du processeur. Elle se fait par exécution directe du code (par exemple un code C compilé) par le calculateur de simulation

(exécution native) ; la simulation inclut toutefois la notion de temps d'exécution (simulation dite "timée") par opposition à des simulations natives "non-timées". Ceci permet de faire une étude de performances de la solution ; la modélisation des exécutifs temps réel se fait par quelques paramètres simples

(modèle abstrait de RTOS) par opposition à la nécessité de devoir disposer du code source de chaque exécutif.