FR2971596A1 - Dispositif pour accelerer l'execution d'une simulation systemc - Google Patents

Abstract

La présente invention concerne un dispositif pour accélérer, sur une plateforme comportant une pluralité d'unités de traitement, l'exécution d'une simulation SystemC d'un système, ladite simulation comportant un noyau SystemC et des processus SystemC. Le dispositif comporte des moyens matériels pour ordonnancer les processus SystemC sur les unités de traitements de manière dynamique pendant l'exécution de la simulation, ces moyens permettant notamment de préempter les unités de traitement. Application : outils de vérification et d'émulation de circuits complexes

Description

Dispositif pour accélérer l'exécution d'une simulation SystemC Domaine technique : La présente invention concerne un dispositif pour pour accélérer l'exécution d'une simulation SystemC. Elle s'applique par exemple dans le domaine des outils de vérification et d'émulation de circuits complexes.

Art antérieur et problème technique : Les applications devenant de plus en plus complexes et performantes, les systèmes à concevoir pour supporter ces applications nécessitent l'utilisation de moyens de simulation de plus en plus importants et rapides. La simulation de ces systèmes a plusieurs rôles. Elle permet non seulement de fournir un support pour le développement des couches applicatives et la validation des applications, mais également de concevoir, dimensionner, évaluer les performances et d'explorer l'espace de conception afin de garantir le fonctionnement et de valider les solutions choisies. Par ailleurs, le dynamisme des applications empêche de s'intéresser uniquement aux performances crêtes et seules des simulations permettent d'estimer et de comprendre les performances efficaces et de dimensionner correctement l'architecture de ces systèmes. Ainsi, la simulation de très grands systèmes, comme les architectures multiprocesseurs constituées de plusieurs dizaines de coeurs de calcul voire de plusieurs centaines, peut se révéler très lente, de plusieurs jours à plusieurs semaines. Dans le cycle de conception d'un tel système, l'architecte doit réaliser un modèle fonctionnel voire transactionnel avec des informations temporelles pour effectuer le dimensionnement, l'évaluation des performances effectives de son système, et l'exploration de différentes solutions architecturales afin de trouver celle qui réponde au mieux à ses besoins. Mais lorsque le système devient trop complexe, il n'est plus possible de conserver ce modèle et le concepteur doit alors faire des choix méthodologiques. Pendant de nombreuses années, le langage C ou C++ a été utilisé pour développer des systèmes logiciels et matériels. L'utilisation de ce langage est due à plusieurs raisons. Tout d'abord, il est facile d'utilisation et très connu par les concepteurs de systèmes. Ensuite, de nombreux algorithmes et applications sont décrits et disponibles dans ce langage et ceci permet de réutiliser des librairies ou du code existants afin de réduire les coûts de développement. Enfin, il permet de décrire dans un même programme les parties logicielles et matérielles d'un système et leurs interactions. Cependant, le langage C ou C++ ne permet pas de décrire la concurrence ou la notion de temps, indispensable pour la conception de systèmes matériels. Pour cela, le modèle matériel doit être traduit manuellement dans un langage de description matériel comme le VHDL (Very high speed integrated circuits Hardware Description Language) ou le VERILOG. L'intérêt d'une traduction d'un modèle matériel en VHDL ou en VERILOG tient à ce qu'elle est exécutable et peut ainsi être vérifiée par 1 o simulation, ou par des moyens d'émulation matérielle. Mais un inconvénient majeur est que cette traduction est longue et très difficile. De surcroît, elle introduit souvent des erreurs ou imposent des contraintes jusqu'alors ignorées qui changent les hypothèses ou les spécifications initiales. Pour tenter de répondre à ces inconvénients, un consortium, 15 nommé Open SystemC Initiative (OSCI), a développé un nouveau standard international (IEEE Std. 1666TM-2005) appelé SystemC qui est aujourd'hui très largement utilisé dans le monde entier. SystemC est une librairie C++ associé à un moteur de simulation, capable de combler ces manques et de transformer le langage C et C++ en langage de description matériel. 20 SystemC introduit donc notamment les notions de concurrence et de temps. Aujourd'hui, des outils permettent la synthèse matérielle de systèmes décris en SystemC au niveau RTL (Register Transfer Level) via une traduction automatique en VHDL ou VERILOG. Ainsi, les moyens d'émulation matérielle disponibles pour ces langages de description matériels peuvent 25 être utilisés pour accélérer les simulations. Cependant, décrire un système en RTL est long et fastidieux, et il est très coûteux de revenir sur ses choix architecturaux. En effet, le niveau de description RTL est tel qu'il est très long d'obtenir une solution fonctionnelle. De plus, il est nécessaire de développer le code système et de porter une application pour valider l'architecture. Il faut 30 donc faire des choix très tôt, c'est-à-dire dans la phase de conception, concernant le modèle de programmation et d'exécution, ces choix pouvant se révéler inadaptés. Enfin, les développeurs logiciels ne peuvent pas avoir accès à ce type de plateforme d'émulation, car elle nécessite l'utilisation d'outils de conception matériels non connus des ingénieurs logiciels qui ne 35 s'intègrent pas dans leur environnement de développement. Ainsi, cette solution n'est envisageable que pour valider le système avant de démarrer le processus de fabrication, lorsque tous les outils, les logiciels et le système complet ont été définis, réalisés et validés. Pour tenter de répondre à cet inconvénient, une nouvelle librairie C++ appelée Transactional Level Modeling (TLM) a été créée, fournissant un niveau d'abstraction bien supérieur à celui du niveau RTL pouvant intégrer également des informations temporelles de haut niveau. En particulier, le TLM permet d'abstraire les communications entre les processus SystemC et d'accroître les vitesses de simulation. Cette librairie TLM répond en fait à un 1 o besoin croissant de conception de systèmes de plus en plus complexes. Ainsi, les développeurs logiciels ont la possibilité d'utiliser un modèle fonctionnel rapide de l'architecture. Mais là encore les inconvénients sont nombreux. Tout d'abord, seulement une partie des validations peuvent être réalisées puisque le modèle n'a plus d'informations temporelles précises. De 15 plus, l'optimisation du code n'est plus possible et il n'est par exemple pas possible d'estimer précisément le coût des communications entre les différentes tâches ou mémoires. Enfin, ce modèle ne permet pas l'exploration de tout l'espace de conception, car il n'apporte pas suffisamment d'information. 20 Ainsi, il semble qu'il n'existe pas aujourd'hui une solution capable de répondre à la fois aux problèmes de la conception du logiciel et à la conception de systèmes complexes.

