WO2012110445A1 - Dispositif pour accélérer l'exécution d'une simulation system c - Google Patents

Dispositif pour accélérer l'exécution d'une simulation system c Download PDF

Info

Publication number
WO2012110445A1
WO2012110445A1 PCT/EP2012/052386 EP2012052386W WO2012110445A1 WO 2012110445 A1 WO2012110445 A1 WO 2012110445A1 EP 2012052386 W EP2012052386 W EP 2012052386W WO 2012110445 A1 WO2012110445 A1 WO 2012110445A1
Authority
WO
WIPO (PCT)
Prior art keywords
systemc
processes
execution
memory
kernel
Prior art date
Application number
PCT/EP2012/052386
Other languages
English (en)
Inventor
Nicolas Ventroux
Original Assignee
Commissariat A L'energie Atomique Et Aux Energies Alternatives
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 Commissariat A L'energie Atomique Et Aux Energies Alternatives filed Critical Commissariat A L'energie Atomique Et Aux Energies Alternatives
Priority to US13/984,525 priority Critical patent/US9612863B2/en
Publication of WO2012110445A1 publication Critical patent/WO2012110445A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G06F30/331—Design verification, e.g. functional simulation or model checking using simulation with hardware acceleration, e.g. by using field programmable gate array [FPGA] or emulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2117/00—Details relating to the type or aim of the circuit design
    • G06F2117/08—HW-SW co-design, e.g. HW-SW partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking

Definitions

  • the present invention relates to a device for accelerating the execution of a SystemC simulation. It applies for example in the field of tools for verification and emulation of complex circuits.
  • the simulation of these systems has several roles. It not only provides support for application layer development and application validation, but also design, scale, evaluate performance and explore the design space to ensure operation and validate selected solutions .
  • the dynamism of the applications makes it impossible to focus solely on peak performance, and only simulations make it possible to estimate and understand effective performance and correctly size the architecture of these systems.
  • the simulation of very large systems such as multiprocessor architectures consisting of several tens of computing cores or even hundreds, can be very slow, from several days to several weeks.
  • C or C ++ has been used to develop software and hardware systems.
  • the use of this language is due to several reasons. First of all, it is easy to use and well known by system designers. Then, many algorithms and applications are described and available in this language and this allows to reuse existing libraries or code to reduce development costs. Finally, it allows to describe in the same program the software and hardware parts of a system and their interactions.
  • the C or C ++ language does not allow to describe the competition or the notion of time, essential for the design of hardware systems. For this, the hardware model must be translated manually into a hardware description language such as the VHDL (very high speed integrated circuits Hardware Description Language) or VERILOG.
  • VHDL very high speed integrated circuits Hardware Description Language
  • VERILOG very high speed integrated circuits Hardware Description Language
  • OSCI Open SystemC Initiative
  • OSCI Open SystemC Initiative
  • RTL Register Transfer Level
  • TLM Transactional Level Modeling
  • CN101315648, CN101329702, CN101635006, CN101770362 and CN101 196826 filed by the Institute of Computer Technologies of the Chinese Academy of Sciences, the use of specific hardware units to accelerate the execution of SystemC simulations is proposed.
  • Adjoined to a Reduced Instruction Set Computer (RISC) processor hardware units capable of emulating primitives or SystemC functions are used to speed up simulations. These primitives support, for example, dynamic process management (SC_SPAWN), semaphores and mutual exclusions (mutex), FIFOs (First In First Out) and the management of sensitivity lists and events.
  • SC_SPAWN dynamic process management
  • FIFOs First In First Out
  • special units for the exchange of data between processes are used to store the values of the signals.
  • the purpose of the invention is to accelerate any type of SystemC simulation described in a C or C ++ language using the standard SystemC and TLM libraries without any modification.
  • the invention proposes a hardware acceleration of the SystemC kernel capable of distributing the set of processes dynamically over a plurality of calculation units.
  • the subject of the invention is a device for accelerating, on a platform comprising a plurality of processing units, the execution of a SystemC simulation of a system, said simulation comprising a SystemC core and SystemC processes.
  • the device includes a hardware running unit of the SystemC kernel scheduling the SystemC processes on the processing units dynamically during execution of the simulation.
  • C scheduling the SystemC processes preempts the processing units, so that if a first SystemC process executed by a processing unit is blocked pending synchronization with a second SystemC process, then said processing unit is preempted, said a processing unit saving its execution context in a memory shared by the processing units and starting the execution of another SystemC process, the execution of the first process being resumed later.
  • the simulated system can be described at the RTL level or at the TLM level.
  • the hardware unit for scheduling the SystemC processes may include means for executing the SystemC kernel. It may also include means for managing events, which means may include a list of all the events that can be generated associated with identifiers of the SystemC processes responsive to said events. It may also include ways to manage time, which may include a watchdog for each of the SystemC processes.
  • the means for executing the SystemC kernel may include a RISC processor to execute the instructions forming the SystemC kernel.
  • the means for executing the SystemC kernel may also include a dependency graph between the SystemC processes, so as to activate child processes as soon as their respective parent processes have been executed.
  • the time management means may include a counter providing a current simulated time. They may also include a memory containing a list of simulated times to be achieved by each of the processes running on the processing units. They may also include a memory containing a list of the states of each of the processes running on the processing units, which state that the process is active or pending. They may also include means for comparing the current simulated time with the simulated times to be achieved by each of the processes. The state of a process can then switch from the active state to the waiting state as soon as the current simulated time has reached the simulated time to reach associated with said process.
  • the means for managing events may include a memory containing a list of event identifiers. They may also include a memory containing, for each event identifier, the address in another memory of a list of processes responsive to said event.
  • the main advantages of the invention are that it supports transactional communications and allows the acceleration of SystemC simulations at a high level of abstraction. It also proposes means of debugging and trace for the validation of the model or the application executed.
  • the main advantages of the invention are that it offers a fast and very flexible time model, integrating into any development or design environment. It offers software and hardware developers an ideal solution for designing complex systems. This has a very important impact on development times and is a major advantage for competitiveness.
  • FIG. 3 a diagram, an illustration of an exemplary embodiment of a time management unit according to the invention.
  • FIG. 4 by a diagram, an illustration of an exemplary embodiment of an event management unit according to the invention.
  • FIG. 5 by a diagram, an example of scheduling of System C processes on a plurality of computing resources
  • FIG. 6 a diagram, an illustration of an exemplary embodiment of the invention on a computing server accessible via an Ethernet network.
  • the invention notably includes a hardware environment capable of accelerating SystemC simulations at varying levels of abstraction, be it RTL, TLM or even TLM with consideration. temporal information, complex digital and analog systems, as well as their software and hardware parts.
  • This hardware environment consists of a plurality of computing processors capable of executing SystemC processes, of at least one hardware acceleration unit of the SystemC kernel in charge of dynamically scheduling the execution of the SystemC processes, of memories, I / O to emulate the simulated system's I / O, as well as debugging and trace means.
  • These hardware acceleration units have access to an event management unit linking the sensitive processes to select the processes to be executed, as well as to a time management unit to manage all the time synchronizations present in SystemC that govern the competition between the processes, and a process dependency graph to determine a partial order of scheduling and to minimize the number of context changes.
  • FIG. 1 diagrammatically illustrates an exemplary implementation of the invention in a multiprocessor environment.
  • the hardware environment includes a plurality of calculation units P1 to Pn controlled by an HWSKS hardware unit according to the invention (Hardware SystemC Kernel Sequencing), this HWSKS unit for controlling the processes handled by the SystemC kernel.
  • HWSKS hardware unit Hardware SystemC Kernel Sequencing
  • This so-called asymmetric architecture has the advantage of explicitly separating the control, that is to say the execution of the SystemC kernel by the HWSKS unit, and the calculation, ie the evaluation of the SystemC process by the processors P1 to Pn.
  • the computing units P1 to Pn are processors capable of executing the SystemC processes.
  • Each calculation unit P1 to Pn is accompanied by a control interface CTRLJF for communicating with the HWSKS unit via a control bus and a TLB unit for translating the cache memories to access the contents of the shared memories.
  • the calculation units P1 to Pn are connected via an interconnection network, a multibus for example, to different memories as well as to an I / O unit for input / output management (I / O Management).
  • a SystemC Processes Context (SPC) memory saves contexts of different active SystemC processes. It is shared by the processors P1 to Pn.
  • SystemC Processes / Local Data stores code related to SystemC processes, such as instructions, local variables, and constants.
  • Shared Data Memory SDM is used to store shared data between SystemC processes such as global variables and constants.
  • SM System Memory
  • a Memory Configuration and Management Unit (MCMU) is used to transfer the code of the SystemC processes to initialization, and to dynamically manage access to the shared memories.
  • This unit is used to manage the pagination and translations associated with the codes of the SystemC processes and their context, as well as the dynamic allocation of memory space in the shared memory.
  • the HWSKS control unit allows hardware execution of the SystemC kernel.
  • FIG. 2 diagrammatically illustrates an exemplary embodiment of the HWSKS unit according to the invention, which supports the execution of the SystemC kernel. It takes into account a dependence graph between processes to determine their activation order, this graph is not shown in Figure 2.
  • the HWSKS unit has an Event Tag Unit (ETU) which has a list of all the events that can be generated associated with the numbers of the processes to be activated on occurrence of these events.
  • the ETU can be a functional equivalent to a search and memory paging block used in event management.
  • the HWSKS unit also has a WTU Watchdog Tag Unit that has a watchdog for each process and allows reference to process waiting for synchronization and evaluate long synchronization expectations. The WTU unit thus avoids unnecessary process awakening.
  • the WTU unit makes it possible to execute more treatments in parallel.
  • the HWSKS unit then uses this information to activate the processes and distribute their execution on the calculation units P1 to Pn, via the control bus of FIG. 1 for example.
  • the time management is carried out explicitly: the waiting times can be defined, pauses can be programmed in the execution of the processes.
  • the scheduling of the processes is done dynamically, that is to say during the execution of the simulation.
  • a process allocated on a calculation unit among P1 to Pn may be pre-empted or migrated to another calculation unit from P1 to Pn if the HWSKS unit decides.
  • a SystemC TM timer manager (Timer Management) allows each process to have access to the current simulation time and allows the SystemC kernel to schedule its processes over time.
  • the HWSKS control unit may be a programmable structure comprising, in addition to the ETU and WTU hardware units, a SystemC Kernel Evaluation (SKE) module including for example a RISC (Reduced Instruction) processor. Set Computer), so that the SKE module can execute the SystemC kernel code.
  • SKE SystemC Kernel Evaluation
  • the SKE module also uses a process dependency graph, which is a data structure organized as a linked list. In this list, each process has parent processes and child processes. When the parent processes have been evaluated, the child processes are activated.
  • the SKE module can dispense with a task of monitoring the dates of event triggering: indeed, the unit WTU performs autonomous time management.
  • FIG. 3 illustrates an embodiment of the WTU unit comprising two memories WTU_M0 and WTU_M1, as well as a set of comparators represented by symbols " ⁇ " and a clock TT.
  • the clock TT can be a Current_sc_time hardware counter that represents the current SystemC time, which will be called “simulated time” later. This counter is incremented at each simulation step, once all processes have been evaluated and the ETU is empty.
  • the SKE processor can access this memory WTU_M1 to check the status of the processes. If the contents of the memory are positive (1), the process is considered as pending. Otherwise (0), the process is considered active.
  • FIG. 4 illustrates an embodiment of the ETU unit comprising three memories ETU_M0, ETU_M1 and ETU_M2.
  • the memory ETU_M0 makes it possible to store the identifiers of events of the type evn, which are generated during the evaluation of the processes.
  • the memory ETU_M1 is a memory of which each line contains a word comprising two fields. The first field is an event identifier, of the type evn in FIG. 4, and the second field is an address in a memory ETU_M2, of the type @processus_listm in FIG. 4, of a list of processes PR1 to PRn sensitive to this event evn.
  • the memory ETU_M2 thus contains lists of processes and the addresses of the type @processus_listm specified in the memory ETU_M1 are pointers on boxes of the memory ETU_M2. These three memories ETU_M0, ETU_M1 and ETU_M2 thus make it possible, starting from an event, to quickly find all the sensitive processes, in order to be able to activate them later. Thus, for each of the events, all the sensitive processes on this event are activated. When all the processes of an evn event in ETU_M0 have been activated, the corresponding event is removed from the memory ETU_M0. Once all events deleted from ETU_M0, the ETU is considered empty.
  • the user loads in the HWSKS unit the dependency graph between the processes, as well as all the codes related to the processes in the SP / LD memory.
  • the HWSKS unit then starts its execution cycle following the operation of the SystemC kernel and executes all the processes in parallel according to the availability of the calculation units P1 to Pn. All processes are then initialized and executed until they meet a synchronization. Some will then update their output signals or send transactions to other processes. In the latter case, according to the TLM standard, the so-called "transport" functions of the target processes concerned are executed until their evaluation is complete.
  • the HWSKS unit will only have the role of equitably distributing the different processes between the calculation units P1 to Pn.
  • the TM clock manager increments the SystemC clock according to the simulation step. Then, according to the dependency graph between the active processes, the HWSKS unit again evaluates the processes that are no longer waiting in the WTU unit by optimizing the distribution of the load of the calculation units P1 to Pn. This process takes place until the end of the simulation.
  • a major advantage of this invention lies in its ability to dynamically schedule processes on the different homogeneous calculation units P1 to Pn. This capacity is made possible thanks to the complementarity of the elements constituting the invention.
  • To allow the preemption and the migration of the processes between the units of computation P1 to Pn it is necessary first of all to have a scheduling algorithm able to take such decisions which is executed by the control unit HWSKS by the intermediate of its RISC processor. This algorithm can therefore simply, depending on the duration of execution of the processes or their activity, decide on the preempt, to run them later on an identical or different processor. As shown in Figure 5, assume for example that the PR1 process is evaluated on the processor P3.
  • PR1 waits for a synchronization with another PR6 process (being evaluated or not), the process PR1 is blocked and the processor P3 is then underused.
  • the invention proposes to interrupt PR1 until it is no longer blocked, to execute another process, for example PR3, which will not be blocked.
  • the processor executes the command
  • the processor saves its context in the SPC shared memory. This memory is accessible and shared between all the processors via the interconnection network, the multibus in the present embodiment.
  • the HWSKS control unit wishes to resume the execution of the PR1 process, it may arbitrarily assign it a free processor so that it can continue its evaluation, the processor may be the previously preempted processor or any other processor among P1 to Pn.
  • FIG. 6 illustrates in a diagram another embodiment, integrating on an emulation card installed in a computing server accessible to a set of clients via an Ethernet network several hardware acceleration environments SystemC according to the invention.
  • the user can run the simulator via his work environment and development tools. With a particular client-server interface, the simulator can be run on a remote emulation board and all debugging and trace information related to the user interface can be redirected to the client. Thus, the user has the impression of running the simulator locally while he is running on a remote system.
  • the remote system may be a compute server having one or more accelerator cards, each capable of accommodating one or more SystemC acceleration modules.
  • Each SystemC acceleration module may consist of an architecture similar to that previously presented, with in addition a debugging and tracing unit capable of transferring all necessary information to the development tools used by the user.
  • Other advantages :
  • the invention described above provides a means to accelerate the simulations and a support to significantly reduce design time. Indeed, the ability to quickly emerge a new system in the embedded electronics market is directly related to the competitiveness and penetration and success factor of the commercial product.
  • the problem of managing the calculation time is solved in a material way by a set of hardware means to improve the speed of execution of a SystemC simulation.
  • the hardware devices implemented according to the invention make it possible to save computing time on the execution of the core

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

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.

