FR 2914525 A1 20081003 FR 0702376 A 20070330 Procédé de simulation transactionnelle d'un modèle générique de noeud de communication, 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. 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). 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 transactionnelle d'un modèle générique de noeud de communication compris dans un modèle de système complexe. Le modèle générique de noeud gère des transactions entre des constituants du modèle de système complexe. La technique de l'invention a été développée pour la conception et l'exploration des architectures des systèmes électroniques embarqués 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. Ces ressources sont généralement interconnectées par des bus et de plus en plus par des réseaux d'interconnexion (dits interconnects ). Cependant, du fait que la technique de l'invention repose sur des concepts généraux de constituants (tels que des tâches (fonctions) et des processeurs (et donc des ressources d'exécution)), 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 besoins client, des standards de traitement de 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 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 Gate Arrays ) et mémoires, constituant ainsi la plate-forme matérielle du système. S'ajoute à cette plate-forme matérielle un ensemble de logiciels 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 vérifier 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 de modèles, méthodes et outils d'aide à la conception (CAO û Conception Assistée par Ordinateur). La technologie de l'invention répond à un tel besoin. La prévision des propriétés de tels systèmes en termes de fonctionnalités et de performances au sens général, résulte en général 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 modélisation efficaces 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 modélisation en vue de simulations 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 On dresse ci-après un bref panorama de l'état de l'art concernant les techniques de simulation d'un modèle générique de noeud de communication compris dans un modèle de système complexe. On rappelle qu'un noeud de communication est un constituant essentiel des plateformes matérielles actuelles. Le bus est le type de noeud le plus connu et le plus utilisé pour interconnecter des processeurs, des mémoires et des composants périphériques. Les ponts ( bridges ) et routeurs sont des composants plus complexes que nous incluons dans la catégorie des noeuds de communication. Dans les systèmes intégrés sur silicium (SoC pour System-on-Chip ), on trouve de plus en plus l'emploi de réseaux d'interconnexion (NoC pour Network-on-Chip ) pour remédier aux limitations des bus. Pour illustrer l'intérêt des techniques de simulation d'un modèle générique de noeud de communication, considérons, en relation avec la figure 1, une architecture simple de système électronique composée de deux processeurs, Proc 1 et Proc2, et une mémoire commune 1, interconnectés par un bus 2. Un ensemble de tâches est exécuté par chaque processeur (tâches T1 et T2 pour le processeur Procl, tâches T3 et T4 pour le processeur Proc2). Des fonctions matérielles plus spécifiques telles qu'un module d'accès direct à la mémoire (DMA pour Direct Memory Access ) peuvent aussi exister (module DMA1 pour le processeur Proc2). Les tâches et/ou fonctions matérielles échangent des données entre elles ou avec la mémoire par l'intermédiaire du bus. Ainsi le bus est une ressource critique partagée qui doit se gérer selon une politique d'accès. Les propriétés de performance du système complet sont alors très dépendantes du comportement du bus. Ce système électronique peut se représenter par un modèle abstrait donné en figure 2. Le bus est représenté par un noeud de communication 20 ( node en anglais). Les figures 3a, 3b et 3c expliquent la différence essentielle entre trois niveaux d'abstraction possibles pour la simulation des échanges assurés par le bus. Considérons deux échanges apparaissant simultanément : Trl entre T2 (Proc1) et la mémoire, Tr2 entre DMA1 (Proc2) et la mémoire. Les deux échanges vont exploiter' le bus commun selon la politique d'accès définie avec la caractéristique essentielle pour ce bus qu'un seul échange peut se faire à chaque instant. Certaines politiques telles que l'entrelacement ( interleaving en anglais) permettent l'alternance entre les deux échanges donnant une impression de simultanéité. La figure 3a illustre le niveau transactionnel (ou TA pour Transaction Accurate ), qui est le niveau le plus abstrait. Chaque échange est modélisé par une transaction atomique. Ainsi la transaction Trl étant en cours, la transaction Tr2 doit attendre la fin de la transaction Trl pour disposer du bus. La figure 3b illustre le niveau transfert de bus (ou BA pour Bus Accurate ) qui est un niveau plus détaillé. Chaque échange est décomposé en trame ou paquet de longueur fixe (sauf le dernier) ; on parle aussi de burst . Un entrelacement ( interleaving ) entre les deux échanges est alors possible par exemple par allocation alternative du bus pour un paquet de chaque transaction. Sur l'exemple, et ceci est général, il est important de noter que les instants de fin des transactions Trl et Tr2 diffèrent par rapport à ceux du niveau transactionnel. Ceci implique que toute la simulation qui suit diffère. Ainsi les deux simulations aux niveaux TA et BA ne sont pas équivalentes. La figure 3c illustre le niveau cycle d'horloge (ou C.A pour Cycle Accurate ) qui est le niveau le plus détaillé. Chaque échange est décomposé en une suite de cycles d'horloge. Chaque paquet est transmis comme une suite de mots élémentaires. Chaque mot requiert un ou plusieurs cycles d'horloge. Le premier mot peut requérir plusieurs cycles d'accès supplémentaires (temps cle latence). Un paramétrage temporel correct d'un modèle du niveau BA peut donner des résultats similaires à son modèle CA correspondant. La majorité des solutions actuelles pour la simulation des systèmes électroniques incluant du matériel et du logiciel entrent dans la catégorie des plateformes virtuelles (première technique connue). Une plateforme virtuelle est un modèle de simulation dans lequel les processeurs sont représentés par des modèles comportementaux basés sur les instructions de ces processeurs (ou ISS pour Instruction-Set Simulator ), et les bus, les réseaux d'interconnexion et les mémoires sont modélisés par des modèles précis au cycle d'échange ou au cycle d'horloge. Ces modèles permettent d'avoir des résultats de simulation dont la précision est de l'ordre de 95% et 99% par rapport à la solution réelle correspondante. Les performances de simulation sont alors situées entre 100 K instructions/s et 5 M instructions/s selon la technique. La performance est meilleure pour des modèles BA mais elles nécessitent encore l'emploi de modèles ISS. La simulation transactionnelle (seconde technique connue) se trouve progressivement utilisée, en particulier depuis la standardisation de TLM ( Transaction-Level Modeling en anglais, ou modélisation au niveau transactionnel en français) par le groupe OSCI (Open SystemC Initiative). La simulation transactionnelle connue à ce jour (appelée par la suite simulation transactionnelle classique ) considère que chaque transaction est atomique et donc ne considère pas le partage d'une ressource telle qu'un bus lors de transactions simultanées. L'inventeur de la présente demande n'a pas connaissance de solutions existantes de simulation transactionnelle assurant le partage d'un bus ou d'un réseau d'interconnexion lors de transactions simultanées. La technique de la plate-forme virtuelle (première technique connue) a deux inconvénients majeurs : - son coût de mise en œuvre. En effet elle nécessite de disposer (et donc d'acheter ou développer) des modèles de processeurs, bus et mémoires. Elle requiert aussi d'être assez avancé dans le développement du produit y compris la partie logicielle puisque le code logiciel source doit être compilé pour chaque processeur cible afin de permettre son exécution par son modèle ISS. Les résultats obtenus même s'ils sont très précis arrivent très tard dans le processus de développement, surtout bien après toutes les prises de décisions. Les résultats sont dits de nature confirmative par opposition à des résultats prospectifs recherchés par les architectes système ; la durée de simulation. Avec l'accroissement de la complexité, les temps de simulation deviennent prohibitifs, en particulier durant les phases initiales d'exploration des architectures potentielles, lorsqu'il s'agit de faire un maximum d'itérations pour la bonne prise de décisions. Des facteurs d'accélération de 100 à 10000 sont demandés, ce qui ne peut s'atteindre que par la simulation transactionnelle. La technique de simulation transactionnelle classique (seconde technique connue) permet de pallier les deux inconvénients précités de la technique de la plate-forme virtuelle, grâce aux caractéristiques suivantes : utilisation de modèles génériques de composants, modèles des tâches logicielles et des fonctions matérielles décrites en SystemC, facteur d'accélération de la simulation de 1000 à 10000 par rapport à des modèles du niveau cycle d'horloge. Toutefois, la technique de simulation transactionnelle classique ne fournit pas des résultats précis car les échanges atomiques introduisent des distorsions temporelles importantes. L'influence de ces distorsions est plus ou moins importante selon les domaines d'applications. Les systèmes du domaine des télécommunications et du multimédia sont très exigeants sur l'emploi des ressources du type bus, réseau et mémoire, et avec de fortes contraintes de temps-réel. Ainsi les performances évaluées peuvent se révéler très erronées. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de 20 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 rnodèle générique de noeud de communication compris dans un modèle de système complexe, cette technique permettant de minimiser le nombre d'événements de simulation nécessaires 25 par rapport à la simulation transactionnelle classique discutée ci-dessus, tout en produisant des résultats précis relativement au système réel que le modèle représente. L'invention a également pour objectif, dans au moins un mode de réalisation, de fournir une telle technique s'appliquant à toute configuration d'architecture matérielle, toute configuration de tâches ou fonctions sur des processeurs et quels que soient les 30 échanges entre les constituants par l'intermédiaire de tout type de noeud de communication. Un objectif complémentaire de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique permettant de pallier les deux inconvénients précités de la technique de la plate-forme virtuelle. Un autre objectif de l'invention, dans au moins un mode de réalisation, est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de simulation transactionnelle d'un modèle générique de noeud de communication compris dans un modèle de système complexe, ledit modèle générique de noeud gérant des transactions entre des constituants dudit modèle de système complexe, ledit procédé comprenant les étapes suivantes, effectuées à chaque pas de simulation correspondant à un événement appartenant au groupe d'évènements comprenant des débuts de transaction et des fins de transactions : calcul d'une quantité restante de données à transmettre pour chaque transaction non achevée présente dans une liste des transactions en cours ; - si ledit pas de simulation correspond au début d'une nouvelle transaction, calcul d'une quantité de données à transmettre pour la nouvelle transaction et ajout de la nouvelle transaction dans la liste des transactions en cours ; - si ledit pas de simulation correspond à la fin d'une transaction, retrait de la transaction de la liste des transactions en cours ; - allocation de débits aux transactions en cours, selon une politique de partage du noeud prédéterminée ; - calcul d'une durée TpsRk jusqu'au plus proche instant de fin d'une des transactions en cours : TpsRk = MIN(TpsRi), avec TpsRi = Qri/Di, TpsRi étant la durée jusqu'à l'instant de fin d'une transaction i en cours, Qri. la quantité de données restante pour la transaction i et Di le débit alloué à la transaction i ; - assignation d'une attente de ladite durée TpsRk avant la génération du prochain événement de fin de transaction. Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive consistant à utiliser une technique de simulation transactionnelle optimisée par rapport à la technique de simulation transactionnelle classique. Elle est basée sur une simulation évènementielle de transactions, en déterminant uniquement des instants futurs utiles (fins de transaction) du modèle du noeud sur la base de calculs de quantités restantes de données à transférer pour chaque transaction non achevée. En d'autres termes, la technique de l'invention permet d'obtenir, avec une simulation du niveau transactionnel (TA), des résultats identiques aux niveaux inférieurs plus détaillés (BA ou CA) mais beaucoup plus rapidement grâce à la réduction des évènements de simulation. De plus, comme la technique de simulation transactionnelle classique, la technique de simulation transactionnelle de l'invention permet de pallier les deux inconvénients précités de la technique de la plate-forme virtuelle. Avec l'accroissement de la complexité des modèles de systèmes, la technique de l'invention est particulièrement adaptée pour la vérification par simulation des systèmes complexes et l'exploration des architectures possibles. De façon avantageuse, l'étape d'allocation de débits aux transactions en cours est une étape d'allocation directe de débits. En d'autres termes, on calcule directement des débits, en fonction de la politique de partage du noeud. Selon une variante avantageuse, l'étape d'allocation de débits aux transactions en cours est une étape d'allocation indirecte de débits comprenant les étapes suivantes : -allocation aux transactions en cours, selon ladite politique de partage du noeud prédéterminée, de pourcentages d'un débit maximal DébitlVlax du modèle générique de noeud ; - calcul des débits alloués aux transactions en cours en appliquant la formule suivante : Di = DébitMax * Ri, avec Ri le pourcentage du débit maximal alloué à la transaction i. En d'autres termes, on calcule d'abord des pourcentages du débit maximal, en fonction de la politique de partage du noeud, puis on calcule des débits. Dans un mode de réalisation particulier de l'invention, la politique de partage du noeud prédéterminée appartient au groupe comprenant : - une politique d'allocation par entrelacement égalitaire, telle que toutes les valeurs Di sont égales à DébitMax/N, avec DébitMax le débit maximal du modèle générique de noeud et N le nombre de transactions en cours ; - une politique d'allocation par priorité, telle que : Di = DébitMax pour la transaction i la plus prioritaire, et : Di = 0 pour les autres transactions ; - une politique d'allocation de type premier entré premier sorti (FIFO), telle que : Di = DébitMax pour la transaction i la plus ancienne, et : Di = 0 pour les autres transactions ; - une politique d'allocation de type qualité de service (QoS), telle que chaque l0 transaction i est associée à une priorité Pi et un débit demandé I)ébitDemandé_i, et, par ordre de priorité décroissante, chaque transaction i se voit allouer son débit demandé ou le débit restant s'il est inférieur à son débit demandé. Cette liste de politiques de partage du noeud n'est pas exhaustive. Dans un mode de réalisation avantageux de l'invention, ledit groupe 15 d'évènements comprend en outre des modifications d'un débit maximal DébitMax du modèle générique de noeud. Ainsi, on considère que le débit maximal est modifiable, ce qui permet de représenter une charge externe variable. Avantageusement, ledit système complexe est un système électronique 20 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 programme d'ordinateur comprenant des instructions de code de programme pour 25 l'exécution des étapes du procédé de simulation transactionnelle précité (dans l'un quelconque de ses modes de réalisation), 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 30 un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de simulation transactionnelle précité (dans l'un quelconque de ses modes de réalisation). 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, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : la figure 1 présente un exemple d'architecture physique d'un système électronique complexe comprenant un noeud de communication (un bus dans cet exemple) ; la figure 2 présente un modèle abstrait du système électronique; complexe de la figure 1, comprenant un modèle générique du noeud de communication dont la présente invention permet une simulation ; les figures 3a, 3b et 3c illustrent trois niveaux d'abstraction connus pour la simulation des échanges assurés par un noeud de communication : le niveau transactionnel (fig.3a), le niveau transfert de bus (fig.3b) et le niveau cycle d'horloge (fig.3c) ; les figures 4a et 4b présentent une analogie entre l'écoulement d'eau de bacs par des vannes (fig.4a) et le transfert de données par un noeud de communication (fig.4b), permettant d'expliquer le principe général de la présente invention ; la figure 5 présente un organigramme d'un mode de réalisation particulier du procédé selon l'invention ; la figure 6 présente un exemple d'allocation d'un modèle fonctionnel sur un modèle de plate-forme matérielle, permettant l'obtention d'un modèle architectural (ce dernier étant présenté d'une part sous une forme arborescente et d'autre part sous une forme graphique) ; la figure 7 illustre une première politique de partage de noeud (par entrelacement égalitaire) selon l'invention, en présentant en partie haute un exemple de diagramme de séquence et en partie basse une représentation graphique du partage du noeud ; la figure 8 illustre une deuxième politique de partage de noeud (par priorité) selon l'invention, en présentant en partie haute un exemple de diagramme de séquence et en partie basse une représentation graphique du partage du noeud ; et la figure 9 illustre une troisième politique de partage de noeud (de type qualité de service) selon l'invention, en présentant en partie haute un exemple de diagramme de séquence et en partie basse une représentation graphique du partage du noeud. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments identiques sont désignés par une même référence alphanumérique. 6.1 Principe général de l'invention L'obtention de résultats précis par une simulation transactionnelle requiert de calculer avec précision les instants de début et de fin d'échange pour chaque transaction dans le modèle. Il s'agit donc, à chaque événement de la simulation (simulation événementielle utilisée), de déterminer avec précision les seuls instants futurs utiles pour le modèle. La technique originale de l'invention repose sur une méthode simple de calcul des instants futurs utiles du noeud de communication. Cette méthode découle d'une analogie faite entre le transfert de données par un noeud (cf figure 4b) et l'écoulement d'eau de bacs par des vannes (cf figure 4a). Le principe de l'invention repose sur la relation générale : Quantité = Débit x Temps. Connaissant la quantité et le débit, il est possible de prévoir la durée du transfert (Temps). L'analogie avec des bacs, comme illustré sur la figure 4a, explique l'idée. Supposons qu'à l'instant tl le bac 1 contient la quantité Ql de liquide et qu'à l'instant t2 le bac 2 contient Q2. Les deux vannes en sortie des bacs sont réglables en débit par R1 et R2. Le débit maximum DébitMax en sortie est défini par une vanne de sortie modifiant la section du tuyau. Ce qui nous intéresse dans cette analogie ce sont les temps T1 et T2 d'écoulement des quantités Q1 et Q2. Ces temps Tl et T2 sont directement liés aux débits en sortie de chaque bac et donc : - soit des débits absolus Dl et D2 ; - soit des valeurs R1 et R2 associées aux vannes représentant le pourcentage du débit maximum. Dans le cas du pourcentage, le débit réel pour chaque bac vaut Di = Ri x DébitMax, avec 0 s Ris 1. Selon l'analogie, la taille d'une transaction exprimée en octel:s (par exemple) correspond à la quantité de liquide. Le débit du noeud ( Throughput en anglais) - on parle aussi de bande passante du noeud -exprimé en octets/s correspond au débit du tuyau. Le partage du noeud lors de transactions simultanées, et donc le pourcentage ou le débit alloué pour chacune d'elles, correspond au réglage Ri ou Di des vannes. La somme des Ri est toujours inférieure ou égale à 1. Lorsque cette somme est inférieure à 1 cela veut dire que toute la capacité de transmission du noeud n'est pas utilisée. Ainsi la politique de partage du noeud peut se définir sur la base des valeurs Ri ou des débits réels Di. Nous considérons aussi que le débit maximum DébitMax est modifiable à tout instant. Ceci permet de représenter une charge externe variable (par exemple celle d'un processeur modifiant dynamiquement son activité avec le bus sur lequel il est connecté). La technique de simulation transactionnelle repose sur la simulation dite événementielle. Pour résumer ce principe, à chaque pas de simulation (ce qui correspond à un événement), il s'agit de mettre à jour la liste des événements du futur selon un ordre croissant, puis le simulateur passe à l'événement futur le plus proche dans le temps qui est donc le premier dans la liste. Exploitant cette technique pour modéliser les transactions sur un noeud, en se référant à la figure 4b, il faut considérer trois types d'événements pour le noeud : le début d'une nouvelle transaction, la fin d'une transaction et la modification du débit maximal (DébitMax). On présente maintenant, en relation avec l'organigramme de la figure 5, un mode de réalisation particulier du procédé selon l'invention. L'algorithme décrit ci-après est exécuté selon cinq phases (P1 à P5) lors de l'apparition de chaque nouvel événement d'un des trois types d'événements précités (c'est-à-dire à chaque pas de simulation). Première phase P1 : dans une étape El, on calcule la quantité restante de données à transmettre pour chacune des transactions non achevées présentes dans une liste des transactions en cours. Il s'agit simplement de soustraire la quantité de données écoulée depuis l'exécution précédente de l'algorithme à la quantité restante. En reprenant l'exemple de la figure 4b : - en t2 (événement : début de la transaction Tr2), il reste la quantité Q12 pour la transaction Trl, avec : Q12 = Q1 û Q11, Q11 = t12 * DébitMax, t12 = t2 ûtl , - en t3 (événement : fin de la transaction Tri), il reste la quantité Q22 pour la transaction Tr2, avec : Q22 = Q2 û Q12, Q12 = t23 * DébitMax, t23 = t3 û t2. Deuxième phase P2 : dans une étape E2, on détecte si le nouvel événement est le début d'une nouvelle transaction. Dans l'affirmative, on effectue une étape E3 de calcul de la quantité de données à transmettre pour la nouvelle transaction et d'ajout de la nouvelle transaction dans la liste des transactions en cours. En reprenant l'exemple de la figure 4b, en tl (événement : début de latransaction Trl), il y a une quantité Q1 à transmettre pour la transaction Tri. Et en t2 (événement : début de la transaction Tr2), il y a une quantité Q2 pour la transaction Tr2. Puis, après l'étape E3 (ou directement après l'étape E2 en cas de détection négative à l'étape E2), on passe à une étape E4 au cours de laquelle on détecte si le nouvel événement est la fin d'une transaction. Dans l'affirmative, on effectue une étape E5 de retrait de la transaction de la liste. En reprenant l'exemple de la figure 4b, en t3 (événement : fin de la transaction Tri), on retire la transaction Trl de la liste, et en T4 (événement : fin de la transaction Tr2), on retire la transaction Tr2 de la liste. Troisième phase P3 : dans une étape E6, on calcule le débit absolu Di à allouer à chaque transaction i de la liste. Dans une variante, on calcule d'abord le pourcentage Ri du débit maximal DébitMax à allouer à chaque transaction i de la liste, puis on calcule le débit absolu Di à allouer à chaque transaction i de la liste, sachant que : Di = Ri * DébitMax. Ce calcul direct ou indirect des débits Di peut se faire selon différentes politiques de partage du nœud (voir ci-après). Quatrième phase P4 : dans une étape E7, on calcule une durée TpsRk jusqu'au plus proche instant de fin d'une des transactions en cours : TpsRk = MIN(TpsRi), avec TpsRi = Qri/Di, TpsRi étant le temps restant pour la transaction i (c'est-à-dire la durée jusqu'à l'instant de fin de cette transaction i), Qri la quantité de données restante pour la transaction i et Di le débit alloué à la transaction i. En reprenant l'exemple de la figure 4b, en t2 (événement : début de la transaction Tr2), on calcule : -TpsRl =Q12/D1 =Q12/(DébitMax * R1) ; - TpsR2 = Q2 / D2 = Q2 / (DébitMax * R2). Dans l'exemple illustré sur la figure 4b, on a supposé que TpsRl est inférieure à TpsR2, c'est-à-dire que la transaction Trl se termine avant la transaction Tr2. A partir de t2, la durée jusqu'au plus proche instant de fin d'une des transactions en cours est donc : TpsRk = TpsRl = t23, et le plus proche instant de fin d'une des transactions en cours est donc t3. Cinquième phase P5 : dans une étape E8, on assigne une attente de la durée TpsRk avant la génération du prochain événement de fin de transaction (c'est-à-dire avant une nouvelle exécution de l'algorithme, si aucun événement de début de nouvelle transaction ou de changement du débit maximal ne se produit entre-temps. En résumé, avec l'exemple de la figure 4b, l'algorithme en cinq phases n'est exécuté que quatre fois, lors des quatre évènements suivants : début de la transaction Trl (à tl), début de la transaction Tr2 (à t2), fin de la transaction Trl (à t3) et fin de la transaction Tr2 (à t4). Ainsi, pour cet exemple, l'efficacité de la technique (se mesurant en nombre d'événements) se constate par le fait que seuls les quatre événements en tl, t2, t3 et t4 sont nécessaires pour l'activation de l'algorithme. Cet algorithme se trouve paramétré par l'ensemble des valeurs Di. Ces valeurs peuvent être fixes ou peuvent varier durant l'évolution du modèle. Il est aussi possible de considérer l'ensemble Ri comme paramètre sachant que Di = DébitMax * Ri. Ces valeurs Di et/ou Ri définissent en fait la politique de partage du bus. Toutes les politiques de partage sont réalisables par cette technique. Comme exemples non limitatifs, citons : - politique d'entrelacement égalitaire : les valeurs Di se calculent par DébitMax/N, N étant le nombre de transactions en cours ; - politique par priorité telle que : Di = DébitMax pour la transaction i la plus prioritaire, et : Di = 0 pour les autres transactions ; - politique de type FIFO, telle que : Di = DébitMax pour la transaction i la plus prioritaire, et : Di = 0 pour les autres transactions ; - politique de qualité de service (QoS, pour Quality of Service en anglais) : chaque transaction i est associée à une priorité Pi et un débit demandé DébitDemandé_i. Par ordre de priorité décroissante, chaque transaction i se voit allouer son débit demandé, ou le débit restant s'il est inférieur à son débit demandé. Ainsi, toutes les phases de l'algorithme ci-dessus sauf la troisième phase P3 sont indépendantes de la politique d'allocation souhaitée. Une programmation par l'utilisateur est possible, simplement par remplacement du traitement de la troisième phase P3. 6.2 Descriptif détaillé illustré Dans la suite de la description, on présente un exemple d'exploitation du procédé selon l'invention dans une nouvelle version des outils CoFluent Studio (marque déposée). Les différents modèles sont représentés suivant les notations et la sémantique décrites dans les notations de la méthodologie MCSE. Les algorithmes sont donnés pour différentes politiques d'accès au noeud. 6.2.1 Création du modèle architectural L'éditeur graphique de CoFluent Studio sert à capturer les modèles fonctionnels (aussi appelés modèles d'application) constitués de fonctions communicantes et concurrentes disposant de leur propre comportement et entrées-sorties. La figure 6 présente un exemple d'allocation d'un modèle d'application 61 sur un modèle de plate-forme matérielle 62, permettant l'obtention d'un modèle architectural 63a, 63b qu'il s'agit de simuler pour étudier ses propriétés. Ce dernier est présenté d'une part sous une forme arborescente 63a et d'autre part sous une forme graphique 63b. Dans l'exemple de modèle d'application 61 utilisé dans la suite, des fonctions ou tâches cycliques échangent des messages par paire : - les fonctions FctO et Fct3, via le canal ChannelO ; - les fonctions Fctl et Fct4, via le canal Channell ; - les fonctions Fct2 et FctS, via le canal Channel2. Un message est en fait une transaction atomique contenant des informations et/ou des données. Ce modèle d'application représente une génération de transactions simultanées. L'exemple de modèle de plateforme 62 est très simple et comprend deux processeurs ProO et Prol, couplés par un bus commun NodeO. Une mémoire pourrait se connecter sur ce bus, mais ceci n'est pas nécessaire pour l'illustration. Il suffit simplement de penser que Prol peut en fait être une mémoire. Le modèle architectural 63a, 63b est obtenu par l'allocation (ou mapping ) des fonctions du modèle d'application 61 sur les processeurs du modèle de plateforme 62. Il en résulte que les transactions échangées entre les fonctions par les canaux ChannelO, Channell et Channel2 (dupliqués sur chaque processeur) doivent transiter par le noeud de communication physique NodeO. Des interfaces sont ajoutées dans le modèle architectural afin de modéliser la gestion des communications par le noeud NodeO : - interfaces ChOOutlnterface , Ch1OutInterface et NodeOlnlnterface dans le processeur ProO ; - interfaces NodeOInInterface et NodeOOutInterface dans le processeur Prol. Le noeud NodeO est ici configuré comme un bus ayant un débit de 100 Moctets/s. Le canal ChannelO assure le transfert de données de 10000 octets (soit: une transaction de durée 100 jts sur le noeud Node0). Le canal Channell fait 100 octets (soit 1 ps sur le noeud NodeO) et le canal Channel2 assure le transfert de données de 1000 octets (soit une transaction de durée 10 s sur le noeud Node0). Le choix de la politique de partage du bus se fait par l'attribut BusAccessPolicy attaché au noeud NodeO. Les modes implémentés sont par exemple ceux précités (politique d'entrelacement égalitaire, politique par priorité, politique de type FIFO et politique QoS). Chacun de ces modes fixe le comportement pour toutes les transactions soumises au noeud. 6.2.2 Résultats et solution pour la politique de partage par entrelacement égalitaire La figure 7 illustre une politique de partage de noeud par entrelacement égalitaire, en présentant en partie haute 71 un exemple de diagramme de séquence et en partie basse 72 une représentation graphique du partage du noeud. Les trois interfaces ChannelOOutInterface, Channel 1OutInterface et NodeOOutInterface produisent des transactions sur le noeud NodeO pour les échanges ChannelO, Channel 1 et Channel2. La partie supérieure 71 de la figure 7 montre le résultat sous forme de diagramme de séquence ( timeline en anglais) dérivé du diagramme de Gantt. On peut y observer le début et la fin de chaque transaction sur le bus. On constate en particulier le transfert simultané des trois transactions. La partie inférieure 72 de la figure 7 est un outil de présentation graphique du partage du bus pour les transactions. A partir de l'instant Dl jusqu'à D2, le bus est utilisé pour le transfert de ChannelO par l'interface ChannelOOutInterface avec son utilisation maximale de 100 MCyps (million de cycles par seconde). De l'instant D2 à l'instant D3, le débit du bus se répartit entre les deux transactions ChannelO (par ChannelOOutInterface) et Channel2 (par Node0Outlnterface). De l'instant D3 à l'instant F3, le débit se répartit par 1/3 entre ChannelO (par Channel00utlnterface), Channel 1 (par Channel10utlnterface) et Channel2 (par NodeOOutInterface). Et ainsi de suite. Nous donnons ci-après une explication de l'algorithme qui produit un tel résultat. La compréhension de l'algorithme repose sur la connaissance de la structure de la classe d'objet représentant chaque transaction en cours. Celle-ci contient les champs ou membres suivants (description en langage C++) : Class Transaction { Transaction* Next; 10 double TransactionSize; transaction double RemainingTransactionSize; à transmettre int priority; transaction double RelativeThroughput; double Throughput; double AllocatedThroughput; double EndDate; transaction //Quantité totale associée à la //Quantité d'information restante //Priorité associée à la //Facteur de pondération //Débit associé à la transaction //Débit alloué à la transaction //Date de l'événement de fin de la 15 20 25 30 } La liste des transactions en cours à l'issue de la phase P2 de l'algorithme est une liste pointée par pTransactionList, composée d'objets correspondant à la classe Transaction. La liste est constituée par le chaînage des objets par le champ Next. La correspondance suivante pour chaque transaction i permet la compréhension du principe décrit précédemment : RemainingTransactionSize = quantité restante Qi RelativeThroughput = Ri Throughput = Di demandé AllocatedThroughput = Di alloué par la politique d'ordonnancement EndDate = Date courante + TpsRi (utilisé ensuite par le simulateur lors de la phase P5) Nous donnons ci-après l'algorithme correspondant à la phase P3. L'algorithme pour toutes les autres phases est indépendant de la politique voulue. // phase P3- Calcul des valeurs AllocatedThroughput pour toutes les transactions en cours int NbrTransactions = pTransactionList->GetNbOfElement();//NbrTransactions = nombre de transactions en cours double Throughputi = GetAvailableThroughput()/NbrTransactions; while (pTransactionList != NULL){ pTransactionList ->Throughput = Throughputi; pTransactionList ->AllocatedThroughput = Throughputi; pTransactionList = pTransactionList->Next; } } GetNbOfElement () est une méthode fournissant le nombre de transactions en cours (donc dans la liste pointée par pTransactionList). GetAvailableThroughput () est une méthode fournissant le débit maximum du noeud. Throughputi est le débit allouable à chaque transaction. Cette valeur est ensuite assignée à chaque transaction par parcours de la liste. La phase P4 exploite ensuite uniquement le champ AllocatedThroughput pour calculer la valeur EndDate de chaque transaction de la liste. 6.2.3 Résultats et solution pour la politique de partage par priorité La figure 8 illustre une politique de partage de noeud par priorité, en présentant en partie haute 81 un exemple de diagramme de séquence et en partie basse 82 une représentation graphique du partage du noeud. L'ordre des priorités est la suivante : Channel 1>Channel2>ChannelO. On constate sur le diagramme de séquence que les fins des transactions Channel 1 et Channel2 ne sont pas identiques aux fins constatées pour l'entrelacement. La répartition du débit du bus visible sur la partie basse 82 montre qu'une seule transaction est active à la fois et que le bus est préempté par Channel2 d'abord puis par Channel 1. L'algorithme correspondant à la phase P3 est donné ci-dessous. Il exploite le champ Priority. Cet algorithme assure d'abord le classement des transactions selon un ordre décroissant de priorité. Ensuite le débit maximum disponible est alloué à la transaction la plus prioritaire. Un débit nul est alloué à toutes les autres transactions. // phase P3- Calcul des valeurs AllocatedThroughput pour toutes les transactions en cours pTransactionList->ClassifyByPriority();// ordonner la liste par priorité pTransactionList->AllocatedThroughput = GetAvailableThroughput(); pTransactionList = pTransactionList->Next; while (pTransactionList != NULL){ pTransactionList-> AllocatedThroughput = 0.0; pTransactionList = pTransactionList->Next; } 6.2.4 Résultats et solution pour la politique de partage de type QoS La figure 9 illustre une politique de partage de noeud dans le cas d'une politique QoS, en présentant en partie haute 91 un exemple de diagramme de séquence et en partie basse 92 une représentation graphique du partage du noeud. Chaque transaction est personnalisée par sa priorité et par le débit demandé. Les valeurs suivantes sont utilisées : - ChannelO => Priorité = 8, Débit = 70 Moctets/s - Channel l => Priorité = 15, Débit = 40 Moctets/s -Channel2 => Priorité = 10, Débit = 50 Moctets/s Comme le bus est programmé pour ne pas exploiter toute sa bande passante (70 Moctets/s), la transaction la moins prioritaire s'achève plus tard, vers 200 pis. A noter entre les instants D3 et F3 la répartition du débit en fonction de la priorité. En effet, il reste 10 Moctets/s pour ChannelO. La programmation spécifique de chaque transaction se fait par l'une des deux méthodes suivantes qui doit être exécutée dans la primitive d'envoi d'une transaction nommée Send et ceci avant l'appel de l'algorithme. Ces deux méthodes servent à créer et à initialiser l'objet Transaction (donc les champs Transactionsize, Priority, RelativeThroughput,Throughput). -SetNodeRequest(TransactionSize, Priority, RelativeThroughput) ; -SetNodeRequest(TransactionSize, Priority, Throughput, ThroughputUnit); L'algorithme correspondant à la phase P3 est donné ci-dessous. II exploite le champ Priority. Cet algorithme assure d'abord le classement des transactions selon un ordre de priorité décroissant. Ensuite le débit maximum disponible est alloué aux transactions les plus prioritaires et en accord avec la demande de chacune stipulée dans le champ Throughput. // phase P3- Calcul des valeurs AllocatedThroughput pour toutes les transactions en cours double RequestedThroughput = 0.0; int PriorityValue; float k; Transaction plist, BeginList; pTransactionList->ClassifyByPriority();// ordonner la liste par priorité plist = pTransactionList; RemainingThroughput = GetAvailableThroughput(); while (plist != NULL){ PriorityValue = plist->priority; BeginList = plist; while ((plist != NULL) && (plist->priority == PriorityValue)){ //faire pour chaque priorité RequestedThroughput += plist->Throughput; plist-> AllocatedThroughput = plist->Throughput:; plist = plist->Next; } if (RemainingThroughput > RequestedThroughput){ RemainingThroughput = RemainingThroughput -RequestedThroughput; RequestedThroughput = 0.0; } else{ k = RemainingThroughput/RequestedThroughput; plist = BeginList; while ((plist != NULL) && (plist->priority == PriorityValue)){ plist->AllocatedThroughput = plist->Throughput * k; plist = plist->Next; } while (plist != NULL){ plist->AllocatedThroughput = 0.0; plist = plist->Next; } } } L'algorithme considère que des transactions peuvent avoir la même priorité. Ainsi le débit disponible est alors alloué pour toutes les transactions de même priorité. Deux cas se présentent. Le débit disponible est suffisant pour satisfaire les demandes pour la priorité, alors le reste est considéré pour l'allocation aux transactions moins prioritaires. Le débit disponible n'est pas suffisant, alors il est partagé proportionnellement à toutes les transactions de la priorité (coefficient k). 6.2.5 Programmation de la politique de partage par l'utilisateur La phase P3 est rendue programmable (surchargée au sens objet) par l'emploi de la méthode suivante. Cette méthode est alors exécutée en remplacement des algorithmes donnés ci-dessus. void UserNodeScheduling(Transaction* pTransactionList) { //Partie à définir par l'utilisateur } REVENDICATIONS 1. Procédé de simulation transactionnelle d'un modèle générique de noeud de communication compris dans un modèle de système complexe, ledit modèle générique de noeud gérant des transactions entre des constituants dudit modèle de système complexe, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes, effectuées à chaque pas de simulation correspondant à un événement appartenant au groupe d'évènements comprenant des débuts de transaction et des fins de transactions : - calcul (El) d'une quantité restante de données à transmettre pour chaque transaction non achevée présente dans une liste des transactions en cours ; - si ledit pas de simulation correspond au début d'une nouvelle transaction, calcul (E3) d'une quantité de données à transmettre pour la nouvelle transaction et ajout de la nouvelle transaction dans la liste des transactions en cours - si ledit pas de simulation correspond à la fin d'une transaction, retrait (E5) de la transaction de la liste des transactions en cours ; -allocation (E6) de débits aux transactions en cours, selon une politique de partage du noeud prédéterminée ; - calcul (E7) d'une durée TpsRk jusqu'au plus proche instant de fin d'une des transactions en cours : TpsRk = MIN(TpsRi), avec TpsRi = Qri/Di, TpsRi étant la durée jusqu'à l'instant de fin d'une transaction i en cours, Qri la quantité de données restante pour la transaction i et Di le débit alloué à la transaction i ; - assignation (E8) d'une attente de ladite durée TpsRk avant la génération du prochain événement de fin de transaction. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape (E6) d'allocation de débits aux transactions en cours est une étape d'allocation directe de débits. 3. Procédé selon la revendication 1, caractérisé en ce que l'étape (E6) d'allocation de débits aux transactions en cours est une étape d'allocation indirecte de débits comprenant les étapes suivantes : -allocation aux transactions en cours, selon ladite politique de partage du noeud prédéterminée, de pourcentages d'un débit maximal DébitMax du modèle générique de noeud ;- calcul des débits alloués aux transactions en cours en appliquant la formule suivante : Di = DébitMax * Ri, avec Ri le pourcentage du débit maximal alloué à la transaction i. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la politique de partage du noeud prédéterminée appartient au groupe comprenant : - une politique d'allocation par entrelacement égalitaire, telle que toutes les valeurs Di sont égales à DébitMax/N, avec DébitMax le débit maximal du modèle générique de noeud et N le nombre de transactions en cours ; - une politique d'allocation par priorité, telle que : Di = DébitMax pour la transaction i la plus prioritaire, et : Di = 0 pour les autres transactions ; - une politique d'allocation de type premier entré premier sorti (FIFO), telle que : Di = DébitMax pour la transaction i la plus ancienne, et : Di = 0 pour les autres transactions ; - une politique d'allocation de type qualité de service (QoS), telle que chaque transaction i est associée à une priorité Pi et un débit demandé I)ébitDemandé_i, et, par ordre de priorité décroissante, chaque transaction i se voit allouer son débit demandé ou le débit restant s'il est inférieur à son débit demandé. 5. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit groupe d'évènements comprend en outre des modifications d'un débit maximal DébitMax du modèle générique de noeud. 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. 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 à 6, lorsque ledit programme est exécuté sur un ordinateur. 8. 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 à 6.