25 Dans des demandes de brevet chinois CN101634979, CN1 01 31 5648, CN101329702, CN101635006, CN101770362 et CN1 01 1 96826 déposées par l'Institut des Technologies Informatiques de l'Académie des Sciences de Chine, l'utilisation d'unités matérielles spécifiques pour accélérer l'exécution des simulations SystemC est 30 proposée. Adjointes à un processeur RISC (Reduced Instruction Set Computer), des unités matérielles capables d'émuler des primitives ou des fonctions SystemC sont utilisées pour accélérer les simulations. Ces primitives supportent par exemple la gestion dynamique de processus (SC_SPAWN), les sémaphores et les exclusions mutuelles (mutex), les FI FO 35 (First ln First Out) et la gestion des listes de sensibilité et des évènements.

En plus, des unités particulières pour l'échange de données entre processus sont utilisées pour stocker les valeurs des signaux. Un inconvénient majeur de cette approche est qu'elle nécessite une modification profonde de la librairie SystemC afin d'utiliser les primitives sur les unités matérielles. De plus, le nombre limité d'unités matérielles contraint irrémédiablement les possibilités de modélisation. Enfin, l'exécution des processus SystemC est considérablement ralentie par d'incessants changements de contexte.

Exposé de l'invention L'invention a notamment pour but d'accélérer n'importe quel type de simulation SystemC décrite dans un langage C ou C++ en utilisant les librairies standards SystemC et TLM sans aucune modification. Pour cela, l'invention propose une accélération matérielle du noyau SystemC capable de répartir l'ensemble des processus dynamiquement sur une pluralité d'unités de calcul. A cet effet, l'invention a pour objet un dispositif pour accélérer, sur une plateforme comportant une pluralité d'unités de traitement, l'exécution d'une simulation SystemC d'un système, ladite simulation comportant un noyau SystemC et des processus SystemC. Le dispositif comporte des moyens matériels pour ordonnancer les processus SystemC sur les unités de traitements de manière dynamique pendant l'exécution de la simulation. Avantageusement, les moyens pour ordonnancer les processus system C permettent de préempter les unités de traitement, de sorte que si un premier processus systemC exécuté par une unité de traitement est bloqué en attente d'une synchronisation avec un deuxième processus systemC, alors ladite unité de traitement est préemptée, ladite unité de traitement sauvegardant son contexte d'exécution dans une mémoire partagée par les unités de traitement et commençant l'exécution d'un autre processus systemC, l'exécution du premier processus étant reprise ultérieurement. Avantageusement, le système simulé peut être décrit au niveau RTL ou au niveau TLM. Dans un mode de réalisation préférentiel, les moyens matériels pour ordonnancer les processus SystemC peuvent inclure des moyens pour exécuter le noyau SystemC. Ils peuvent également inclure des moyens pour gérer des évènements, ces moyens pouvant inclure une liste de tous les évènements pouvant être générés associés à des identifiants des processus SystemC sensibles auxdits évènements. Ils peuvent aussi inclure des moyens pour gérer le temps, ces moyens pouvant inclure un chien de garde pour chacun des processus SystemC. Par exemple, les moyens pour exécuter le noyau SystemC peuvent inclure un processeur RISC pour exécuter les instructions formant le noyau SystemC. Les moyens pour exécuter le noyau SystemC peuvent également 1 o inclure un graphe de dépendance entre les processus SystemC, de manière à activer des processus fils dès lors que leurs processus pères respectifs ont été exécutés. Dans un mode de réalisation préférentiel, les moyens pour gérer le temps peuvent inclure un compteur fournissant un temps simulé courant. 15 Ils peuvent également inclure une mémoire contenant une liste des temps simulés à atteindre par chacun des processus en cours d'exécution sur les unités de traitement. Ils peuvent également inclure une mémoire contenant une liste des états de chacun des processus en cours d'exécution sur les unités de traitement, cet état indiquant que le processus est actif ou en 20 attente. Ils peuvent également inclure des moyens pour comparer le temps simulé courant aux temps simulés à atteindre par chacun des processus. L'état d'un processus peut alors commuter de l'état actif à l'état d'attente dès lors que le temps simulé courant a atteint le temps simulé à atteindre associé audit processus. 25 Les moyens pour gérer des évènements peuvent inclure une mémoire contenant une liste d'identifiants d'évènements. Ils peuvent également inclure une mémoire contenant, pour chaque identifiant d'évènement, l'adresse dans une autre mémoire d'une liste des processus sensibles audit évènement. 30 Avantages : L'invention a encore pour principaux avantages qu'elle supporte les communications transactionnelles et permet l'accélération de simulations SystemC à un niveau d'abstraction élevé. Elle propose également des moyens de mise au point et de trace pour la validation du modèle ou de l'application exécutée. L'invention a encore pour principaux avantages qu'elle offre un modèle temporel rapide et très flexible, s'intégrant dans n'importe quel environnement de développement ou de conception. Elle offre aux développeurs de logiciel et de matériel une solution idéale pour la conception de systèmes complexes. Ceci a un impact très important sur les temps de développement et constitue un avantage majeur pour la compétitivité.

