WO2006084845A2 - Procede de simulation d'un processeur utilisant un modele comprenant un ensemble de objets - Google Patents
Procede de simulation d'un processeur utilisant un modele comprenant un ensemble de objets Download PDFInfo
- Publication number
- WO2006084845A2 WO2006084845A2 PCT/EP2006/050725 EP2006050725W WO2006084845A2 WO 2006084845 A2 WO2006084845 A2 WO 2006084845A2 EP 2006050725 W EP2006050725 W EP 2006050725W WO 2006084845 A2 WO2006084845 A2 WO 2006084845A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- modeled
- processor
- scheduler
- function
- model
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
Definitions
- the technique of the invention is based on general concepts of task (function), processor (and thus execution resource) and scheduler, it has a broader application than that of microprocessors. It covers all types of processors (see definition above) to ensure resource sharing.
- the technique of the invention is particularly adapted to new technologies of telecommunications and multimedia.
- the evolution of standards and their gradual stabilization lead to the need to create scalable and therefore "teleconfigurable" equipment. Dynamic configuration and therefore dynamic scheduling are solutions to respond to changes in product functionality.
- a modeled processor may include one or more other modeled processors, a modeled processor not including any other modeled processor is called a modeled elementary processor; an elementary modeled processor includes, in addition to its own modeled scheduler, at least one modeled function and / or at least one other modeled scheduler; a modeled scheduler includes at least one modeled function and / or at least one other modeled scheduler; a modeled function may include one or more other modeled functions.
- the invention provides for this, in a particular embodiment, to generate the desired models with a model generator, that the user informs with a graphic description of these models on the basis of a few symbols, to which are added the C algorithms of the application functions.
- the properties of the constituents in particular the temporal properties, are also introduced automatically into the product model.
- the generation technique according to the invention automatically introduces the necessary executives for the model, according to the allocation (or "mapping" in English) of the functions on the processors and on the desired schedulers.
- a modeled function can be allocated on a modeled processor or a modeled scheduler; two modeled functions linked by a communication channel and allocated on different modeled processors induce a communication interface in each of said modeled processors, said communication interfaces being assimilated to additional modeled functions to be scheduled; a communication channel linking two modeled functions allocated on the same modeled processor is managed by the modeled schedulers managing said modeled functions.
- the simulation engine analyzes the state of all the modeled functions and modeled schedulers located at the highest hierarchical level within said activated modeled scheduler;
- the invention therefore relates to a simulation method.
- a complex system comprising at least one processor executing a set of functions under the control of a hierarchical set of schedulers.
- step 21 of constructing an architectural model itself comprises: a step 211 for generating a functional model of the complex system, comprising the modeled functions and communication channels between these modeled functions; a step 212 of generating a hardware platform model of the complex system, including the modeled processor (s) and the modeled scheduler (s); a step 213 of allocating the functional model on the platform model, to obtain the architectural model of the complex system.
- the native simulation step 22 itself comprises a step 221 for obtaining a binary code of the architectural model, by compiling a source code of this architectural model, and a step 222 Direct execution of the binary code of the architectural model by a simulation engine. This last step 222 is discussed in more detail in the following description.
- FIG. 3 illustrates, by way of example, the step of constructing an architectural model appearing on the flowchart of FIG. 2, with the allocation of a functional model on a hardware platform model of the complex system, these two models being previously generated independently of one another.
- the right part of FIG. 3 represents an exemplary platform model 32. It is composed of two modeled processors (hierarchy possible), referenced ProO and Prol, and a modeled communication node, referenced NodeO, representing the bus. interconnection physics.
- the modeled processors may be hardware or software type.
- Each modeled processor includes several modeled schedulers: the modeled processor referenced ProO includes the modeled schedulers referenced SchedulerOl and SchedulerO2.
- the modeled processor referenced Prol includes the modeled schedulers referenced Schedulerl l, Schedulerl2 and Schedulerl21.
- the hierarchy of modeled schedulers is considered in the example. Thus, the modeled scheduler referenced Schedulerl21 is included in that referenced Schedulerl2.
- the allocation step 34 of the functional model 31 on the platform model 32 is performed according to the following rules: a modeled function can be allocated on a modeled processor (in the case of the modeled functions referenced Fct3 and Fct4) or a scheduler modeled (in the case of other modeled functions); two modeled functions linked by a communication channel and allocated on different modeled processors (case of the following pairs of functions:
- FIG. 5 shows an example of a software tool for editing the attributes of the components of an architectural model, using the example of the architectural model of FIG. 4.
- the left window 51 displays the hierarchy of the architectural model (the names of the elements are identical to those of FIG. 4) as well as the element of this currently selected hierarchy (it appears in a grayed-out box) and whose attributes can therefore be defined.
- the right window 52 displays the attributes of the element selected in the left window 51. In the illustrated example, it is the scheduler referenced SchedulerOl.
- the right window 52 comprises four columns, which respectively indicate, for each attribute: the attribute category to which this attribute belongs, the name of this attribute, the value of this attribute and the unit in which this value is expressed. .
- a scheduler which characterize a real-time operating system (or RTOS, for "Real Time Operating System”): a first attribute (“SchedulingPolicy”) 53 that defines the policy scheduling tasks. The most common are: scheduling according to the priority, according to a deadline, this in preemptive or non-preemptive mode, time sharing type operation; a second attribute (“SchedulingDuration”) 54 which represents the time required by the scheduler to decide on the task to be performed; - third and fourth attributes ("TaskContextLoad” and
- preemptive character does not appear to be justified today.
- the skilled person will be able to precisely define the different scheduling policies that can be selected.
- the invention is not related to a particular scheduling policy.
- step 222 in Figure 2 direct execution of the binary code of the architectural model by a simulation engine.
- the simulation engine analyzes the state of all modeled functions and modeled schedulers located at the highest hierarchical level within this modeled enabled scheduler. Then, according to the scheduling policy with which this modeled scheduler has been initialized, the simulation engine selects the highest priority modeled function or modeled scheduler within this activated modeled scheduler. Finally, the simulation engine activates the selected component, applying the temporal parameters associated with the scheduling policy followed by the activated modeled scheduler.
- Preemption can occur (external interruption, time slot allocated and elapsed, availability of a message ).
- the current task or scheduler is suspended and therefore for a scheduler all the included tasks are recursively suspended according to the temporal parameters.
- the technique of the invention based on an object implantation, is open. This allows any future adaptation to the new needs of the designers. Indeed, the scheduling algorithm is implemented as a method of the class
- the scheduling method can be overloaded at any time by a method that can be described by the model designer to meet his particular need.
- the invention is not limited to processors of the microprocessor type. It applies in a similar way to hardware processors that are, for example, the programmable reconfigurable circuits of the FPGA type. This is very important for the future. Indeed, the reconfigurability of the programmable circuits leads to the possibility of sharing the same hardware area (gates and bistables) for several functions or algorithms on the condition that they execute exclusively. To ensure this requirement, you need a scheduler. The scheduler is then hardware since internal to the FPGA.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
Abstract
Procédé de simulation d'un système complexe incluant une hiérarchie d'ordonnanceurs, produit programme d'ordinateur et moyen de stockage correspondants. 5 L'invent ion concerne 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, le procédé comprend une étape (21) 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 « Fonct ion », représentant un modèle abstrait de toute fonction exécutée par le système complexe, chaque instance de la classe « Fonct ion » é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 est initialisée avec au moins un attribut caractérisant son comportement souhaité.
Description
Procédé de simulation d'un système complexe incluant une hiérarchie d'ordonnanceurs, produit programme d'ordinateur et moyen de stockage correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des systèmes complexes du type comprenant au moins un processeur exécutant un ensemble de fonctions sous le contrôle d'un ensemble hiérarchisé d'ordonnanceurs.
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.
Claims
1. Procédé de simulation d'un système complexe comprenant au moins un processeur (11 ; ProO, Prol) exécutant un ensemble de fonctions (Fl à F5, FlO, FI l ; FctO à Fct9) sous le contrôle d'un ensemble hiérarchisé d'ordonnanceurs (12 à 15 ; SchedulerOl, SchedulerO2, Schedulerl l, Schedulerl2, Schedulerl21), caractérisé en ce que ledit procédé comprend une étape (21) 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é.
2. Procédé selon la revendication 1, caractérisé en ce que l'étape (21) 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.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que l'étape (21) de construction d'un modèle architectural comprend les étapes suivantes : - génération (211) 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 (212) 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 (213) du modèle fonctionnel sur le modèle de plate-forme, pour obtenir ledit modèle architectural du système complexe.
4. Procédé selon la revendication 3, caractérisé en ce que ledit modèle fonctionnel comprend au moins un couple de fonctions modélisées, appelées fonction source (FctO, Fctl, Fct4, Fct6, Fct8) et fonction consommatrice (Fct2, Fct3, Fct5, Fct7, Fct9), liées par un canal de communication (ChannelO à Channel4), la fonction source générant des messages à destination de la fonction consommatrice qui en assure la consommation.
5. Procédé selon l'une quelconque des revendications 3 et 4, caractérisé en ce que l'étape (213) 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.
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que 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.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que chaque processeur modélisé est initialisé avec au moins l'attribut suivant : le type, processeur matériel ou processeur logiciel, dudit processeur modélisé.
8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que chaque ordonnanceur modélisé est initialisé avec au moins les attributs suivants : une politique d'ordonnancement et au moins un paramètre temporel associé.
9. Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que ledit au moins un processeur appartient au groupe comprenant : des microprocesseurs, des microcontrôleurs, des processeurs de traitement du signal, des processeurs réseaux, des circuits intégrés à application spécifique, des réseaux logiques programmables, notamment des réseaux prédiffusés programmables, des processeurs mécaniques et des processeurs humains.
10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend en outre une étape (22) de simulation native comprenant les étapes suivantes : obtention (221) d'un code binaire du modèle architectural, par compilation d'un code source dudit modèle architectural, et exécution (222) directe du code binaire du modèle architectural par un moteur de simulation.
11. Procédé selon la revendication 10, caractérisé en ce que l'étape (222) 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.
12. Procédé selon la revendication 11, caractérisé en ce que, 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.
13. Produit programme d'ordinateur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 12, lorsque ledit programme est exécuté sur un ordinateur.
14. 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é selon l'une quelconque des revendications 1 à 12.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/815,829 US7885802B2 (en) | 2005-02-14 | 2006-02-07 | Method of simulating a complex system including scheduler hierarchy, and corresponding storage means and computer program product |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0501486A FR2882169B1 (fr) | 2005-02-14 | 2005-02-14 | Procede de simulation d'un systeme complexe incluant une hierarchie d'ordonnanceurs, produit programme d'ordinateur et moyen de stockage correspondants |
| FR0501486 | 2005-02-14 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| WO2006084845A2 true WO2006084845A2 (fr) | 2006-08-17 |
| WO2006084845A3 WO2006084845A3 (fr) | 2006-12-14 |
Family
ID=34955472
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/EP2006/050725 WO2006084845A2 (fr) | 2005-02-14 | 2006-02-07 | Procede de simulation d'un processeur utilisant un modele comprenant un ensemble de objets |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7885802B2 (fr) |
| FR (1) | FR2882169B1 (fr) |
| WO (1) | WO2006084845A2 (fr) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2907240A1 (fr) * | 2006-10-11 | 2008-04-18 | Cofluent Design Sarl | Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants |
| US8650570B2 (en) | 2008-06-02 | 2014-02-11 | Microsoft Corporation | Method of assigning instructions in a process to a plurality of scheduler instances based on the instruction, in which each scheduler instance is allocated a set of negoitaited processor resources |
| CN108073682A (zh) * | 2016-11-14 | 2018-05-25 | 达索系统公司 | 基于参数视图函数查询数据库 |
| US10031987B2 (en) | 2016-06-15 | 2018-07-24 | International Business Machines Corporation | Verification of untimed nets |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7934194B2 (en) * | 2006-10-17 | 2011-04-26 | The Mathworks, Inc. | User-defined hierarchies of user-defined classes of graphical objects in a graphical modeling environment |
| EP2366146B2 (fr) | 2009-12-23 | 2016-10-12 | Inchron GmbH | Procédé et système de traitement de données pour simuler un système intégré |
| WO2011114478A1 (fr) * | 2010-03-17 | 2011-09-22 | 富士通株式会社 | Procédé de génération, procédé d'ordonnancement, programme de génération, programme d'ordonnancement, dispositif de génération et dispositif de traitement d'informations |
| KR101689736B1 (ko) * | 2010-08-18 | 2016-12-27 | 삼성전자주식회사 | 작업 스케쥴링 기능을 구비한 작업 처리장치, 스케쥴링 활성화 제어장치 및 대칭형 멀티프로세싱 환경에서의 작업 스케쥴링 방법 |
| JP5625710B2 (ja) * | 2010-10-05 | 2014-11-19 | 富士通セミコンダクター株式会社 | シミュレーション装置、方法、及びプログラム |
| CN102366930A (zh) * | 2011-09-28 | 2012-03-07 | 安徽沃德气门制造有限公司 | 一种自动气门研磨装置 |
| US9360523B2 (en) * | 2014-04-18 | 2016-06-07 | Breker Verification Systems | Display in a graphical format of test results generated using scenario models |
| CN104991884B (zh) * | 2015-06-18 | 2017-12-05 | 中国科学院自动化研究所 | 异构多核SoC的体系结构设计方法 |
| US9996637B2 (en) * | 2015-07-30 | 2018-06-12 | International Business Machines Corporation | Method for verifying hardware/software co-designs |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002027565A1 (fr) * | 2000-09-28 | 2002-04-04 | Cadence Design Systems, Inc. | Modelisation de niveau de performance et simulation de systemes electroniques possedant a la fois des ressources materielles et des ressources logicielles |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7567893B2 (en) * | 2004-12-30 | 2009-07-28 | Vast Systems Technology Corporation | Clock simulation system and method |
-
2005
- 2005-02-14 FR FR0501486A patent/FR2882169B1/fr not_active Expired - Fee Related
-
2006
- 2006-02-07 US US11/815,829 patent/US7885802B2/en not_active Expired - Fee Related
- 2006-02-07 WO PCT/EP2006/050725 patent/WO2006084845A2/fr active Application Filing
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2002027565A1 (fr) * | 2000-09-28 | 2002-04-04 | Cadence Design Systems, Inc. | Modelisation de niveau de performance et simulation de systemes electroniques possedant a la fois des ressources materielles et des ressources logicielles |
Non-Patent Citations (4)
| Title |
|---|
| LE MOIGNE R ET AL: "A generic RTOS model for real-time systems simulation with systemC" DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE AND EXHIBITION, 2004. PROCEEDINGS FEB. 16-20, 2004, PISCATAWAY, NJ, USA,IEEE, vol. 3, 16 février 2004 (2004-02-16), pages 82-87, XP010685017 ISBN: 0-7695-2085-5 * |
| MULLER F ET AL: "An interactive modeling and generation tool for the design of Hw/Sw systems" EUROMICRO CONFERENCE, 1999. PROCEEDINGS. 25TH MILAN, ITALY 8-10 SEPT. 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, vol. 1, 8 septembre 1999 (1999-09-08), pages 382-385, XP010352253 ISBN: 0-7695-0321-7 * |
| VINCENT PERRIER: "System architecting complex designs" EMBEDDED SYTEMS EUROPE, [Online] 1 janvier 2004 (2004-01-01), pages 24-26, XP002344005 Extrait de l'Internet: URL:http://www.cofluentdesign.com/protecte d/iso_album/esefeb04p24.pdf> [extrait le 2005-09-05] * |
| YOO S ET AL: "Automatic generation of fast timed simulation models for operating systems in SoC design" PROCEEDINGS 2002 DESIGN, AUTOMATION AND TEST IN EUROPE CONFERENCE AND EXHIBITION IEEE COMPUT. SOC LOS ALAMITOS, CA, USA, 2002, pages 620-627, XP002344006 ISBN: 0-7695-1471-5 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2907240A1 (fr) * | 2006-10-11 | 2008-04-18 | Cofluent Design Sarl | Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants |
| US7991603B2 (en) | 2006-10-11 | 2011-08-02 | Cofluent Design | Method for simulating a complex system with expansion of instance vectors, corresponding computer program product and storage means |
| US8650570B2 (en) | 2008-06-02 | 2014-02-11 | Microsoft Corporation | Method of assigning instructions in a process to a plurality of scheduler instances based on the instruction, in which each scheduler instance is allocated a set of negoitaited processor resources |
| US10031987B2 (en) | 2016-06-15 | 2018-07-24 | International Business Machines Corporation | Verification of untimed nets |
| CN108073682A (zh) * | 2016-11-14 | 2018-05-25 | 达索系统公司 | 基于参数视图函数查询数据库 |
| CN108073682B (zh) * | 2016-11-14 | 2024-03-29 | 达索系统公司 | 基于参数视图函数查询数据库 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20080228461A1 (en) | 2008-09-18 |
| US7885802B2 (en) | 2011-02-08 |
| FR2882169A1 (fr) | 2006-08-18 |
| WO2006084845A3 (fr) | 2006-12-14 |
| FR2882169B1 (fr) | 2007-05-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2006084845A2 (fr) | Procede de simulation d'un processeur utilisant un modele comprenant un ensemble de objets | |
| Sangiovanni-Vincentelli | Quo vadis, SLD? Reasoning about the trends and challenges of system level design | |
| US7487080B1 (en) | Partitioning a model in modeling environments | |
| US8855992B1 (en) | Graphical modeling blocks that execute in more than one domain | |
| JP6953450B2 (ja) | モデルアダプタを作成するためのシステム及び方法 | |
| Otero et al. | Dreams: A tool for the design of dynamically reconfigurable embedded and modular systems | |
| JP2009538481A (ja) | 処理システムでのソフトウェアプログラムの実行に基づくａｓｉｃの設計 | |
| EP1290554B1 (fr) | Systeme informatique modulaire et procede associe | |
| Le Sergent et al. | Benefits of model based system engineering for avionics systems | |
| EP3273368A1 (fr) | Systèmes et procédés de groupement de codes d'événements implicites et explicites de modèles exécutables | |
| US11755294B2 (en) | Systems and methods for generating service access points for RTE services in code or other RTE service information for use with the code | |
| Ajwani et al. | Generating synthetic task graphs for simulating stream computing systems | |
| FR2907240A1 (fr) | Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants | |
| Quadri | MARTE based model driven design methodology for targeting dynamically reconfigurable FPGA based SoCs | |
| FR2971596A1 (fr) | Dispositif pour accelerer l'execution d'une simulation systemc | |
| Raaijmakers | Run-Time Partial Reconfiguration on the Virtex-II Pro | |
| FR2902211A1 (fr) | Procede de simulation d'un systeme complexe avec construction d'au moins un modele comprenant au moins un routeur modelise, produit programme d'ordinateur et moyen de stockage correspondants | |
| WO2014124852A2 (fr) | Dispositif et procédé pour accélérer la phase de mise à jour d'un noyau de simulation | |
| CA2887077C (fr) | Systeme de traitement de donnees pour interface graphique et interface graphique comportant un tel systeme de traitement de donnees | |
| US9256405B1 (en) | Code generation based on regional upsampling-based delay insertion | |
| Peñil et al. | Automatic synthesis from UML/MARTE models using channel semantics | |
| Sangiovanni-Vincentelli et al. | A vision for embedded software | |
| FR2914525A1 (fr) | Procede de simulation transactionnelle d'un modele generique de noeud de communication, produit programme d'ordinateur et moyen de stockage correspondants | |
| JP2023548392A (ja) | 異種集積回路のためのモデルベース設計および区分 | |
| Jaber | High-Level soc modeling and performance estimation applied to a multi-core implementation of LTE enodeb physical layer |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 06708072 Country of ref document: EP Kind code of ref document: A2 |
|
| WWW | Wipo information: withdrawn in national office |
Ref document number: 6708072 Country of ref document: EP |
|
| WWE | Wipo information: entry into national phase |
Ref document number: 11815829 Country of ref document: US |