FR2907240A1 - Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants - Google Patents

Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants Download PDF

Info

Publication number
FR2907240A1
FR2907240A1 FR0608913A FR0608913A FR2907240A1 FR 2907240 A1 FR2907240 A1 FR 2907240A1 FR 0608913 A FR0608913 A FR 0608913A FR 0608913 A FR0608913 A FR 0608913A FR 2907240 A1 FR2907240 A1 FR 2907240A1
Authority
FR
France
Prior art keywords
vector
instance
model
instances
modeled
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0608913A
Other languages
English (en)
Inventor
Jean Paul Calvez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Cofluent Design SARL
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cofluent Design SARL filed Critical Cofluent Design SARL
Priority to FR0608913A priority Critical patent/FR2907240A1/fr
Priority to US11/870,920 priority patent/US7991603B2/en
Publication of FR2907240A1 publication Critical patent/FR2907240A1/fr
Priority to US13/161,197 priority patent/US20110246168A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking

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)
  • Stored Programmes (AREA)
  • Feedback Control In General (AREA)

Abstract

L'invention concerne un procédé de simulation d'un système complexe comprenant une pluralité de constituants, ledit procédé comprenant une étape de construction d'au moins un modèle du système complexe (31, 32), chaque modèle du système comprenant un ensemble hiérarchisé de constituants modélisés, ladite étape de construction comprenant, pour chaque modèle, une étape d'obtention d'un modèle hiérarchique multi-instances comprenant au moins un vecteur d'instances correspondant à une pluralité d'instances d'un même constituant modélisé, chaque vecteur d'instances pouvant se situer à tout niveau d'un arbre de décomposition hiérarchique dudit modèle hiérarchique multi-instances. L'étape de construction comprend en outre, pour chaque modèle, une étape d'expansion (35, 36) dudit modèle hiérarchique multi-instances en un modèle développé (33, 34), par expansion d'au moins un vecteur d'instances compris dans ledit modèle hiérarchique multi-instances.

Description