1 o Description des figures : D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard de dessins annexés qui représentent : - la figure 1, par un diagramme, une illustration d'un exemple de 15 réalisation de l'invention sur une plateforme multiprocesseur ; - la figure 2, par un diagramme, une illustration d'un exemple de réalisation d'une unité de contrôle selon l'invention ; - la figure 3, par un diagramme, une illustration d'un exemple de réalisation d'une unité de gestion du temps selon l'invention; 20 - la figure 4, par un diagramme, une illustration d'un exemple de réalisation d'une unité de gestion des évènements selon l'invention; - la figure 5, par un diagramme, un exemple d'ordonnancement de processus System C sur une pluralité de ressources de calcul; 25 - la figure 6, par un diagramme, une illustration d'un exemple de réalisation de l'invention sur un serveur de calcul accessible via un réseau Ethernet.

Description de l'invention à partir des figures : 30 L'invention inclut notamment un environnement matériel capable d'accélérer les simulations SystemC à des niveaux d'abstraction variables, qu'il s'agisse de RTL, de TLM ou même de TLM avec prise en compte d'informations temporelles, de systèmes complexes numériques et analogiques, ainsi que de leurs parties logicielles et matérielles. Cet 35 environnement matériel est constitué d'une pluralité de processeurs de calcul capables d'exécuter des processus SystemC, d'au moins une unité d'accélération matérielle du noyau SystemC en charge d'ordonnancer dynamiquement l'exécution des processus SystemC, de mémoires, d'entrées-sorties pour émuler les entrées-sorties du système simulé, ainsi que de moyens de mise au point et de trace. Ces unités d'accélération matérielle ont accès à une unité de gestion des évènements liant les processus sensibles afin de sélectionner les processus à exécuter, ainsi qu'à une unité de gestion temporelle afin de gérer l'ensemble des synchronisations temporelles présentes dans SystemC qui régissent la 1 o concurrence entre les processus, et ainsi qu'à un graphe de dépendance entre processus pour déterminer un ordre partiel d'ordonnancement et minimiser le nombre de changement de contexte.