Description

Dispositif pour accélérer l'exécution d'une simulation SystemC
Domaine technique :
La présente invention concerne un dispositif 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 cœurs 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 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 impose 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, nommé Open SystemC Initiative (OSCI), a développé un nouveau standard international (IEEE Std. 1666™-2005) appelé SystemC qui est aujourd'hui très largement utilisé dans le monde entier. SystemC est une librairie C++ associée à un moteur de simulation, capable de combler ces manques et de transformer le langage C et C++ en langage de description matériel. 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 ê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 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 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 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 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.
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.
Dans des demandes de brevet chinois CN101634979,
CN101315648, CN101329702, CN101635006, CN101770362 et CN101 196826 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 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 FIFO (First In 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. De manière générale, la gestion des processus usuellement réalisée par des simulations reposant sur le langage SystemC est très contraignante et très gourmande en temps de calcul.
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 une unité matérielle d'exécution du noyau SystemC ordonnançant les processus SystemC sur les unités de traitements de manière dynamique pendant l'exécution de la simulation.
Avantageusement, l'unité matérielle d'exécution du noyau System
C ordonnançant les processus SystemC permet 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, l'unité matérielle pour ordonnancer les processus SystemC peut inclure des moyens pour exécuter le noyau SystemC. Elle peut é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. Elle peut 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 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. 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 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.
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.
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é.
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 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;
- 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;
- 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 :
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 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 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.
La figure 1 illustre par un diagramme un exemple de mise en œuvre 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 les processus manipulés par le 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 des processeurs capables d'exécuter les processus SystemC. Chaque unité de calcul P1 à Pn est accompagnée d'une interface de contrôle CTRLJF 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 d'interconnexion, un multibus par exemple, à différentes mémoires ainsi qu'à une unité l/OM de gestion des entrées-sorties (I/O 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 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 partagées. 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.
Dans la suite de la présente demande, le terme « processus >> est utilisé pour désigner implicitement des processus SystemC.
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 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é ETU peut être un équivalent fonctionnel à un bloc de recherche et de pagination mémoire, utilisée dans le cadre d'une gestion des événements. L'unité HWSKS comporte également une unité WTU de gestion du temps (Watchdog Tag Unit) qui possède un chien 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. Avantageusement, l'unité WTU permet d'exécuter plus de traitements en parallèle. 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 Figure 1 par exemple. Ainsi la gestion du temps est réalisée de manière explicite : les temps d'attente peuvent être définis, des pauses peuvent programmées dans l'exécution des processus.
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 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 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. Avantageusement, le module SKE peut s'affranchir d'une tâche de surveillance des dates de déclenchements des événements : en effet, l'unité WTU réalise une gestion du temps autonome.
La figure 3 illustre un mode de réalisation de l'unité WTU comportant deux mémoires WTU_M0 et WTU_M1 , ainsi qu'un ensemble de comparateurs représentés par des symboles "<" et une horloge TT. L'horloge 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_M0 contient, pour chacun des processus PR1 à PRn, le temps simulé à atteindre 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 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_M0 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 @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_M0 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 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 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 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. 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 liée à la compétitivité et au facteur de pénétration et de réussite du produit commercial.
Dans l'invention, le problème de gestion du temps de calcul est résolu de manière matérielle par un ensemble de moyens matériels permettant d'améliorer la rapidité d'exécution d'une simulation SystemC.
Notamment, la répartition des processus SystemC sur plusieurs processeurs permet d'en paralléliser l'exécution, accélérant ainsi de manière significative la simulation SystemC.
Avantageusement, les dispositifs matériels mis en place selon l'invention permettent de gagner du temps de calcul sur l'exécution du noyau
SystemC pour l'allouer aux applications elles-mêmes.

Claims

REVENDICATIONS
1 . 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 une unité matérielle (HWSKS) d'exécution du noyau SystemC ordonnançant les processus SystemC sur les unités de traitements de manière dynamique pendant l'exécution de la simulation.
2. Dispositif selon la revendication 1 , caractérisé en ce que l'unité matérielle (HWSKS) d'exécution du noyau System C ordonnançant es processus systemC permet 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. 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. Dispositif selon la revendication 2, caractérisé en ce que l'unité matérielle (HWSKS) d'exécution du noyau SytemC ordonnaçant les processus SystemC inclue:
- 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. 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. 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. 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_M0) 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 ) dès lors que le temps simulé courant a atteint le temps simulé à atteindre associé audit processus.
8. Dispositif selon la revendication 4, caractérisé en ce que les moyens (ETU) pour gérer des événements incluent:
- une mémoire (ETU_M0) contenant une liste d'identifiants d'événements (evn);
- une mémoire (ETU_M1 ) contenant, pour chaque identifiant d'événement {evri), l'adresse {@processus_listm) dans une autre mémoire (ETU_M2) d'une liste des processus sensibles audit événement.
PCT/EP2012/052386 2011-02-15 2012-02-13 Dispositif pour accélérer l'exécution d'une simulation system c WO2012110445A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/984,525 US9612863B2 (en) 2011-02-15 2012-02-13 Hardware device for accelerating the execution of a systemC simulation in a dynamic manner during the simulation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1151223 2011-02-15
FR1151223A FR2971596B1 (fr) 2011-02-15 2011-02-15 Dispositif pour accelerer l'execution d'une simulation systemc