1 Procédé de simulation d'un système complexe avec expansion de vecteurs
d'instances, 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 une pluralité de constituants, tels que par exemple un ou plusieurs processeurs exécutant un ensemble de fonctions (éventuellement 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. 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 comme ressources d'exécution pour les services. Cependant, du fait que la technique de l'invention repose sur des concepts généraux de constituants (tels que des tâches (fonctions), des processeurs (et donc des ressources d'exécution) et des ordonnanceurs), elle a une application plus large que celle 2907240 2 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 (description par instances multiples, aussi appelées vecteurs d'instances) se veut tout particulièrement adaptée aux technologies nouvelles 5 des télécommunications et du multimédia. En effet, l'évolution des besoins client, des standards de traitement des données, voix et vidéo et des communications conduisent à devoir créer des équipements évolutifs incluant de plus en plus de parallélisme de fonctions et de communications. Dans les systèmes électroniques et informatiques, les systèmes complexes sont 10 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 15 programmables (ou FPGA pour Field Programmable Gate 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 20 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, 25 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. 30 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 2907240 3 é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 5 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 ). 10 De façon classique, l'étude des systèmes complexes passe par leur modélisation fonctionnelle d'abord et architecturale ensuite. Ces modèles servent à assurer des vérifications et analyses de propriétés tant fonctionnelles que de performances. Les propriétés sont obtenues par simulation des modèles. Pour plus d'informations, se référer à la méthodologie MCSE (Méthode de Conception de Systèmes Electroniques) et 15 aux outils CoFluent Studio (marque déposée) de la société CoFluent Design (déposante de la présente demande de brevet), qui mettent en oeuvre une partie de cette méthodologie MCSE. Plus précisément, l'invention concerne une technique de simulation d'un système complexe, avec création d'un ou plusieurs modèles sur la base de vecteurs de 20 constituants (un vecteur d'instances correspond à une pluralité d'instances d'un même constituant modélisé) facilitant la modélisation, la vérification de tels systèmes et l'exploration des architectures possibles. 2. ART ANTÉRIEUR L'utilisation de vecteurs de constituants lors de la création d'un modèle de 25 système complexe répond aujourd'hui à un besoin naissant car de plus en plus de systèmes sont construits par assemblage de plusieurs exemplaires (ou instances) de constituants (aussi appelés composants). Se pose alors le problème de décrire de tels modèles d'architectures et de les transformer afin d'étudier leurs propriétés. Pour l'illustration du problème, considérons les produits du type réseaux de 30 communications. Plus précisément, à titre d'exemple les figures 1 et 2 illustrent le cas d'un commutateur Ethernet. 2907240 4 La figure 1 montre la fonctionnalité souhaitée 10. Les trames reçues sur chacun des ports d'entrée doivent être retransmises le plus rapidement possible vers l'un des ports destinataires ou vers les trois autres ports (diffusion, ou broadcast en anglais) en fonction de l'adresse de destination trouvée dans la trame entrante. Bien sûr les 5 performances voulues requièrent le maximum de transmissions simultanées et sans perte de trames. La partie haute de la figure 2 montre une solution possible d'architecture fonctionnelle 21 représentant les fonctions internes nécessaires et des couplages entre ces fonctions. Il est clair que l'architecture doit se baser sur des vecteurs de récepteurs 10 ( Récepteur[1:N] ) 23 et d'émetteurs ( Emetteur[1:N] ) 24 en rapport avec le nombre de ports du commutateur et que le routage des trames nécessite un ensemble de relations par files de messages ( message queues en anglais) de type FIFO ( First-In First-Out , c'est-à-dire premier entré premier sorti ). La partie basse de la figure 2 est une proposition possible de représentation de 15 l'architecture interne matérielle 22. Un vecteur de p processeurs ( Proc[l:p] ) 25 est utilisé et les processeurs communiquent par une mémoire commune 26. Chaque processeur possède deux parties (ProcTx 27 et ProcTx 28) et qui sont aussi couplées par un bus 210 et une mémoire locale 29. La figure 2 montre l'intérêt du concept de vecteurs de composants et de relations 20 pour décrire des architectures complexes et nouvelles. Mais l'emploi de ce concept de vecteurs, qui simplifie la représentation, rend bien plus difficile deux aspects : - la vérification du comportement détaillé du modèle fonctionnel parce que chaque élément de chaque vecteur n'est pas identifié séparément ; et 25 -la construction du modèle architectural résultant du mappage (référencé 211 sur la figure 2) de l'architecture fonctionnelle sur l'architecture matérielle. En effet, il devient quasi impossible de pouvoir mapper chaque élément de vecteurs de fonctions ou de relations fonctionnelles (vecteurs de constituants de l'architecture fonctionnelle) sur un élément de vecteurs de processeurs, de bus ou 30 de mémoires (vecteurs de constituants de l'architecture matérielle). 2907240 5 Un nouveau degré de complexité apparaît aussi avec les produits configurables du type FPGA et qui justifie l'emploi du concept de vecteurs d'instances. En effet, l'architecture même de ces composants permet l'instanciation d'un nombre quelconque de processeurs, mémoires, FIFOs et bus, et ceci selon des topologies très variées. 5 On connaît, dans l'art antérieur, deux techniques de description des modèles fonctionnels ou physiques (dits aussi de plates-formes) des systèmes complexes. Dans la première technique connue, presque exclusivement utilisée aujourd'hui, la description des modèles des systèmes complexes consiste à dessiner individuellement chaque constituant modélisé, ainsi que toutes les interconnexions entre les constituants 10 modélisés. Le modèle de chaque constituant peut provenir d'un modèle en librairie afin de faciliter la duplication. L'inconvénient majeur de la première technique connue de description est le temps important pour la saisie et le caractère non générique (c'est-à-dire la non adaptation à un nombre modifiable de constituants). 15 Dans la seconde technique connue, utilisée aujourd'hui seulement dans quelques cas particuliers, la description des modèles des systèmes complexes s'appuie sur un mécanisme permettant d'indiquer la multiplicité des constituants (notion de vecteur d'instances au sens précité). Les interconnexions respectent alors des motifs plutôt réguliers. 20 Cette technique de représentation d'un modèle (modèle d'application ou modèle de plate-forme) par utilisation d'instances multiples de constituants (fonctions et relations, ou bien processeurs, mémoires et noeuds de communication) est exploitée dans les outils CoFluent Studio (marqué déposée) précités depuis Juin 2005. Elle est détaillée dans l'ouvrage suivant publié par l'inventeur de la présente 25 demande : A System-Level Performance Model and Method. Jean-Paul Calvez, Chapter 2 in Meta-Modeling: Performance and Information Modeling. pp57-102 - 1996 CIEM Vol 6 (Current Issues in Electronic Modeling). Edited by Jean-Michel Bergé, Oz Levia, Jacques Rouillard. Kluwer Academic Publishers ISBN 0-7923-9687-1 . On notera que la représentation d'une fonction, une relation, un processeur, une 30 mémoire ou un noeud de communication, est par exemple faite sous la forme graphique d'un rectangle ou d'un cercle avec son ombre pour indiquer la multiplicité. Cependant 2907240 6 cette forme de représentation n'est pas limitative. Toute forme est exploitable comme représentation de ce concept (texte par exemple sous la forme d'un vecteur [1 :N]). La seconde technique connue simplifie fortement le travail de saisie des modèles et structure mieux leur régularité et leur généricité. La multiplicité (notion de vecteur 5 d'instances) peut se décrire pour n'importe quel niveau de la représentation hiérarchique du modèle. Des vecteurs d'instances (aussi appelés instances multiples) peuvent être imbriqués. Toutefois la seconde technique connue présente l'inconvénient de restreindre beaucoup les possibilités d'architectures. En effet, chaque vecteur d'instances est 10 considéré comme un constituant non décomposable et donc ne peut que s'allouer globalement sur une seule ressource du type processeur. Un vecteur d'instances de processeurs ne peut pas s'utiliser directement car il n'est pas simple de définir le mappage de fonctions sur chaque processeur du vecteur. De plus, tous les éléments d'un vecteur ont les mêmes propriétés. 15 Un autre inconvénient de la seconde technique connue est qu'elle ne facilite pas non plus la vérification du modèle obtenu. En effet, la simulation de ce modèle fournit un déroulement temporel dont la compréhension est assez complexe et sujette à mauvaise interprétation compte tenu de la superposition d'états des vecteurs d'instances (constituants multiples) (voir l'exemple de la figure 6). 20 Les inconvénients ci-dessus conduisent à la situation que les concepteurs ne créent pas ou très peu de modèles de telles architectures. Ainsi l'étude de telles architectures et l'exploration des solutions potentielles n'est pas faite ou très difficilement, ce qui conduit à des difficultés de prises de décisions pour de tels produits. 3. OBJECTIFS DE L'INVENTION 25 L'invention, dans au moins un mode de réalisation, 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, dans au moins un mode de réalisation, est de fournir une technique de simulation d'un système complexe avec construction d'au moins un modèle de ce système, cette technique permettant 30 d'utiliser le concept de vecteur d'instances (au sens précité) sans pour autant restreindre les possibilités d'architecture (meilleure exploration des architectures de solutions) et 2907240 7 tout en facilitant la vérification du ou des modèles construits (c'est-à-dire l'analyse détaillée du comportement du modèle). L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 5 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de simulation d'un système complexe comprenant une pluralité de constituants, ledit procédé comprenant une étape de construction d'au moins un modèle du système complexe, chaque modèle du système comprenant un ensemble hiérarchisé de 10 constituants modélisés, ladite étape de construction comprenant, pour chaque modèle, une étape d'obtention d'un modèle hiérarchique multi-instances comprenant au moins un vecteur d'instances correspondant à une pluralité d'instances d'un même constituant modélisé, chaque vecteur d'instances pouvant se situer à tout niveau d'un arbre de décomposition hiérarchique dudit modèle hiérarchique multi-instances. Ladite étape de 15 construction comprend en outre, pour chaque modèle, une étape d'expansion dudit modèle hiérarchique multi-instances en un modèle développé, par expansion d'au moins un vecteur d'instances compris dans ledit modèle hiérarchique multi-instances. Le principe général de l'invention est donc l'emploi d'une opération de transformation d'un modèle hiérarchique multiinstances en un modèle développé (aussi 20 appelé modèle expansé , ou expanded model en anglais). Ainsi, on continue d'utiliser le concept de vecteur d'instances pour obtenir le modèle hiérarchique multiinstances. Mais on va plus loin en obtenant à partir de celui-ci un modèle hiérarchique développé, qui n'implique aucune limitation dans les possibilités d'architecture (meilleure exploration des architectures de solutions) et est aisément vérifiable 25 (l'analyse de son comportement est simple). De façon avantageuse, l'étape d'expansion dudit au moins un modèle hiérarchique multi-instances comprend elle-même les étapes suivantes, effectuées pour chaque vecteur d'instances à développer correspondant à N instances d'un constituant modélisé : 30 - développement dudit vecteur d'instances en un nombre de constituants modélisés égal audit nombre N d'instances ; et 2907240 8 - production de la ou les entrée(s) et/ou la ou les sortie(s) de chacun des N constituants modélisés, selon un jeu d'au moins une règle de production. Avantageusement, l'étape d'expansion dudit au moins un modèle hiérarchique multi-instances comprend les étapes suivantes : 5 descente dudit arbre de décomposition hiérarchique, de façon récursive depuis une racine jusqu'à des feuilles, de sorte que pour chaque niveau dudit arbre de décomposition hiérarchique, chaque vecteur d'instances à développer est développé en un nombre prédéterminé de constituants modélisés ; - remontée dudit arbre de décomposition hiérarchique, de façon récursive depuis 10 les feuilles jusqu'à la racine, de sorte que pour chaque niveau dudit arbre de décomposition hiérarchique, la ou les entrée(s) et/ou la ou les sortie(s) des constituants modélisés résultant du développement d'un vecteur d'instances sont produites selon ledit jeu d'au moins une règle de production. Dans un premier mode de réalisation de l'invention, ladite étape d'expansion est 15 systématique et consiste en une expansion de tous les vecteur d'instances. Dans un second mode de réalisation de l'invention, ladite étape d'expansion est sélective et consiste en une expansion uniquement des vecteurs d'instances associés à un attribut d'expansion prenant une valeur indiquant qu'une expansion doit être effectuée. Dans un mode de réalisation particulier de l'invention, ledit système complexe 20 est un système électronique complexe. Avantageusement, le procédé comprend une étape de construction d'un modèle fonctionnel du système complexe, comprenant elle-même une étape d'obtention d'un modèle fonctionnel hiérarchique multi-instances et une étape d'expansion dudit modèle fonctionnel hiérarchique multi-instances en un modèle fonctionnel développé. 25 De façon avantageuse, ledit modèle fonctionnel hiérarchique multi-instances comprend au moins un vecteur d'instances appartenant au groupe comprenant : - des vecteurs de fonctions correspondant chacun à une pluralité d'instances d'une fonction modélisée ; et des vecteurs de relations correspondant chacun à une pluralité d'instances d'une 30 relation modélisée. 2907240 9 De façon avantageuse, comprend une étape de construction d'un modèle de plate-forme hiérarchique du système complexe, comprenant elle-même une étape d'obtention d'un modèle de plate-forme hiérarchique multi-instances et une étape d'expansion dudit modèle de plate-forme hiérarchique multi-instances en un modèle de 5 plate-forme développé. De façon avantageuse, ledit modèle de plate-forme hiérarchique multi-instances comprend au moins un vecteur d'instances appartenant au groupe comprenant : - des vecteurs de processeurs correspondant chacun à une pluralité d'instances d'un processeur modélisé ; 10 - des vecteurs de mémoires correspondant chacun à une pluralité d'instances d'une mémoire modélisée ; et - des vecteurs de noeuds de communication correspondant chacun à une pluralité d'instances d'un noeud de communication modélisé. Avantageusement, le procédé comprend une étape d'allocation distribuée dudit 15 modèle fonctionnel développé sur ledit modèle de plate-forme développé, permettant d'obtenir un modèle architectural développé dudit système complexe. Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit 20 programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé précité, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant 25 un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé précité. 5. LISTE DES FIGURES, D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel 30 de l'invention, donné à titre d'exemple indicatif et non limitatif (tous les modes de 5 10 15 20 25 30 2907240 10 réalisation de l'invention ne sont pas limités aux caractéristiques et avantages de ce mode de réalisation préférentiel), et des dessins annexés, dans lesquels : la figure 1 illustre, à titre d'exemple d'un système complexe, un commutateur Ethernet; la figure 2 présente un exemple de modèle fonctionnel multi-instances et de modèle de plate-forme multi-instances pour le commutateur Ethernet de la figure 1; la figure 3 illustre le principe général de l'invention, à travers un exemple d'expansion d'un modèle fonctionnel multi-instances et un modèle de plate-forme multi-instances ; la figure 4 présente un exemple d'expansion selon l'invention d'un modèle de plate-forme, selon un motif en anneau en horizontal et un motif linéaire en vertical; la figure 5 présente un exemple de modèle fonctionnel multi-instances, non développé ; la figure 6 présente un exemple de déroulement temporel obtenu par simulation du modèle non développé de la figure 5 ; la figure 7 illustre un exemple d'outil logiciel d'édition des attributs des constituants modélisés (composants) d'un modèle, et notamment d'un attribut d'expansion selon la présente invention ; la figure 8 présente un exemple de déroulement temporel obtenu par simulation du modèle développé obtenu par expansion selon l'invention du modèle fonctionnel multi-instances de la figure 5 ; la figure 9 présente un exemple de modèle de plate-forme multi-instances, non développé ; la figure 10 présente un exemple de modèle de plate-forme développé, obtenu par expansion selon l'invention du modèle de plate-forme multi-instances de la figure 9 ; la figure 11 présente une partie d'un exemple de modèle architectural développé, résultant du mappage du modèle fonctionnel développé obtenu par expansion du 2907240 11 modèle fonctionnel multi-instances de la figure 5, sur le modèle de plate-forme développé de la figure 10 ; et la figure 12 présente un exemple de déroulement temporel obtenu par simulation du modèle architectural développé présenté partiellement sur la figure 11. 5 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 6.1 Principe général La figure 3 illustre le principe général de l'invention, à travers un exemple 10 d'expansion d'un modèle fonctionnel multi-instances 31 et un modèle de plate-forme multiinstances 32. Ces modèles 31, 32, représentés sur la partie gauche de la figure 3, résultent d'une modélisation faite par le concepteur, à l'aide par exemple de la technologie CoFluent Studio (marque déposée), en utilisant le concept de vecteur d'instances. Sur la partie droite de la figure 3 sont représentés les modèles développés 15 33, 34 résultant d'une expansion (symbolisée par les flèches référencées 35 et 36 respectivement) de chacun des modèles précités 31, 32. L'expansion peut être systématique (expansion de tous les vecteur d'instances) ou sélective (expansion uniquement des vecteurs d'instances associés à un attribut d'expansion prenant une valeur indiquant qu'une expansion doit être effectuée). 20 L'intérêt résultant apparaît sur la droite car après expansion, le modèle fonctionnel développé est aisément vérifiable et tout constituant fonctionnel modélisé et individualisé peut se mapper sur n'importe quel constituant d'exécution de la plate-forme modélisé et individualisé, pour l'étude d'architectures. Le mappage (aussi appelé allocation distribuée ) du modèle fonctionnel développé sur le modèle de plate-forme 25 développé est symbolisé par la flèche référencée 37. Le principe général de l'invention est donc l'emploi d'une opération de transformation d'un modèle multi-instances en un modèle développé ("expanded model" en anglais). La transformation est globale (tous les constituants sont développés) ou sélective (pour chaque constituant multi-instances, un attribut indique l'expansion ou 30 non). Le résultat de la transformation se veut optimisé dans le sens ou les entrées-sorties nécessaires pour chaque composant sont produites (relation de 1 vers 1 ou de 1 vers N) 10 15 20 25 30 2907240 12 et le modèle comportemental de chaque fonction élémentaire (non-représenté sur la figure) est aussi optimisé selon les entrées-sorties nécessaires. Le principe de la transformation pour le développement (aussi appelé l'expansion ) du modèle fonctionnel est le suivant, dans un mode de réalisation 5 particulier de l'invention : 1. La transformation commence par le niveau global (racine) du modèle fonctionnel, considéré comme premier composant courant sans entrées-sorties. 2. Pour chaque vecteur de relations compris dans le composant courant, la relation modélisée est dupliquée en une pluralité d'instances et chacune des instances de la relation modélisée est nommée par ajout d'un index à son nom. 3. Pour chaque vecteur de fonctions compris dans le composant courant, la fonction modélisée est dupliquée en une pluralité d'instances et chacune des instances de la fonction modélisée est nommée par ajout d'un index à son nom. 4. La procédure se poursuit récursivement pour chaque fonction modélisée interne après duplication, en la considérant comme nouveau composant courant (retour en 2). L'index du niveau supérieur est propagé et concaténé avec l'index courant. 5. La récursivité se termine quand le composant courant est terminal ou feuille de l'arbre de décomposition. En d'autres termes, les étapes 1 à 5 permettent une descente d'un arbre de décomposition hiérarchique du modèle hiérarchique fonctionnel, de façon récursive depuis une racine jusqu'à des feuilles, de sorte que pour chaque niveau de l'arbre, chaque vecteur d'instances à développer est développé en un nombre prédéterminé de constituants modélisés. 6. Puis, pour chaque feuille de l'arbre de décomposition, on cherche à optimiser le modèle comportemental de chaque fonction élémentaire dont plusieurs instances sont comprises dans cette feuille, sous la forme d'un vecteur de fonctions élémentaires. On appelle fonction élémentaire une fonction qui ne comprend pas elle-même une autre fonction. L'optimisation concerne le ou les sélecteurs qui sont compris dans le modèle comportemental et permettent, en entrée et/ou en sortie de la fonction élémentaire concernée, de choisir une instance de constituant émettrice en entrée et/ou une instance de constituant destinatrice en sortie, pour chaque instance du vecteur de fonctions élémentaires. Ces sélecteurs 5 10 15 20 25 30 2907240 13 sont nécessaires pour spécialiser les entrées-sorties et le comportement de chaque instance du vecteur de fonctions élémentaires, mais n'ont plus lieu d'être une fois l'expansion de ce vecteur accomplie. L'optimisation consiste donc à représenter l'effet des sélecteurs dans le comportement de chaque instance du vecteur. Ainsi, l'optimisation peut donner lieu à une simplification ou complexification du comportement de l'instance de composant considérée (par exemple ajout d'alternatives dans le flot de contrôle) en fonction de la présence ou non de sélecteurs d'entrée etsortie et de la valeur de la condition de sélection. 7. Ensuite, pour chaque feuille de l'arbre de décomposition, les entrées et sorties de chaque fonction élémentaire modélisée, résultant du développement d'un vecteur de fonctions élémentaires, sont produites en fonction des optimisations et des liens avec les relations modélisées ou les vecteurs de relations auxquel(le)s ces entrées et sorties sont connectées. Un jeu complet de règles de production des entrées et sorties est fourni ci-après. En résumé, chaque entrée ou sortie d'un vecteur est soit développée et donc remplacée par autant d'entrées ou sorties que d'instances dans le vecteur, soit remplacée par une seule entrée ou sortie correspondant à l'indice de l'instance considérée. 8. Cette adaptation des entrées-sorties des composants est poursuivie lors d'une remontée de l'arbre de décomposition hiérarchique, de façon récursive depuis les feuilles jusqu'à la racine (niveau global), de sorte que pour chaque niveau de l'arbre, la ou les entrée(s) et/ou la ou les sortie(s) des constituants modélisés résultant du développement d'un vecteur d'instances sont produites selon le jeu de règles de production. Pour les fonctions composites modélisées ou les vecteurs de fonctions composites, la détermination des entrées et sorties se déduit des entrées et sorties des fonctions modélisées internes (notamment, une relation du type 1 vers 1 en sortie, respectivement entrée, d'une fonction composite modélisée n'est possible que si toutes les sorties, respectivement entrées, des fonctions internes sont également du type 1 vers 1 ). On appelle fonction composite (ou fonction non élémentaire) une fonction qui comprend elle-même une autre fonction. 2907240 14 Dans un mode de réalisation particulier de l'invention, le principe de la transformation pour l'expansion du modèle de plate-forme est assez similaire mais plus simple car les composants terminaux (dans les feuilles de l'arbre de décomposition) ne possèdent pas de modèle comportemental : 5 1. La transformation commence par le niveau global (racine) du modèle de plate-forme, considéré comme premier composant courant sans entrées-sorties. 2. Pour chaque vecteur d'instances compris dans le composant courant, le constituant modélisé (processeur, mémoire ou noeud de communication) est dupliqué en une pluralité d'instances et chacune des instances est nommée par 10 ajout d'un index à son nom. 3. La procédure se poursuit récursivement pour chaque constituant modélisé interne après duplication, en le considérant comme nouveau composant courant (retour en 2). L'index du niveau supérieur est propagé et concaténé avec l'index courant. 4. La récursivité se termine quand le composant courant est terminal ou feuille de 15 l'arbre de décomposition. En d'autres termes, les étapes 1 à 4 permettent une descente d'un arbre de décomposition hiérarchique du modèle hiérarchique de plate-forme, de façon récursive depuis une racine jusqu'à des feuilles, de sorte que pour chaque niveau de l'arbre, chaque vecteur d'instances à développer est développé en un nombre prédéterminé de constituants modélisés. 20 5. Ensuite, pour chaque feuille de l'arbre de décomposition, les entrées et sorties de chaque constituant modélisé, résultant du développement d'un vecteur d'instances, sont produites en fonction d'un jeu de règles de production (voir exemple de jeu ci-après). 6. Cette adaptation des entrées-sorties des composants est poursuivie lors d'une 25 remontée de l'arbre de décomposition hiérarchique, de façon récursive depuis les feuilles jusqu'à la racine (niveau global), de sorte que pour chaque niveau de l'arbre, la ou les entrée(s) et/ou la ou les sortie(s) des constituants modélisés résultant du développement d'un vecteur d'instances sont produites selon le jeu de règles de production. 30 6.2 Exemple de jeu de règles de production des entrées-sorties 6.2.1 Production des entrées-sorties d'un modèle fonctionnel développé 2907240 15 On suppose dans la suite que le modèle fonctionnel hiérarchique multi-instances qui est à développer, pour obtenir le modèle fonctionnel hiérarchique développé, comprend au moins un vecteur d'instances appartenant au groupe comprenant : - des vecteurs de fonctions correspondant chacun à une pluralité d'instances d'une 5 fonction modélisée ; et - des vecteurs de relations correspondant chacun à une pluralité d'instances d'une relation modélisée. Le jeu de règles de production comprend les règles suivantes appliquées aux vecteurs de fonctions élémentaires correspondant chacun à une pluralité d'instances 10 d'une fonction élémentaire modélisée : - si, dans le modèle hiérarchique multi-instance, une sortie d'un vecteur de fonctions élémentaires (feuilles de l'arbre de décomposition) est reliée à un vecteur de relations : * si la sortie du vecteur de fonctions élémentaires est associée à un sélecteur de sortie compris dans le modèle comportemental de la fonction élémentaire modélisée : - si le sélecteur de sortie est défini par un paramètre indiquant une affectation selon une relation 1 vers 1 , alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède une sortie reliée, selon la relation 1 vers 1 , à une instance de même indice parmi les instances obtenues après développement du vecteur de relations ; - si le sélecteur de sortie est défini par un paramètre indiquant une affectation selon une relation 1 vers X , avec X>1, alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède X sorties, chacune reliée à une instance de même indice parmi les instances obtenues après développement du vecteur de relations ; * si la sortie du vecteur de fonctions élémentaires n'est pas associée à un sélecteur de sortie compris dans un modèle comportemental de la fonction élémentaire modélisée, alors chaque instance obtenue après développement 15 20 25 30 2907240 16 du vecteur de fonctions élémentaires possède une sortie reliée, selon une relation 1 vers 1 , à une instance de même indice parmi les instances obtenues après développement du vecteur de relations. si, dans le modèle hiérarchique multi-instance, une entrée d'un vecteur de 5 fonctions élémentaires (feuilles de l'arbre de décomposition) est reliée à un vecteur de relations : * si l'entrée du vecteur de fonctions élémentaires est associée à un sélecteur d'entrée compris dans le modèle comportemental de la fonction élémentaire modélisée : 10 - si le sélecteur d'entrée est défini par un paramètre indiquant une affectation selon une relation 1 vers 1 , alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède une entrée reliée, selon la relation 1 vers 1 , à une instance de même indice parmi les instances obtenues après développement du vecteur de 15 relations ; - si le sélecteur d'entrée est défini par un paramètre indiquant une affectation selon une relation 1 vers X , avec X>1, alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède X entrées, chacune reliée à une instance de même 20 indice parmi les instances obtenues après développement du vecteur de relations ; * si l'entrée du vecteur de fonctions élémentaires n'est pas associée à un sélecteur d'entrée compris dans un modèle comportemental de la fonction élémentaire modélisée, alors chaque instance obtenue après développement 25 du vecteur de fonctions élémentaires possède X entrées, chacune reliée à une instance de même indice parmi les instances obtenues après développement du vecteur de relations. Une optimisation du modèle comportemental de la fonction élémentaire modélisée consiste à y supprimer : 30 - tout sélecteur de sortie associé à la fonction élémentaire modélisée et indiquant une affectation selon une relation 1 vers 1 ; et/ou 2907240 17 - tout sélecteur d'entrée associé à la fonction élémentaire modélisée et indiquant une affectation selon une relation 1 vers X . Le jeu de règles de production comprend en outre la règle suivante appliquée, durant l'étape de remontée de l'arbre de décomposition, aux vecteurs de fonctions non 5 élémentaires (aussi appelées fonctions composites) correspondant chacun à une pluralité d'instances d'une fonction non élémentaire modélisée : - si, dans le modèle hiérarchique multi-instance, une entrée, respectivement sortie, d'un vecteur de fonctions non élémentaires est reliée à un vecteur de relations : * s'il existe une relation 1 vers 1 pour toutes les entrées, respectivement sortries, reliées audit vecteur de relations et appartenant à des fonctions qui sont internes à ladite fonction non élémentaire modélisée, chaque instance obtenue après développement du vecteur de fonctions non élémentaires possède une entrée, respectivement sortie, reliée selon une relation 1 vers 1 à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations ; * sinon, chaque instance obtenue après développement du vecteur de fonctions non élémentaires possède X entrées, respectivement sorties, chacune reliée à une entrée, respectivement sortie, de même indice pour toutes les instances obtenues après développement dudit vecteur de relations. Le jeu de règles de production comprend en outre les règles suivantes : si, dans le modèle hiérarchique multi-instance, une sortie d'un vecteur de fonctions, élémentaires ou non élémentaires, est reliée à une relation modélisée non vectorisée, alors chaque instance obtenue après développement du vecteur de fonctions possède une sortie reliée à la relation modélisée ; - si, dans le modèle hiérarchique multi-instance, une entrée d'un vecteur de fonctions, élémentaires ou non élémentaires, est reliée à une relation modélisée non vectorisée, alors chaque instance obtenue après développement du vecteur de fonctions possède une entrée reliée à la relation modélisée. 30 6.2.2 Production des entrées-sorties d'un modèle de plate-forme développé 10 15 20 25 2907240 18 On suppose dans la suite que le modèle de plate-forme hiérarchique multiinstances qui est à développer, pour obtenir le modèle plate-forme hiérarchique développé, comprend au moins un vecteur d'instances appartenant au groupe comprenant : 5 - des vecteurs de processeurs correspondant chacun à une pluralité d'instances d'un processeur modélisé ; - des vecteurs de mémoires correspondant chacun à une pluralité d'instances d'une mémoire modélisée ; et - des vecteurs de noeuds de communication correspondant chacun à une pluralité 10 d'instances d'un noeud de communication modélisé. Chaque vecteur de noeuds de communication est associé un paramètre de configuration d'expansion. Le jeu de règles de production comprend les règles suivantes, pour chaque vecteur de noeuds de communication relié à un vecteur de processeurs ou mémoires : 15 - si le paramètre de configuration d'expansion indique liens vers tous , alors chaque instance du vecteur de noeuds de communication est reliée à chacune des instances du vecteur de processeurs ou mémoires ; - si le paramètre de configuration d'expansion indique linéaire , alors les instances du vecteur de processeurs ou mémoires sont reliées entre elles de façon 20 linéaire, via des instances du vecteur de noeuds de communication. Le noeud modélisé i est relié au processeur modélisé ou à la mémoire modélisée i d'un côté et au processeur modélisé ou à la mémoire modélisée 41 de l'autre, si i<N avec N le nombre d'instances du vecteur de processeurs ou mémoires développé ;et 25 - si le paramètre de configuration d'expansion indique anneau , alors les instances du vecteur de processeurs ou mémoires sont reliées entre elles en anneau, via des instances du vecteur de noeuds de communication. Le noeud modélisé i est relié au processeur modélisé ou à la mémoire modélisée i d'un côté et au processeur modélisé ou à la mémoire modélisée i+1 de l'autre, si i<N 30 avec N le nombre d'instances du vecteur de processeurs ou mémoires développé. Le noeud modélisé i est relié au processeur modélisé ou à la mémoire modélisée i 2907240 19 d'un côté et au processeur modélisé ou à la mémoire modélisée 1 de l'autre, si i=N. Il est clair que des motifs de configuration d'expansion autres que ceux précités ( liens vers tous , linéaire et anneau ) peuvent être envisagés
sans sortir du 5 cadre de la présente invention. La figure 4 présente un exemple d'expansion selon l'invention d'un modèle de plate-forme 41, selon un motif en anneau pour "Node2" et un motif linéaire pour "Node1". Le modèle développé résultant est référencé 42. 6.3 Descriptif détaillé illustré 10 Dans la suite de la description, on présente un exemple d'exploitation du procédé selon l'invention (technologie sous-jacente de l'expansion de modèles), dans une nouvelle version des outils CoFluent Studio (marque déposée), pour l'obtention d'un modèle fonctionnel développé ("expanded" en anglais) puis d'un modèle architectural développé. Les différents modèles sont représentés suivant les notations et la sémantique 15 décrites dans MCSE. 6.3.1 Création du modèle d'application L'éditeur graphique de CoFluent Studio sert à capturer les modèles fonctionnels (aussi appelés modèles d'applications) constitués de fonctions communicantes et concurrentes disposant de leur propre comportement et entrées-sorties.
20 La figure 5 présente l'exemple illustratif considéré pour le modèle fonctionnel multi- instances (non développé). Il est composé de fonctions modélisées simples ("Monitor", référencée 51) et hiérarchiques ("Appli" et "Appli2", référencées 52 et 53 respectivement), des vecteurs de fonctions ("Service", "Appli l " et "Appli2l ", référencées 54, 55 et 56 respectivement) 25 et des vecteurs de relations fonctionnelles ( Chant , Chan2 , Chan3 , Chan4 et Var , référencées 57 à 61 respectivement). Pour chaque fonction élémentaire modélisée 51 ou vecteur de fonctions élémentaires 54, 55, 56, un graphe de son modèle comportemental est représenté dans le bloc représentant cette fonction élémentaire modélisée ou ce vecteur de fonctions élémentaires. Ces modèles comportementaux 30 comprennent des sélecteurs de sortie référencés 62 à 64, et des sélecteurs d'entrée référencés 65 et 66.
2907240 20 Il représente un système clients-serveurs et leurs couplages. Les modèles comportementaux des fonctions modélisées permettent de comprendre assez aisément le fonctionnement. Les sélecteurs utilisés sur les entrées et sorties permettent de désigner respectivement l'entrée source ou la sortie destinataire.
5 Chaque instance de "Service" envoie une requête dans la file de message correspondante de "Chan 1 " (relation de 1 vers 1 car pas de sélecteur en sortie de "Service"). Chaque instance de "Appli 1" est en attente sur toutes les instances de "Chan1" (car pas de sélecteur en entrée). Chaque instance de "Appli 1" communique avec une 10 instance de "Appli2l" (côté serveur) en désignant le correspondant par les sélecteurs de sortie 63, 64 et d'entrée 66. Enfin, chaque instance de "Applil" fournit un message après "Opl1", via l'instance correspondante de "Chan4" (pas de sélecteur), à la fonction "Monitor" qui est en attente sur toutes les instances de "Chan4". Chaque instance de "Appli2l" (côté serveur) est en attente sur l'instance 15 correspondante de "Chan2", exploite l'instance correspondante de "Var" et fournit son résultat à l'instance de "Applil" (côté client) qui a provoqué l'activation. Ceci s'obtient si le client indique dans sa requête son numéro d'instance. La simulation directe de ce modèle non développé, avec l'outil CoFluent Studio, fournit le déroulement temporel présenté sur la figure 6 (pour une description et 20 compréhension détaillée de cette représentation, se reporter à la documentation de CoFluent Studio). La compréhension de ce déroulement reste assez complexe et sujette à mauvaise interprétation compte tenu de la superposition d'états des fonctions et relations multiples. 6.3.2 Expansion sélective du modèle d'application 25 La figure 7 illustre un exemple d'outil logiciel d'édition des attributs des constituants modélisés d'un modèle. Il permet notamment de définir, pour chaque vecteur d'instances, un attribut d'expansion. Ainsi, l'expansion sélective souhaitée est paramétrée par l'éditeur d'attributs : pour chaque vecteur de fonctions ou de relations, un attribut d'expansion apparaît, qui peut être assigné à vrai ou faux.
30 Plus précisément, dans cet exemple, la fenêtre de gauche 72 affiche la hiérarchie du modèle fonctionnel (les noms des éléments sont identiques à ceux de la figure 5) 2907240 21 ainsi que l'élément de cette hiérarchie couramment sélectionné (il apparaît dans un cadre grisé : Service[l:ClientNumber] dans cet exemple) et dont les attributs peuvent donc être définis. La fenêtre de droite 71 affiche les attributs de l'élément sélectionné dans la fenêtre de gauche 72. Dans l'exemple illustré, c'est le vecteur de fonctions élémentaires 5 appelé Service[l:ClientNumber] et référencé 54 sur la figure 5. La fenêtre de droite 71 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 de Service[1:ClientNumber] , on notera notamment, dans la catégorie développement 10 ( Expand ), l'attribut d'expansion Expand Multiple-Instance 73, dont la valeur vrai ( true ) indique qu'il doit être développé. Le développement (expansion) est ensuite réalisé par le générateur du modèle SystemC de CoFluent Studio. Il fonctionne selon deux phases : 15 Phase 1 : Analyse des fonctions et relations à développer et construction du modèle fonctionnel textuel optimisé correspondant. Phase 2 : Transformation du modèle textuel résultant en un programme source SystemC en exploitant le paramétrage par attributs de tous les constituants et les algorithmes liés aux modèles comportementaux.
20 La visualisation du résultat se fait plus particulièrement par la simulation. La figure 8 présente un exemple de déroulement temporel obtenu par simulation du modèle développé, obtenu par l'expansion du modèle fonctionnel multi-instances de la figure 5. Cette figure 8 montre que toutes les fonctions modélisées et relations modélisées sont individualisées (il n'y a plus de vecteurs). Ainsi l'analyse détaillée du comportement du 25 modèle est beaucoup plus évidente. 6.3.3 Création du modèle de plate-forme L'éditeur graphique de CoFluent Studio sert aussi à capturer les modèles de plate-forme constitués de processeurs modélisés (logiciels de type CPU ou DSP ou matériels de type ASIC ou FPGA) et mémoires partagées modélisées communiquant par 30 le biais de noeuds de communication modélisés.
2907240 22 La figure 9 présente l'exemple illustratif considéré pour le modèle de plate-forme multi-instances (non développé). Cet exemple de modèle de plate-forme comprend des vecteurs de processeurs ("ProO" et "Prol ", référencés 91 et 92 respectivement), de mémoires ("MemO", référencé 5 93) et de noeuds de communication ("Nodel", référencé 94). Il comprend également un processeur modélisé simple (pas vectorisé) ( Pro2 , référencé 96) et un noeud de communication modélisé simple (pas vectorisé) ( NodeO , référencé 95). 6.3.4 Création du modèle de plate-forme expansé L'éditeur graphique de CoFluent Studio a été enrichi de manière à produire 10 systématiquement lors de la sauvegarde du modèle graphique, un modèle textuel complètement expansé. La figure 10 présente un exemple de modèle de plate-forme développé, obtenu par expansion du modèle de plate-forme multi-instances de la figure 9. Cette figure 10 a été représentée manuellement avec l'outil car seul un modèle textuel est produit, ce qui 15 est suffisant pour son exploitation ultérieure. Ce modèle ne se simule pas. Il est par contre utilisable pour la production de modèles architecturaux, comme décrit dans la suite. 6.3.
5 Mappage du modèle d'application expansé sur le modèle de plate-forme expansé L'outil de configuration architecturale de CoFluent Studio permet d'exploiter les 20 modèles expansés afin de produire un modèle architectural résultant. La figure 11 présente une partie d'un exemple de modèle architectural développé, résultant du mappage du modèle fonctionnel développé obtenu par expansion du modèle fonctionnel multi-instances de la figure 5, sur le modèle de plate-forme développé de la figure 10.
25 Le modèle d'application développé est appelé "ConfiglExpand" et le modèle de plate-forme développé est appelé "FirstPlatform". On observe sur la figure 11 que chaque fonction modélisée est individualisée et peut se mapper sur n'importe quel processeur modélisé aussi individualisé. La partie supérieure gauche représente l'arbre de décomposition du modèle 30 fonctionnel développé correspondant à la figure 5. Chaque fonction individualisée est désignée par son indice (ex ; Appli2l-1, Appli2l-2).
2907240 23 La partie supérieure droite représente l'arbre de décomposition du modèle de la plate-forme développé correspondant à la figure 9 et représenté par la figure 10. La partie inférieure gauche donne une vue partielle du mappage proposé par l'outil pour les relations fonctionnelles devant utiliser un lien physique inter- 5 processeurs. On y voit les relations développées Chan2_1 et Chan2-2. Les propositions de solutions concernent les processeurs individualisés Pro_1 et Pro_2. La partie inférieure droite est la vue duale de celle de gauche. Elle indique les relations fonctionnelles supportées par chacune des relations physiques individualisées. Par exemple Nodel-2 supporte la relation Chan4-2. De même, les mémoires 10 individualisées MemO_1 et MemO_2 implémentent respectivement les variables Var_1 et V ar_2. La production du modèle architectural en SystemC pour sa vérification et son analyse se fait par deux générateurs : - le générateur du modèle architectural comme fusion des deux modèles, 15 d'application et de plate-forme, compte tenu du mappage spécifié ci-dessus. Ce générateur produit un modèle textuel permettant sa caractérisation par l'éditeur d'attributs ; et - le générateur de code source SystemC, qui transforme le modèle texte résultat du générateur précédent en un programme SystemC.
20 Le résultat de ces générateurs produit un modèle exécutable fournissant des traces de simulation. La figure 12 présente un exemple de déroulement temporel obtenu par simulation du modèle architectural développé présenté partiellement sur la figure 11. On peut constater que tous les constituants modélisés sont individualisés, ce qui permet un 25 paramétrage fin et une excellente interprétation du comportement détaillé du modèle. Ainsi, comme déjà indiqué, la technique de description des modèles sur la base de vecteurs de composants et de relations simplifie fortement le travail de saisie des modèles et structure mieux leur régularité et leur généricité. La technique de développement (expansion) des modèles facilite grandement l'analyse détaillée des 30 comportements des modèles et permet surtout une meilleure exploration des architectures de solutions.

Claims (19)

REVENDICATIONS
1. Procédé de construction d'au moins un modèle (31, 32) d'un système complexe comprenant une pluralité de constituants, chaque modèle du système comprenant un ensemble hiérarchisé de constituants modélisés, ledit procédé de construction comprenant, pour chaque modèle, une étape d'obtention d'un modèle hiérarchique mufti-instances comprenant au moins un vecteur d'instances correspondant à une pluralité d'instances d'un même constituant modélisé, chaque vecteur d'instances pouvant se situer à tout niveau d'un arbre de décomposition hiérarchique dudit modèle hiérarchique multi-instances, caractérisé en ce que ledit procédé de construction comprend en outre, pour chaque modèle, une étape d'expansion (35, 36) dudit modèle hiérarchique multi-instances en un modèle développé (33, 34), par expansion d'au moins un vecteur d'instances compris dans ledit modèle hiérarchique multi-instances.
2. Procédé selon la revendication 1, caractérisé en ce que l'étape d'expansion dudit au moins un modèle hiérarchique multi-instances comprend elle-même Ies étapes suivantes, effectuées pour chaque vecteur d'instances à développer correspondant à N instances d'un constituant modélisé : développement dudit vecteur d'instances en un nombre de constituants modélisés égal audit nombre N d'instances ; et - production de la ou les entrée(s) et/ou la ou les sortie(s) de chacun des N constituants modélisés, selon un jeu d'au moins une règle de production.
3. Procédé selon la revendication 2, caractérisé en ce que I'étape d'expansion dudit au moins un modèle hiérarchique multi-instances comprend les étapes suivantes : descente dudit arbre de décomposition hiérarchique, de façon récursive depuis une racine jusqu'à des feuilles, de sorte que pour chaque niveau dudit arbre de décomposition hiérarchique, chaque vecteur d'instances à développer est développé en un nombre prédéterminé de constituants modélisés ; remontée dudit arbre de décomposition hiérarchique, de façon récursive depuis les feuilles jusqu'à la racine, de sorte que pour chaque niveau dudit arbre de 30 décomposition hiérarchique, la ou les entrée(s) et/ou la ou Ies sortie(s) des 2907240 25 constituants modélisés résultant du développement d'un vecteur d'instances sont produites selon ledit jeu d'au moins une règle de production.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite étape d'expansion est systématique et consiste en une expansion de tous les 5 vecteur d'instances.
5. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite étape d'expansion est sélective et consiste en une expansion uniquement des vecteurs d'instances associés à un attribut d'expansion prenant une valeur indiquant qu'une expansion doit être effectuée. 10
6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit système complexe est un système électronique complexe.
7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend une étape de construction d'un modèle fonctionnel du système complexe, comprenant elle-même une étape d'obtention d'un modèle fonctionnel hiérarchique 15 multi-instances et une étape d'expansion dudit modèle fonctionnel hiérarchique multiinstances en un modèle fonctionnel développé.
8. Procédé selon la revendication 7, caractérisé en ce que ledit modèle fonctionnel hiérarchique multi-instances comprend au moins un vecteur d'instances appartenant au groupe comprenant : 20 - des vecteurs de fonctions correspondant chacun à une pluralité d'instances d'une fonction modélisée ; et des vecteurs de relations correspondant chacun à une pluralité d'instances d'une relation modélisée.
9. Procédé selon la revendication 2 et la revendication 8, caractérisé en ce que ledit 25 jeu d'au moins une règle de production comprend les règles suivantes appliquées aux vecteurs de fonctions élémentaires correspondant chacun à une pluralité d'instances d'une fonction élémentaire modélisée : si, dans le modèle hiérarchique multi-instance, une sortie d'un vecteur de fonctions élémentaires est reliée à un vecteur de relations : 2907240 26 * si ladite sortie du vecteur de fonctions élémentaires est associée à un sélecteur de sortie compris dans un modèle comportemental de ladite fonction élémentaire modélisée : - si le sélecteur de sortie est défini par un paramètre indiquant une affectation selon une relation 1 vers 1 , alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède une sortie reliée, selon ladite relation 1 vers 1 , à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations ; - si le sélecteur de sortie est défini par un paramètre indiquant une affectation selon une relation 1 vers X , avec X>1, alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède X sorties, chacune reliée à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations ; * si ladite sortie du vecteur de fonctions élémentaires n'est pas associée à un sélecteur de sortie compris dans un modèle comportemental de ladite fonction élémentaire modélisée, alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède une sortie reliée, selon une relation 1 vers 1 , à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations.
10. Procédé selon la revendication 2 et l'une quelconque des revendications 8 et 9, caractérisé en ce que ledit jeu d'au moins une règle de production comprend les règles suivantes appliquées aux vecteurs de fonctions élémentaires correspondant chacun à une 25 pluralité d'instances d'une fonction élémentaire modélisée : - si, dans le modèle hiérarchique multi-instance, une entrée d'un vecteur de fonctions élémentaires est reliée à un vecteur de relations : * si ladite entrée du vecteur de fonctions élémentaires est associée à un sélecteur d'entrée compris dans un modèle comportemental de ladite 30 fonction élémentaire modélisée : 5 10 15 20 2907240 27 - si le sélecteur d'entrée est défini par un paramètre indiquant une affectation selon une relation 1 vers 1 , alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède une entrée reliée, selon ladite relation 1 vers 1 , à une instance de même 5 indice parmi les instances obtenues après développement dudit vecteur de relations ; - si le sélecteur d'entrée est défini par un paramètre indiquant une affectation selon une relation 1 vers X , avec X>1, alors chaque instance obtenue après développement du vecteur de fonctions 10 élémentaires possède X entrées, chacune reliée à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations ; * si ladite entrée du vecteur de fonctions élémentaires n'est pas associée à un sélecteur d'entrée compris dans un modèle comportemental de ladite 15 fonction élémentaire modélisée, alors chaque instance obtenue après développement du vecteur de fonctions élémentaires possède X entrées, chacune reliée à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations.
11. Procédé selon l'une quelconque des revendications 9 et 10, caractérisé en ce que 20 l'étape d'expansion dudit modèle fonctionnel hiérarchique multi-instances comprend l'étape suivante, effectuée pour au moins un vecteur d'instances qui est un vecteur de fonctions élémentaires correspondant à une pluralité d'instances d'une fonction élémentaire modélisée : optimisation du modèle comportemental de ladite fonction élémentaire modélisée, par suppression dans ledit modèle comportemental de : 25 - tout sélecteur de sortie associé à ladite fonction élémentaire modélisée et indiquant une affectation selon une relation 1 vers 1 ; et/ou - tout sélecteur d'entrée associé à ladite fonction élémentaire modélisée et indiquant une affectation selon une relation 1 vers 1 .
12. Procédé selon la revendication 2 et l'une quelconque des revendications 9 à 11, caractérisé en ce que ledit jeu d'au moins une règle de production comprend la règle 2907240 28 suivante appliquée aux vecteurs de fonctions non élémentaires correspondant chacun à une pluralité d'instances d'une fonction non élémentaire modélisée : - si, dans le modèle hiérarchique multi-instance, une entrée, respectivement sortie, d'un vecteur de fonctions non élémentaires est reliée à un vecteur de relations : * s'il existe une relation 1 vers 1 pour toutes les entrées, respectivement sortries, reliées audit vecteur de relations et appartenant à des fonctions qui sont internes à ladite fonction non élémentaire modélisée, chaque instance obtenue après développement du vecteur de fonctions non élémentaires possède une entrée, respectivement sortie, reliée selon une relation 1 vers 1 à une instance de même indice parmi les instances obtenues après développement dudit vecteur de relations ; * sinon, chaque instance obtenue après développement du vecteur de fonctions non élémentaires possède X entrées, respectivement sorties, chacune reliée à une entrée, respectivement sortie, de même indice pour toutes les instances obtenues après développement dudit vecteur de relations.
13. Procédé selon la revendication 2 et l'une quelconque des revendications 8 à 12, caractérisé en ce que ledit jeu d'au moins une règle de production comprend les règles suivantes : 20 - si, dans le modèle hiérarchique multi-instance, une sortie d'un vecteur de fonctions, élémentaires ou non élémentaires, est reliée à une relation modélisée non vectorisée, alors chaque instance obtenue après développement du vecteur de fonctions possède une sortie reliée à ladite relation modélisée ; - si, dans le modèle hiérarchique multi-instance, une entrée d'un vecteur de 25 fonctions, élémentaires ou non élémentaires, est reliée à une relation modélisée non vectorisée, alors chaque instance obtenue après développement du vecteur de fonctions possède une entrée reliée à ladite relation modélisée.
14. Procédé selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'il comprend une étape de construction d'un modèle de plate-forme hiérarchique du 30 système complexe, comprenant elle-même une étape d'obtention d'un modèle de plate- 5 10 15 2907240 29 forme hiérarchique multi-instances et une étape d'expansion dudit modèle de plate-forme hiérarchique multi-instances en un modèle de plate-forme développé.
15. Procédé selon la revendication 14, caractérisé en ce que ledit modèle de plate-forme hiérarchique multi-instances comprend au moins un vecteur d'instances 5 appartenant au groupe comprenant : - des vecteurs de processeurs correspondant chacun à une pluralité d'instances d'un processeur modélisé ; - des vecteurs de mémoires correspondant chacun à une pluralité d'instances d'une mémoire modélisée ; et 10 - des vecteurs de noeuds de communication correspondant chacun à une pluralité d'instances d'un noeud de communication modélisé.
16. Procédé selon la revendication 2 et la revendication 15, caractérisé en ce que à chaque vecteur de noeuds de communication est associé un paramètre de configuration d'expansion, 15 et en ce que ledit jeu d'au moins une règle de production comprend les règles suivantes, pour chaque vecteur de noeuds de communication relié à un vecteur de processeurs ou mémoires : - si le paramètre de configuration d'expansion indique liens vers tous , alors chaque instance du vecteur de noeuds de communication est reliée à chacune des instances du vecteur de processeurs ou mémoires ; - si le paramètre de configuration d'expansion indique linéaire , alors les instances du vecteur de processeurs ou mémoires sont reliées entre elles de façon linéaire, via des instances du vecteur de noeuds de communication ; - si le paramètre de configuration d'expansion indique anneau , alors les instances du vecteur de processeurs ou mémoires sont reliées entre elles en anneau, via des instances du vecteur de noeuds de communication.
17. Procédé selon l'une quelconque des revendications 7 à 13 et l'une quelconque des revendications 14 à 16, caractérisé en ce qu'il comprend une étape d'allocation distribuée dudit modèle fonctionnel développé sur ledit modèle de plate-forme 30 développé, permettant d'obtenir un modèle architectural développé dudit système complexe. 20 25 2907240 30
18. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution des étapes du procédé selon au moins une des revendications 1 à 17, 5 lorsque ledit programme est exécuté sur un ordinateur.
19. 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 oeuvre le procédé d'au moins une des revendications 1 à 17.
FR0608913A 2006-10-11 2006-10-11 Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants Withdrawn FR2907240A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0608913A FR2907240A1 (fr) 2006-10-11 2006-10-11 Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants
US11/870,920 US7991603B2 (en) 2006-10-11 2007-10-11 Method for simulating a complex system with expansion of instance vectors, corresponding computer program product and storage means
US13/161,197 US20110246168A1 (en) 2006-10-11 2011-06-15 Method for simulating a complex system with expansion of instance vectors, corresponding computer program product and storage means

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0608913A FR2907240A1 (fr) 2006-10-11 2006-10-11 Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants

Publications (1)

Publication Number Publication Date
FR2907240A1 true FR2907240A1 (fr) 2008-04-18

Family

ID=37951476

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0608913A Withdrawn FR2907240A1 (fr) 2006-10-11 2006-10-11 Procede de simulation d'un systeme complexe avec expansion de vecteurs d'instances, produit programme d'ordinateur et moyen de stokage correspondants

Country Status (2)

Country Link
US (2) US7991603B2 (fr)
FR (1) FR2907240A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
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
US8204732B1 (en) * 2008-10-03 2012-06-19 The Mathworks, Inc. Modeling communication interfaces for multiprocessor systems
US9064075B1 (en) 2008-12-02 2015-06-23 The Mathworks, Inc. Automatic assignment of signals for a functional model
US20140164032A1 (en) * 2012-12-06 2014-06-12 International Business Machines Corporation Cladistics data analyzer for business data

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1284454A2 (fr) * 2001-08-17 2003-02-19 Sun Microsystems, Inc. Méthode et appareil pour compilateur de système de simulation
WO2006084845A2 (fr) * 2005-02-14 2006-08-17 Cofluent Design Procede de simulation d'un processeur utilisant un modele comprenant un ensemble de objets

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6816825B1 (en) * 1999-06-18 2004-11-09 Nec Corporation Simulation vector generation from HDL descriptions for observability-enhanced statement coverage
US7324931B1 (en) * 2003-11-17 2008-01-29 The Mathworks, Inc. Conversion of model components into references
US20050257178A1 (en) * 2004-05-14 2005-11-17 Daems Walter Pol M Method and apparatus for designing electronic circuits
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1284454A2 (fr) * 2001-08-17 2003-02-19 Sun Microsystems, Inc. Méthode et appareil pour compilateur de système de simulation
WO2006084845A2 (fr) * 2005-02-14 2006-08-17 Cofluent Design Procede de simulation d'un processeur utilisant un modele comprenant un ensemble de objets

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CALVEZ J P: "A system-level performance model and method", CIEM CURRENT ISSUES IN ELECTRONIC MODELING: META-MODELING: PERFORMANCE, SOFTWARE AND INFORMATION MODELING, vol. 6, 1996, KLUWER ACADEMIC PUBLISHERS, pages 57 - 102, XP009082942 *

Also Published As

Publication number Publication date
US20110246168A1 (en) 2011-10-06
US20080091401A1 (en) 2008-04-17
US7991603B2 (en) 2011-08-02

Similar Documents

Publication Publication Date Title
WO2006084845A2 (fr) Procede de simulation d&#39;un processeur utilisant un modele comprenant un ensemble de objets
US8855992B1 (en) Graphical modeling blocks that execute in more than one domain
FR2820919A1 (fr) Procede et dispositif pour suivre une connectivite de reseau au moyen d&#39;une hierarchie de conception
FR2922665A1 (fr) Procede d&#39;aide a la conception d&#39;une architecture systeme
WO2004038617A2 (fr) Procede et dispositif pour synthetiser une architecture electrique
JP5567682B2 (ja) グラフィカル状態遷移図モデルにおける再利用候補の正規化バージョン
EP3273368B1 (fr) Systèmes et procédés de groupement de codes d&#39;événements implicites et explicites de modèles exécutables
EP1387305A1 (fr) Procédé et systeme d&#39;établissement automatique d&#39;un modèle global de simulation d&#39;une architecture
FR2964224A1 (fr) Procede et dispositif de deploiement et d&#39;aide au deploiement de composants formant un systeme temps reel embarque
CN106406999A (zh) 计算系统和计算系统的执行控制方法
FR2907240A1 (fr) Procede de simulation d&#39;un systeme complexe avec expansion de vecteurs d&#39;instances, produit programme d&#39;ordinateur et moyen de stokage correspondants
US12073197B2 (en) Systems and methods for generating service access points for RTE services in code or other RTE service information for use with the code
CN113255258A (zh) 逻辑综合方法、装置、电子设备及存储介质
EP3087401B1 (fr) Système de simulation et de test
EP3827368A1 (fr) Outil et procédé de conception et de validation d&#39;un système flots de données par un modèle formel
EP2956874B1 (fr) Dispositif et procédé pour accélérer la phase de mise à jour d&#39;un noyau de simulation
FR2902211A1 (fr) Procede de simulation d&#39;un systeme complexe avec construction d&#39;au moins un modele comprenant au moins un routeur modelise, produit programme d&#39;ordinateur et moyen de stockage correspondants
Kamali et al. Formal modeling of multicast communication in 3D NoCs
Theelen et al. Performance modelling of a network processor using POOSL
CN110780978A (zh) 一种数据处理方法、系统、设备和介质
FR3096531A1 (fr) Procédé d’allocation de ressources d’une infrastructure de réseau
Pilato et al. On the automatic integration of hardware accelerators into FPGA-based embedded systems
FR3006470A1 (fr) Dispositif et procede informatises d&#39;analyse de panne dans un systeme
Arronategui et al. Towards an architecture proposal for federation of distributed DES simulators
KR101396885B1 (ko) 구조 모델링을 위한 ses 기반 블록 다이어그램 편집기 및 그 편집 방법

Legal Events

Date Code Title Description
TP Transmission of property

Owner name: INTEL CORPORATION, US

Effective date: 20120206

ST Notification of lapse

Effective date: 20130628