15 La figure 1 illustre par un diagramme un exemple de mise en oeuvre de l'invention dans un environnement multiprocesseur. L'environnement matériel inclut une pluralité d'unités de calcul P1 à Pn contrôlées par une unité matérielle HWSKS selon l'invention (HardWare SystemC Kernel Sequencing), cette unité HWSKS permettant de contrôler 20 les processus du noyau SystemC. Cette architecture, dite asymétrique, présente l'avantage de séparer explicitement le contrôle, c'est-à-dire l'exécution du noyau SystemC par l'unité HWSKS, et le calcul, c'est-à-dire l'évaluation des processus SystemC par les processeurs P1 à Pn. Dans ce mode de réalisation, les unités de calcul P1 à Pn sont 25 des processeurs capables d'exécuter les processus SystemC. Chaque unité de calcul P1 à Pn est accompagnée d'une interface de contrôle CTRL_IF pour communiquer avec l'unité HWSKS via un bus de contrôle et d'une unité TLB de translation des mémoires caches pour accéder au contenu des mémoires partagées. Les unités de calcul P1 à Pn sont reliées via un réseau 30 d'interconnexion, un multibus par exemple, à différentes mémoires ainsi qu'à une unité I/OM de gestion des entrées-sorties (1/0 Management). Une mémoire SPC (SystemC Processes Context) permet de sauvegarder les contextes des différents processus SystemC actifs. Elle est partagée par les processeurs P1 à Pn. Une mémoire SP/LD (SystemC Processes / Local 35 Data) permet de stocker le code lié aux processus SystemC, comme les instructions, les variables locales et les constantes. Une mémoire SDM (Shared Data Memory) permet de stocker les données partagées entre les processus SystemC comme les variables globales et les constantes. Enfin, une mémoire système SM (System Memory) contient l'ensemble des routines du logiciel système pour supporter les préemptions ou l'initialisation des unités de calcul P1 à Pn par exemple. Dans ce mode de réalisation, une MCMU (Memory Configuration and Management Unit) permet de transférer à l'initialisation le code des processus SystemC, et de gérer dynamiquement les accès aux mémoires 1 o partagées 4. Cette unité permet de gérer la pagination et les translations associées aux codes des processus SystemC et de leur contexte, ainsi que l'allocation dynamique d'espace mémoire dans la mémoire partagée. Conformément à l'invention, l'unité de contrôle HWSKS permet l'exécution matérielle du noyau SystemC. 15

Dans la suite de la présente demande, le terme « processus » est utilisé pour désigner implicitement des processus SystemC.

20 La figure 2 illustre par un diagramme un exemple de réalisation de l'unité HWSKS selon l'invention, qui supporte l'exécution du noyau SystemC. Elle tient compte d'un graphe de dépendance entre les processus pour déterminer leur ordre d'activation, ce graphe n'étant pas représenté sur la 25 Figure 2. L'unité HWSKS comporte une unité ETU de gestion des évènements (Event Tag Unit) qui possède la liste de tous les évènements pouvant être générés associés aux numéros des processus à activer sur occurrence de ces évènements. L'unité HWSKS comporte également une unité WTU de gestion du temps (Watchdog Tag Unit) qui possède un chien 30 de garde pour chacun des processus et permet de référencer les processus en attente de synchronisation et d'évaluer les attentes longues de synchronisation. L'unité WTU évite ainsi le réveil inutile de processus. L'unité HWSKS utilise alors ces informations pour activer les processus et répartir leur exécution sur les unités de calcul P1 à Pn, via le bus de contrôle de la 35 Figure 1 par exemple.