Publications (1)

Publication Number Publication Date
WO2012110445A1 true WO2012110445A1 (fr) 2012-08-23

Family

ID=45855711

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/052386 WO2012110445A1 (fr) 2011-02-15 2012-02-13 Dispositif pour accélérer l'exécution d'une simulation system c

Country Status (3)

Country Link
US (1) US9612863B2 (fr)
FR (1) FR2971596B1 (fr)
WO (1) WO2012110445A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3002342B1 (fr) * 2013-02-15 2015-02-27 Commissariat Energie Atomique Dispositif et procede pour accelerer la phase de mise a jour d'un noyau de simulation
US9817771B2 (en) * 2013-08-20 2017-11-14 Synopsys, Inc. Guarded memory access in a multi-thread safe system level modeling simulation
US9778817B2 (en) 2013-12-31 2017-10-03 Findo, Inc. Tagging of images based on social network tags or comments
US10445445B2 (en) * 2016-04-22 2019-10-15 Synopsys, Inc. Sliding time window control mechanism for parallel execution of multiple processor core models in a virtual platform simulation
US20240012629A1 (en) * 2022-07-11 2024-01-11 Xilinx, Inc. Compiler-based generation of transaction accurate models from high-level languages

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101196826A (zh) 2007-12-29 2008-06-11 中国科学院计算技术研究所 满足SystemC语法要求的多核处理器及获得其执行代码的方法
CN101315648A (zh) 2008-07-22 2008-12-03 中国科学院计算技术研究所 一种满足systemC语法的多核处理器的事件处理单元组
CN101329702A (zh) 2008-07-22 2008-12-24 中国科学院计算技术研究所 一种满足SystemC语法的多核处理器的先进先出队列单元组
CN101634979A (zh) 2008-07-22 2010-01-27 中国科学院计算技术研究所 一种满足SystemC语法的多核处理器
CN101635006A (zh) 2008-07-22 2010-01-27 中国科学院计算技术研究所 一种满足SystemC语法的多核处理器的互斥和信号量单元组
CN101770362A (zh) 2009-01-06 2010-07-07 中国科学院计算技术研究所 满足SystemC的处理器中的分布式动态进程生成单元

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003441B2 (en) * 2001-07-31 2006-02-21 Hewlett-Packard Development Company, L.P. Method for deriving the benchmark program for estimating the maximum power consumed in a microprocessor
US20050229170A1 (en) * 2004-04-08 2005-10-13 Matthew Bellantoni Optimized system-level simulation
US7567893B2 (en) * 2004-12-30 2009-07-28 Vast Systems Technology Corporation Clock simulation system and method
JP2008059192A (ja) * 2006-08-30 2008-03-13 Oki Electric Ind Co Ltd ハード・ソフト協調検証用シミュレータ
US8296741B1 (en) * 2007-03-05 2012-10-23 Google Inc. Identifying function-level code dependency by simulating runtime binding
US7957950B2 (en) * 2008-02-28 2011-06-07 Oki Semiconductor Co., Ltd. Hard/soft cooperative verifying simulator
EP2257874A4 (fr) * 2008-03-27 2013-07-17 Rocketick Technologies Ltd Simulation de conception utilisant des processeurs parallèles
JP5066013B2 (ja) * 2008-06-24 2012-11-07 富士通セミコンダクター株式会社 シミュレーション装置およびプログラム
US8156458B2 (en) * 2008-08-29 2012-04-10 International Business Machines Corporation Uniquification and parent-child constructs for 1xN VLSI design
JP5262774B2 (ja) * 2009-02-03 2013-08-14 富士通株式会社 シミュレーション制御プログラム、シミュレーション装置、およびシミュレーション制御方法
JP2012509546A (ja) * 2009-12-23 2012-04-19 インチロン ゲーエムベーハー 組み込みシステムをシミュレートするための方法及びデータ処理システム
US20110307847A1 (en) * 2010-06-10 2011-12-15 Global Unichip Corporation Hybrid system combining TLM simulators and HW accelerators
US8458630B1 (en) * 2010-06-26 2013-06-04 Cadence Design Systems, Inc. Supporting dynamic aspects of polymorphism in high-level synthesis of integrated circuit designs
US9015649B2 (en) * 2010-07-19 2015-04-21 Taiwan Semiconductor Manufacturing Co., Ltd. Method and apparatus for electronic system model generation
US20120197625A1 (en) * 2011-01-28 2012-08-02 National Tsing Hua University Data-dependency-Oriented Modeling Approach for Efficient Simulation of OS Preemptive Scheduling

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101196826A (zh) 2007-12-29 2008-06-11 中国科学院计算技术研究所 满足SystemC语法要求的多核处理器及获得其执行代码的方法
CN101315648A (zh) 2008-07-22 2008-12-03 中国科学院计算技术研究所 一种满足systemC语法的多核处理器的事件处理单元组
CN101329702A (zh) 2008-07-22 2008-12-24 中国科学院计算技术研究所 一种满足SystemC语法的多核处理器的先进先出队列单元组
CN101634979A (zh) 2008-07-22 2010-01-27 中国科学院计算技术研究所 一种满足SystemC语法的多核处理器
CN101635006A (zh) 2008-07-22 2010-01-27 中国科学院计算技术研究所 一种满足SystemC语法的多核处理器的互斥和信号量单元组
CN101770362A (zh) 2009-01-06 2010-07-07 中国科学院计算技术研究所 满足SystemC的处理器中的分布式动态进程生成单元

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
A. GUERRE: "Approche hiérarchique pour la gestion dynamique des tâches et des communications dans les architectures massivement parallèles programmables", 24 September 2010 (2010-09-24), Université Paris-Sud 11, France, pages I - 150, XP002663625, Retrieved from the Internet <URL:http://nventrou.free.fr/thesis/these_aguerre.pdf> [retrieved on 20111114] *
C. BECHARA ET AL: "A TLM-based Multithreaded Instruction SetSimulator for MPSoC Simulation Environment", January 2011 (2011-01-01), pages 1 - 7, XP002663624, Retrieved from the Internet <URL:http://nventrou.free.fr/papers/RAPIDO2011_CB.pdf> [retrieved on 20111114] *
NICOLAS VENTROUX ET AL: "SCMP architecture: An Asymmetric Multiprocessor System-On-Chip for Dynamic Applications", PROCEEDINGS OF THE SECOND INTERNATIONAL FORUM ON NEXT-GENERATION MULTICORE/MANYCORE TECHNOLOGIES, IFMT '10, 19 June 2010 (2010-06-19), New York, New York, USA, pages 1 - 12, XP055012079, ISBN: 978-1-45-030008-7, DOI: 10.1145/1882453.1882461 *
VENTROUX N ET AL: "SESAM: An MPSoC Simulation Environment for Dynamic Application Processing", COMPUTER AND INFORMATION TECHNOLOGY (CIT), 2010 IEEE 10TH INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 29 June 2010 (2010-06-29), pages 1880 - 1886, XP031757603, ISBN: 978-1-4244-7547-6 *

Also Published As

Publication number Publication date
FR2971596A1 (fr) 2012-08-17
US20140325516A1 (en) 2014-10-30
FR2971596B1 (fr) 2016-01-01
US9612863B2 (en) 2017-04-04

Similar Documents

Publication Publication Date Title
CN107733977B (zh) 一种基于Docker的集群管理方法及装置
EP1337919B1 (fr) Procede de securisation rendant deterministe l&#39;execution en temps reel d&#39;applications multitaches du type controle-commande avec confinement d&#39;erreur
CN111258744A (zh) 一种基于异构计算的任务处理方法及软硬件框架系统
EP3777086A1 (fr) Procédé de gestion d&#39;état de configuration d&#39;application à l&#39;aide de techniques de gestion d&#39;application en nuage
EP0536010B1 (fr) Procédé et dispositif pour la gestion temps réel d&#39;un système comprenant au moins un processeur apte à gérer plusieurs fonctions
EP2257876B1 (fr) Methode de prechargement dans une hierarchie de memoires des configurations d&#39;un systeme heterogene reconfigurable de traitement de l&#39;information
US10248581B2 (en) Guarded memory access in a multi-thread safe system level modeling simulation
WO2012110445A1 (fr) Dispositif pour accélérer l&#39;exécution d&#39;une simulation system c
US9075666B2 (en) Deferred execution in a multi-thread safe system level modeling simulation
US10585648B2 (en) Systems and methods for aggregating implicit and explicit event code of executable models
FR2964225A1 (fr) Procede et dispositif de deploiement et d&#39;aide au deploiement de composants formant un systeme temps reel embarque
US9201708B2 (en) Direct memory interface access in a multi-thread safe system level modeling simulation
WO2016207249A1 (fr) Procédé implémenté par ordinateur permettant d&#39;exécuter des simulations au niveau de système électronique en parallèle
EP3494475B1 (fr) Procede et dispositif de distribution de partitions sur un processeur multi-coeurs
CN115686805A (zh) Gpu资源共享的方法和装置、调度gpu资源共享的方法和装置
Denninnart et al. Efficiency in the serverless cloud paradigm: A survey on the reusing and approximation aspects
EP3923133A1 (fr) Systèmes et procédés permettant de générer des points d&#39;accès au service pour les services rte en code ou d&#39;autres informations de service rte à utiliser avec le code
EP2956874B1 (fr) Dispositif et procédé pour accélérer la phase de mise à jour d&#39;un noyau de simulation
CA2887077C (fr) Systeme de traitement de donnees pour interface graphique et interface graphique comportant un tel systeme de traitement de donnees
US12001382B2 (en) Methods, apparatus, and articles of manufacture to generate command lists to be offloaded to accelerator circuitry
FR2991074A1 (fr) Procede, dispositif et programme d&#39;ordinateur de controle dynamique de distances d&#39;acces memoire dans un systeme de type numa
Pierfederici Distributed Computing with Python
US8745620B2 (en) Software tool and method for updating a virtual appliance
Otterness Developing real-time GPU-sharing platforms for artificial-intelligence applications
De Munck et al. Design and performance evaluation of a conservative parallel discrete event core for GES

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12709542

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13984525

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12709542

Country of ref document: EP

Kind code of ref document: A1