L'ordonnancement des processus se fait de manière dynamique, c'est-à-dire pendant l'exécution de la simulation. Un processus alloué sur une unité de calcul parmi P1 à Pn peut être préempté ou migré vers une autre unité de calcul parmi P1 à Pn si l'unité HWSKS le décide. Un gestionnaire d'horloge SystemC TM (Timer Management) permet à chaque processus d'avoir accès au temps courant de simulation et permet au noyau SystemC d'ordonnancer ses processus en fonction du temps. Dans le mode de réalisation des figures 1 et 2, l'unité de contrôle HWSKS peut être une structure programmable comportant, en plus des 1 o unités matérielles ETU et WTU, un module SKE (SystemC Kernel Evaluation) incluant par exemple un processeur RISC (Reduced Instruction Set Computer), de sorte que le module SKE peut exécuter le code du noyau SystemC. Ainsi, l'exécution de ce code, via l'utilisation des unités matérielles ETU et WTU, a un comportement compatible avec le noyau SystemC issu de 15 la version standard. Le module SKE utilise également un graphe de dépendance entre les processus, qui est une structure de données organisée sous forme de liste chaînée. Dans cette liste, chaque processus possède des processus pères et des processus fils. Lorsque les processus pères ont été évalués, les processus fils sont activés. 20

La figure 3 illustre un mode de réalisation de l'unité WTU comportant deux mémoires WTU_MO et WTU_M1, ainsi qu'un ensemble de comparateurs représentés par des symboles "<" et une horloge TT. L'horloge 25 TT peut être un compteur matériel Current sc time qui représente le temps courant SystemC, qui sera appelé "temps simulé" par la suite. Ce compteur est incrémenté à chaque pas de simulation, une fois que tous les processus ont été évalués et que l'unité ETU est vide. La mémoire WTU_MO contient, pour chacun des processus PR1 à PRn, le temps simulé à atteindre 30 Stop time reg. Lorsque ce temps est atteint, c'est-à-dire lorsque Current sc time = Stop time reg, le contenu de la mémoire WTU_M1 est mis à jour. Le processeur SKE peut accéder à cette mémoire WTU_M1 pour vérifier l'état des processus. Si le contenu de la mémoire est positif (1), le processus est considéré comme en attente. Dans le cas contraire (0), le 35 processus est considéré comme actif.

La figure 4 illustre un mode de réalisation de l'unité ETU comportant trois mémoires ETU_M0, ETU_M1 et ETU_M2. La mémoire ETU_MO permet de stocker les identifiants d'évènements du type evn, qui sont générés lors de l'évaluation des processus. La mémoire ETU_M1 est une mémoire dont chaque ligne contient un mot comportant deux champs. Le premier champ est un identifiant d'évènement, du type evn sur la figure 4, et le second est une adresse dans une mémoire ETU_M2, du type @processus listm sur la figure 4, d'une liste de processus PR1 à PRn sensibles à cet évènement evn. La mémoire ETU_M2 contient donc des listes de processus et les adresses du type @a processus listm spécifiées dans la mémoire ETU_M1 sont des pointeurs sur des cases de la mémoire ETU_M2. Ces trois mémoires ETU_M0, ETU_M1 et ETU_M2 permettent donc, à partir d'un évènement, de retrouver rapidement tous les processus sensibles, afin de pouvoir les activer ultérieurement. Ainsi, pour chacun des évènements, tous les processus sensibles sur cet évènement sont activés. Lorsque tous les processus d'un évènement evn dans ETU_M0 ont été activés, l'évènement correspondant est supprimé de la mémoire ETU_M0.

Une fois tous les évènements supprimés de ETU_M0, l'unité ETU est considéré comme étant vide.

Dans le mode de réalisation illustré par les figures qui précèdent, l'utilisateur charge dans l'unité HWSKS le graphe de dépendances entre les processus, ainsi que l'ensemble des codes liés aux processus dans la mémoire SP/LD. L'unité HWSKS démarre alors son cycle d'exécution suivant le fonctionnement du noyau SystemC et exécute tous les processus en parallèle suivant la disponibilité des unités de calcul P1 à Pn. Tous les processus sont alors initialisés puis exécutés jusqu'à ce qu'ils rencontrent une synchronisation. Certains vont alors mettre à jour leurs signaux de sorties ou envoyer des transactions à d'autres processus. Dans ce dernier cas, suivant la norme TLM, les fonctions dites « transport » des processus cibles concernés sont exécutées jusqu'à ce que leur évaluation soit complète. Ainsi, tous les processus vont s'exécuter jusqu'à ce qu'ils rencontrent une synchronisation, que tous les processus dans WTU_M1 soient positifs et que la liste d'évènements activés dans l'unité ETU_MO soit vide. L'unité HWSKS aura juste pour rôle de distribuer équitablement les différents processus entre les unités de calcul P1 à Pn. Lorsque tous les processus exécutés sont bloqués en attente de synchronisation dans l'unité WTU, le gestionnaire d'horloge TM incrémente l'horloge SystemC suivant le pas de simulation. Puis, suivant le graphe de dépendance entre les processus actifs, l'unité HWSKS évalue de nouveau les processus qui ne sont plus en attente dans l'unité WTU en optimisant la répartition de la charge des unités de calcul P1 à Pn. Ce procédé a lieu jusqu'à la fin de la simulation.

Comme illustré par la figure 5, un avantage majeur de cette invention réside dans sa capacité à ordonnancer dynamiquement des processus sur les différentes unités de calcul homogènes P1 à Pn. Cette capacité est rendue possible grâce à la complémentarité des éléments constituant l'invention. Pour permettre la préemption et la migration des processus entre les unités de calcul P1 à Pn, il faut tout d'abord disposer d'un algorithme d'ordonnancement capable de prendre de telles décisions qui est exécuté par l'unité de contrôle HWSKS par l'intermédiaire de son processeur RISC. Cet algorithme peut donc simplement, en fonction de la durée d'exécution des processus ou de leur activité, décider de les préempter, pour les exécuter ultérieurement sur un processeur identique ou différent. Comme présenté dans la figure 5, supposons par exemple que le processus PR1 soit évalué sur le processeur P3. Si PR1 se met en attente d'une synchronisation avec un autre processus PR6 (en cours d'évaluation ou non), le processus PR1 est bloqué et le processeur P3 est alors sous- utilisé. L'invention propose d'interrompre PR1 jusqu'à ce qu'il ne soit plus bloqué, pour exécuter un autre processus, par exemple PR3, qui lui ne sera pas bloqué. Lorsque le processeur exécutant le processus concerné par la demande de préemption, envoyée par HWSKS, reçoit la commande, le processeur sauvegarde son contexte dans la mémoire partagée SPC. Cette mémoire est accessible et partagée entre tous les processeurs via le réseau d'interconnexion, le multibus dans le présent exemple de réalisation. Lorsque l'unité de contrôle HWSKS souhaite reprendre l'exécution du processus PR1, elle peut arbitrairement lui attribuer un processeur libre pour que celui-ci puisse continuer son évaluation, le processeur pouvant être le processeur préalablement préempté ou un tout autre processeur parmi P1 à Pn.

La figure 6 illustre par un schéma un autre mode de réalisation, intégrant sur une carte d'émulation installée dans un serveur de calcul accessible à un ensemble de clients via un réseau Ethernet plusieurs 1 o environnements matériels d'accélération SystemC selon l'invention. L'utilisateur peut exécuter le simulateur via son environnement de travail et ses outils de développements. Grâce à une interface particulière client-serveur, le simulateur peut être exécutée sur une carte d'émulation distante et toutes les informations de mise au point et de trace liées à l'interface 15 utilisateur peuvent être redirigées vers le client. Ainsi, l'utilisateur a l'impression d'exécuter localement le simulateur alors qu'il s'exécute sur un système distant. Le système distant peut être un serveur de calcul possédant une ou plusieurs cartes accélératrices, chacune pouvant accueillir un ou plusieurs modules d'accélération SystemC. Chaque module d'accélération 20 SystemC peut être constitué d'une architecture similaire à celle précédemment présentée, avec en plus une unité de mise au point et de trace capable de transférer toutes les informations nécessaires aux outils de développement utilisés par l'utilisateur.

25 Autres avantages : L'invention décrite précédemment fournit un moyen pour accélérer les simulations ainsi qu'un support permettant de réduire considérablement les temps de conception. En effet, la capacité à faire émerger rapidement un nouveau système sur le marché de l'électronique embarquée est directement 30 liée à la compétitivité et au facteur de pénétration et de réussite du produit commercial.

Claims (8)

1. REVENDICATIONS1. Dispositif pour accélérer, sur une plateforme comportant une pluralité d'unités de traitement (P1 à Pn), l'exécution d'une simulation SystemC d'un système, ladite simulation comportant un noyau SystemC et des processus SystemC, le dispositif étant caractérisé en ce qu'il comporte des moyens matériels (HWSKS) pour ordonnancer les processus SystemC sur les unités de traitements de manière dynamique pendant l'exécution de la simulation.
2. 2. Dispositif selon la revendication 1, caractérisé en ce que les moyens (HWSKS) pour ordonnancer les processus systemC permettent de préempter les unités de traitement (P1 à Pn), de sorte que si un premier processus systemC exécuté par une unité de traitement (P1 à Pn) est bloqué en attente d'une synchronisation avec un deuxième processus systemC, alors ladite unité de traitement est préemptée, ladite unité de traitement sauvegardant son contexte d'exécution dans une mémoire partagée (SPC) par les unités de traitement (P1 à Pn) et commençant l'exécution d'un autre processus systemC, l'exécution du premier processus étant reprise ultérieurement.
3. 3. Dispositif selon la revendication 1, caractérisé en ce que le système simulé est décrit au niveau RTL ou au niveau TLM.
4. 4. Dispositif selon la revendication 2, caractérisé en ce que les moyens matériels (HWSKS) pour ordonnancer les processus SystemC incluent: - des moyens (SKE) pour exécuter le noyau SystemC; - des moyens (ETU) pour gérer des évènements, ces moyens incluant une liste de tous les évènements pouvant être générés associés à des identifiants des processus SystemC sensibles auxdits évènements, et; - des moyens (WTU) pour gérer le temps, ces moyens incluant un chien de garde pour chacun des processus SystemC.
5. 5. Dispositif selon la revendication 4, caractérisé en ce que les moyens (SKE) pour exécuter le noyau SystemC incluent un processeur RISC pour exécuter les instructions formant le noyau SystemC.
6. 6. Dispositif selon la revendication 4, caractérisé en ce que les moyens (SKE) pour exécuter le noyau SystemC incluent un graphe de dépendance entre les processus SystemC, de manière à activer des processus fils dès lors que leurs processus pères respectifs ont été exécutés.
7. 7. Dispositif selon la revendication 4, caractérisé en ce que les moyens (WTU) pour gérer le temps incluent: - un compteur (Current sc time) fournissant un temps simulé courant; - une mémoire (WTU_MO) contenant une liste des temps simulés à atteindre (Stop time reg) par chacun des processus en cours d'exécution sur les unités de traitement (P1 à Pn); - une mémoire (WTU_M1) contenant une liste des états de chacun des processus en cours d'exécution sur les unités de traitement (P1 à Pn), cet état indiquant que le processus est actif ou en attente; - des moyens pour comparer le temps simulé courant aux temps simulés à atteindre par chacun des processus; l'état d'un processus commutant de l'état actif (0) à l'état d'attente (1) 25 dès lors que le temps simulé courant a atteint le temps simulé à atteindre associé audit processus.
8. 8. Dispositif selon la revendication 4, caractérisé en ce que les moyens (ETU) pour gérer des évènements incluent: 30 - une mémoire (ETU_MO) contenant une liste d'identifiants d'évènements (evn); - une mémoire (ETU_M1) contenant, pour chaque identifiant d'évènement (evn), l'adresse (@a processus listm) dans une autre mémoire (ETU_M2) d'une liste des processus sensibles audit 35 évènement.