FR3103595A1 - Fast simulator of an ECU and software implemented by this ECU - Google Patents

Abstract

Rapid simulator of a calculator and of software implemented by this calculator, the calculator comprising at least one processor, a memory hierarchy comprising several levels of cache memories, external memories and a network of interconnections ensuring communication between the cache memories and external memories; the simulator comprising a plurality of co-simulators respectively associated with a task, and being configured to operate by quantum of instructions, a so-called functional co-simulator (CSF) being configured to operate the simulated software while ignoring the architecture of the calculator, at least one other so-called architectural co-simulator (CSAi) being configured to simulate, in parallel, the architectural behavior linked to the architecture of the calculator and determine the values of extra-functional parameters of the calculator, and a transfer module (MT) configured to transfer an event reported by the functional co-simulator (CSF) to an architectural co-simulator (CSAi) subscribed to this event. Figure for abstract: Fig. 5

Description

Fast simulator of a computer and software implemented by this computer

The invention relates to a fast simulator of a computer and to software implemented by this computer, and to a corresponding method.

A conventional computer comprises one or more calculation units or processors, a memory hierarchy comprising several levels of cache memories (high-performance computers typically include three levels of cache memories), external memories (called RAM for the acronym of "Random Access Memory " in English) and an interconnection network (NoC for acronym of "Network-on-Chip" in English), ensuring communication between the caches and the external memories. Such computers can also include a certain number of peripherals, such as serial controllers, hard disks, or PCI peripherals (for acronym for "Peripheral Component Interconnect" in English.

In order to accelerate the development of such ECUs, rapid virtual prototypes are often made in the early design phases, which can reduce the time to market or "time-to-market" in the English language, mainly in the two ways that follow.

It is possible to make architectural decisions: the virtual prototype can model the critical parts of the computer's architecture, such as the cache memories, and to test different operating modes and different capacities in order to size these elements correctly for the final structure.

It is also possible to use software development: with a faithful model of the processor, software can be developed, debugged and tested even before the physical platform is available, making it possible to parallelize hardware and software designs.

For a virtual prototype to be useful, two conditions must be met:
- It must be available early, and therefore able to be developed quickly. The models developed are therefore often quite abstract and non-detailed.
- It must be fast, because the designer must be able to perform several iterations and test different configurations quickly.

The speed of the virtual prototype is characterized by the speed at which it is able to run the simulated software. Typically, modern simulators are capable of simulating several hundred million instructions per second (MIPS).

A technique very often adopted to fulfill these two conditions is so-called vaguely timed modeling or "loosely-timed" in English. This method models the various components (peripherals, memories) in a fairly abstract way, reducing both development time and design time.

The loosely-timed modeling, schematically illustrated in Figure 1, operates as follows.

The simulator hands over control to one of the system's processors for a quantum of instructions.

Throughout the duration of the quantum, the processor executes instructions without giving control back to the simulator. This reduces the number of simulator context switches, and significantly improves simulation performance.

The processor model interprets the simulated software instructions.

These instructions can be arithmetic instructions ALU_instr() for Arithmetic and Logic Unit instruction, which can be simulated very quickly (typically using simple operators), input/output access instructions IO_access(), which can be simulated slowly ( typically using system calls), but which are rare, and finally RAM_access() memory access instructions, which generate transactions to the cache memory, external memory and NoC network models to simulate memory access.

Each element traversed during the processor quantum updates the local processor clock by adding its own latency. For example, as shown in Figure 1, the first level cache memory L1 Cache takes two cycles, so two cycles are added (T+=2) to the local time T of the processor.

In the example shown, the execution of each instruction takes one cycle.

We can see in Figure 1 that the simulation time can quickly become problematic. Indeed, the number of memory accesses in a classical program can be very large, and constantly switching between interpreting instructions and simulating the memory hierarchy has a serious impact on the locality of the simulator code. The locality of the code corresponds to the fact of executing the same pieces of code several times during the execution of the simulator.

Indeed, if the interpreter often visits the same simple areas of code, a large part of the executed instructions may remain in cache, which is desirable for smooth execution. However, by making transitions between instructions of the instruction interpreter and the models of cache memories, NoC communications networks and external RAM memories, which can be quite complex, one obtains the undesirable effect of severely reducing this locality.

Given the severity of this problem, several solutions have been proposed as follows.

Document US 2018/0173825 A1 discloses an approach consisting in parallelizing the simulation, by simulating each processor in a single execution task, or "thread". This allows to have significant speedups when the number of simulated cores is large, typically greater than 16. However, this approach does not address the performance problem due to the simulation of memory accesses exposed previously. Also, for the simulation of a classic embedded system, having between four and eight calculation cores, this approach does not produce any acceleration.

Mutli-threaded TCG (Tiny Code Generator) document approaches", Bellard, F. (2005, April), QEMU, a fast and portable dynamic translato, inUSENIX Annual Technical Conference, FREENIX Track(Vol. 41, p. 46) , and "QEMU and SystemC in separate threads", by Delbergue, G., Burton, M., Konrad, F., Le Gal, B., & Jego, C. (2016, January), QBox: an industrial solution for virtual platform simulation using QEMU and SystemC TLM-2.0, in8th European Congress on Embedded Real Time Software and Systems (ERTS 2016), aim to speed up simulations as much as possible by emphasizing code locality. not interrupt the execution of the processor during a quantum, the memory accesses are translated by simple accesses to the RAM memory of the host machine (machine executing the simulation).Of course, this does not allow to have a sufficiently detailed prototyping to be able to size the memory elements correctly, because the memory hierarchy is entirely neglected during the simulation. These approaches also employ spatial parallelism as described previously, where each core is executed in the context of a separate task.

Another approach is to adopt a parallelization that is not spatial, but temporal. The basic idea is to perform the same simulation in two layers: a functional layer that serves to drive the simulator forward, and a temporal layer that serves to model the temporal behavior of different parts of the system. The following documents implement such a realization: "Trace Driven Virtual Synchronization", by Yun, D., Kim, S., & Ha, S. (2012), A parallel simulation technique for multicore embedded systems and its performance analysis ,IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems,31(1), 121-13; "Graphite: Distributed Parallel Multicore Simulator", by Miller, J. E., Kasture, H., Kurian, G., Gruenwald, C., Beckmann, N., Celio, C., ... & Agarwal, A. (2010, January), Graphite: A distributed parallel simulator for multicores, InHPCA-16 2010 The Sixteenth International Symposium on High-Performance Computer Architecture(pp. 1-12). IEEE; "TQSim: Cycle-approximate processor simulator based on QEMU", by Kang, S. H., Yoo, D., & Ha, S. (2016), "TQSIM: A fast cycle-approximate processor simulator based on QEMU".Journal of Systems Architecture,66, 33-47; and "GreenSoCs: Gathering Memory Hierarchy Statistics in QEMU" by Clement Deschamps, Frédéric Pétrot, Mark Burton, Eric Jenn, DVCon 2019.

TQSim uses the QEMU emulator for a functional execution of the simulated software, without any information on the time due to the different architectural aspects (memories, processors). This time is calculated by a separate simulator which models these aspects more precisely.

TQSim simulates the memory hierarchy in the same context as the functional simulation, which in the case of complex hierarchies can be very problematic in terms of performance, as explained before.

Other aspects of the processor, such as pipeline and branch predictor, are simulated in a separate task, hiding their impact on simulation speed.

As the TQSim approach is based on the sampling of the executed instructions, i.e., only a part of the instructions is instrumented at the beginning of each quantum, the memory and processor models must be analytical models representing in an abstract way the characteristics of the different components.

The GreenSoCs approach aims to simulate the memory hierarchy in parallel with a functional simulator. A functional simulator is a simulator configured to operate the simulated software, disregarding the architecture of the computer.

Architectural behavior means any action of the simulated computer aimed at reproducing a behavior of the real computer that does not impact the logical operation of the simulated software, but the extra-functional characteristics, such as performance or energy consumption. For example, caches do not change how a program works, but can improve its performance.

A critical point in these last two approaches TQSim and GreenSoCs is that the simulated software never perceives the impact of the different modeled subsystems in the temporal context. Thus, the temporal context is the single point of truth of the simulation, contrary to the approach that we propose, where the simulated software has a correct view of the time and the state of execution, taking into account the extra-functional aspects simulated in other tasks.

An object of the invention is to overcome the problems cited above.

Also, there is proposed, according to one aspect of the invention, a fast simulator of a computer and of software implemented by this computer, the computer comprising at least one processor, a memory hierarchy comprising several levels of cache memories , external memories and an interconnection network providing communication between the cache memories and the external memories. The simulator comprises a plurality of co-simulators respectively associated with a task (thread), and is configured to operate by quantum of instructions, a so-called functional co-simulator being configured to operate the simulated software by disregarding the architecture of the computer, at least one other so-called architectural co-simulator being configured to simulate, in parallel, the architectural behavior linked to the architecture of the computer and to determine the values of extra-functional parameters (or simulation results) of the computer, and a forwarding module configured to forward an event signaled by the functional co-simulator to an architectural co-simulator subscribed to this event.

Such a simulator makes it possible to envisage simulations comprising both a fluid and functionally faithful execution of the simulated software, and a detailed and timed reproduction of all the architectural components of the simulated computer. Traditionally, only one of two modes is possible: fast simulation without architectural details, or precise but very slow simulation. The proposed simulator separates the architectural co-simulators from the functional co-simulator to facilitate the integration of new co-simulators, modeling new architectural details, into an existing simulator. The proposed simulator systematically takes into account the states of the architectural co-simulators within the functional co-simulator, so that the software has an up-to-date view of the state of the computer.

In one embodiment, the extra-functional parameters of the computer include processor cycle times, and/or energy, and/or reliability.

Thus the simulator can be used not only to validate the operation of software, but also to optimize it in terms of performance, energy or reliability, taking into account all architectural aspects.

According to one embodiment, the architectural behavior comprises parameters representative of the architecture of the computer.

For example, the parameters representative of the architecture of the computer include a number of cache and external memory accesses of the computer, and/or the communications of the interconnection network.

Thus the user is able to understand the details of the behavior of the computer following the execution of the simulated software.

In one embodiment, each architectural co-simulator is configured to simulate a unique type of event.

Thus it is easy to develop architectural co-simulators simulating different architectural behaviors and at various levels of precision in a separate and modular way. Moreover, since all the architectural co-simulators are decoupled from the main simulator, different characteristics of the architecture can be evaluated simultaneously without impacting the fluidity of the simulation.

According to one embodiment, a simulation being broken down into epochs numbered starting from 0, and an epoch corresponding to at least one quantum, the functional co-simulator is configured to, at the start of an odd epoch, wait for each co- architectural simulator has finished processing the events of the preceding odd epoch, and at the start of an even epoch, wait until each architectural co-simulator has finished processing the events of the preceding even epoch.

Thus the functional simulation emitting events during an epoch is always carried out in parallel with the processing by the co-simulators of the events emitted during the previous epoch, thus guaranteeing an optimal use of parallelism.

In one embodiment, the simulator comprises two copies of the state of an architectural co-simulator, a so-called even copy S'(i) for an even epoch and a so-called odd copy S''(i) for an epoch odd, the state S(i) of an architectural co-simulator comprising the parameters representative of the architecture of the computer, in which:
- an architectural co-simulator is configured to write in the even copy S'(i) during an even epoch and to write in the odd copy S''(i) during an odd epoch, and
- the functional co-simulator CSF is configured to read then reset the even copy S'(i) between the end of an odd epoch and the start of the next even epoch, and to read then reset the odd copy S'' (i) between the end of an even epoch and the start of the next odd epoch.

Thus when the functional co-simulator begins an odd epoch, it can read and reset the odd states S''(i) of the architectural co-simulators without having to block the execution of the architectural co-simulators, which write in parallel in their even state S'(i).

According to one embodiment, an epoch corresponds to a single quantum.

There is also proposed, according to another aspect of the invention, a method for rapid simulation of a computer and of software implemented by this computer, the computer comprising at least one processor, a memory hierarchy comprising several levels of cache memories, external memories and a network of interconnections providing communication between the cache memories and the external memories comprising a plurality of co-simulators respectively associated with a task,
the method operating by instruction quantum, and comprising the steps of:
- simulation of the software by a so-called functional co-simulator, disregarding the architecture of the computer,
- simulation, in parallel, by at least one other so-called architectural co-simulator of the architectural behavior linked to the architecture of the computer and determination of the values of extra-functional parameters of the computer, and
- transfer of an event signaled by the functional co-simulator to an architectural co-simulator subscribed to this event.

The invention will be better understood on studying a few embodiments described by way of non-limiting examples and illustrated by the appended drawings in which:

schematically illustrates a simulator using a loosely-timed modeling of a quantum of instructions for a processor, according to the state of the art;

schematically illustrates a simulator with sequential decoupling between the functional simulation and the architectural simulation, of a system of FIG. 1, according to one aspect of the invention;

schematically illustrates a simulator according to FIG. 2, according to one aspect of the invention;

schematically illustrates a simulator according to two aspects of the invention; And

schematically illustrates a simulator according to one aspect of the invention.

In all of the figures, the elements having identical references are similar.

There are two interests in simulating the models related to the memory hierarchy as in the case of figure 1. On the one hand, it allows to obtain useful statistics on the different components, which is useful for the characterization of the architecture and software. On the other hand, this makes it possible to adjust the time of the simulator, and also the different clocks perceived by the processors by counting the delays due to the simulation of these components. However, these two features in no way require that the models be simulated at the instant the memory access instruction is executed.

Indeed, compared to the example of FIG. 1 of the state of the art, it is possible to defer the simulation of the cache memories, of the NoC interconnection network and of the external memories at the end of the instruction quantum , thus improving the locality within a quantum. This is illustrated in Figure 2. The times due to memory accesses would therefore be added to the end of the quantum, thus ensuring that the time spent executing these instructions is the same in both cases. Also, the statistics will be available at the level of the models at the end of the quantum.

The architectural simulation of the memory hierarchy is replaced by direct memory access (direct_mem_access()).

The invention makes it possible to execute an architectural co-simulator of memory accesses in parallel with the functional simulation of the software simulated by the functional co-simulator.

First, we separate the memory co-simulator (on the right as an example of an architectural co-simulator) from the functional co-simulator of the software simulated on the processor (left). The simulated instructions, as well as the models used to simulate the memory elements, are the same as in the example of figure 2.

Instead of simulating online or continuous memory accesses, as on the left side of Figure 2, memory accesses are translated into two basic operations:
- Direct memory access (direct_mem_access() in figure 3) consisting of completing the memory access by loading or storing the data directly on the target memory space, without simulating the actual behavior of the memory. This can be emulated using Load/Store instructions from the host machine (machine running the simulator), and is nearly instantaneous.
- Notification of memory access (notify() in figure 3) which must imperatively be as fast as possible so as not to disturb the flow of execution of the processor. In figure 3, it consists of a simple writing of an event on a lock-free queue (FIFO). The lock-free FIFO stack does not make system calls and helps ensure efficient insertion. The event written to the queue contains information about the memory access, in this example: the instant when the access took place (time), the identifier of the processor making the access (cpu ), the memory address of the access (addr), the size of the requested data (size), and the type of access (read/write, rd/wr).

The memory co-simulator consumes the events present in the queue one by one, and goes through the different models concerned. A delay T' specific to the memory simulator is updated progressively, in processor cycle times.

At the end of the quantum, this time T' is counted on the local time of the CPU, thus leading to the same state at the end of the quantum as on the left part of figure 2, but with a considerable reduction in the simulation time.

After this simple example, we now detail the general implementation of the present invention to accommodate any architectural co-simulator and ensure maximum parallelism.

The simulator of the invention comprises a functional co-simulator configured to operate the simulated software, disregarding the architecture of the computer. The purpose of the functional co-simulator is to correctly execute the instructions of the simulated software. It must ensure this correct operation in the simplest possible way, disregarding any architectural aspect that would not be directly visible from a functional point of view.

The functional co-simulator has the ability to signal a number of events that occur during execution.

An event can be a read access to memory (load instruction), a branch instruction, etc.

The simulation must include a finite number E of event types. Each event is identified by its type, a unique integer between 0 and E.

Each event comes with its own data structure, including details about the event. For example, when did the event take place, what is the source of the event, etc. This structure may be different depending on the type of event.

The simulator also comprises, in addition to the functional co-simulator, at least one architectural co-simulator configured to simulate, in parallel, the architectural behavior linked to the architecture of the computer and to determine the values of extra-functional parameters of the computer. A unique identifier numbered between 0 and N is associated with each architectural co-simulator. The simulator also comprises a transfer module, or "dispatcher" in English, configured to transfer an event signaled by the functional co-simulator to an architectural co-simulator subscribed to this event.

Each architectural co-simulator i includes:
- a queue of events associated with the architectural co-simulator i denoted EQ(i), a single queue being able to contain several types of events (between 0 and E types). The architectural co-simulator subscribes to the types of events it wants to handle before the simulation begins. This subscription is done with the transfer module, detailed later. The event queue is accessible by the transfer module.
- a state S(i) accessible by the functional co-simulator, comprising:
* a delay dT (additional time spent performing the function of the components simulated by the architectural co-simulator i). If the components simulated by the architectural co-simulator i make it possible to reduce the execution time estimated by the functional co-simulator instead of penalizing it, then dT can be negative. For an architectural co-simulator which does not affect the simulation time (eg a power simulator), dT always remains at 0.
* a number K of counters C(k), k being an integer between 0 and K. These counters are updated during the execution of the architectural co-simulator. Examples of counters include: the number of accesses to a memory, the number of successes, or "hits" in English, in a cache memory, etc. Accessing these counters during execution from the functional co-simulator makes it possible, among other things, to correctly simulate a monitoring unit or "monitoring" in English, of performance PMU for acronym of "Performance Monitoring Unit" in English, present on current processors. Thus, the simulated software can have access to information about the running simulated hardware.
- a procedure F(i) which describes the operation of the component or components simulated by the architectural co-simulator i. This function takes the state S(i), as well as the next event present in the queue EQ(i), and updates the state S(i). A single procedure F(i) can model several architectural components (eg the whole memory hierarchy instead of just one part).

Events reported by the functional co-simulator are forwarded to a forwarding module.

The purpose of the transfer module is to transmit an event to the architectural co-simulators that are subscribed to it. To do this, the transfer module maintains a correspondence ("mapping" in English) between the different types of events, and the architectural co-simulators that are subscribed to them. This mapping can be efficiently implemented using a vector of vectors EM, EM(e) being a vector containing all the architectural co-simulators i which are subscribed to the event type e. More formally, when an event of type e is signaled at the level of the transfer module, the latter inserts the event into EQ(i) for each i in EM(e).

For maximum efficiency, an event type can be associated with each architectural co-simulator, which amounts to simply inserting each signaled event of type e into EQ(e).

The transfer module can be executed in the same context as the main simulator synchronously.

As shown in Figure 4, on the left is shown a basic version and on the right an improved version.

Below is the operating principle of the basic version (left part of figure 4).

During an initialization, we instantiate each architectural co-simulator i, responsible for initializing its state S(i). Each architectural co-simulator i consumes the content of its event queue EQ(i) in a different context (task).

Each co-simulator i registers with the transfer module, on the one hand a reference to its queue of events EQ(i), and on the other hand the list of types of events es that the architectural co-simulator i can to treat. The transfer module therefore adds i to the vector EM(e) for each event of type e in the list es.

Each architectural co-simulator i registers with the functional co-simulator a reference to its internal state S(i).

Then, a simulation phase takes place, carried out by quantums of instructions. During a quantum, the functional co-simulator simulates the defined number of instructions on a processor of the simulated platform.

A simulated instruction may be accompanied by an event signal. In this case, the functional co-simulator invokes the transfer module indicating the type of the event, as well as the data associated with it.

The transfer module, depending on the type of event, writes the event in the relevant EQ(i) event queue(s), and immediately gives control back to the functional co-simulator, allowing it to resume execution immediately.

Concurrently and in parallel with the execution of the functional co-simulator, each architectural co-simulator reads the events e from their event queue EQ(i) and calls their internal function F(i).

At the end of the instruction quantum, the functional co-simulator waits for the architectural co-simulator(s) to have finished processing their respective events, and uses the contents of the states S(i) to update its internal registers ( clock, PMU etc.).

The states S(i) are reinitialized on each reading. Thus, the counters correspond only to the execution of the current quantum, and are easy to exploit by the functional co-simulator.

Here follows the operating principle of the improved version, to maximize parallelism (right part of figure 4).

The basic approach can be very effective for quantums of a high number of instructions, however, the interest is quickly limited for small quantums, for the following reasons:
- The functional simulator must wait for the architectural co-simulator(s) to finish processing all events, including those signaled within the current quantum. If the set of architectural co-simulators is complex, this can very quickly impact the fluidity of the functional execution.
- If events arrive late in the quantum, architectural co-simulators can be inactive for a good part of the quantum, which does not take advantage of the parallelism of the host machine (see figure 3, on which the functional co-simulator remains waiting for the memory co-simulator when it has finished its quantum).

The improved version is shown on the left side of Figure 4.

It is assumed that the architectural co-simulator(s) can be slow, and therefore the goal is to ensure that at each quantum, the architectural co-simulators are processing events in parallel to the instructions of the functional co-simulator .

In the simulation, epochs are defined as an epoch corresponding to an integer number of quantums, greater than or equal to one. The simulation starts at epoch 0, then goes to epoch 1, then 2, etc.

The transition from one epoch to another can be done when switching from one quantum to another to simplify the implementation.

We will then distinguish between even epochs and odd epochs (epoch 0 is even, 1 is odd, etc.).

At the end of a quantum of instructions corresponding to an even epoch, the functional co-simulator must just wait for the architectural co-simulator(s) to finish processing the events of the last odd epoch. On passing to the next quantum, which corresponds to an odd epoch, the execution is done in parallel with the processing of the events of the previous quantum, which was even.

Similarly, at the end of a quantum of instructions corresponding to an odd epoch, the functional co-simulator just has to wait for the architectural co-simulator(s) to finish processing the events of the last even epoch. On passing to the next quantum, which corresponds to an even epoch, the execution is done in parallel with the processing of the events of the previous quantum, which was odd.

The implementation of this approach requires duplicating the state S(i) of an architectural co-simulator i, in two copies:
- S'(i) for even epochs, and
- S''(i) for odd periods.

An architectural co-simulator i writes to state S'(i) for even epochs, and the functional co-simulator reads S'(i) at the end of an odd epoch, and writes to state S' '(i) for odd epochs, and the functional co-simulator reads S''(i) at the end of an even epoch.

As illustrated in Figures 4 and 5, the present invention ensures that at the start of a new instruction quantum, the functional co-simulator just has to wait until the events of the same parity have been processed by the co-simulators. architectural simulators. The figures show that this makes it possible to execute a whole quantum while the architectural co-simulators process both the events of the previous quantum, and those newly emitted during the current quantum, which considerably reduces the execution time, as we can see it on figure 4, where one manages to execute three quantums of instructions instead of two, with the same simulation time.

Synchronization is detailed as follows.

A key factor in simulation performance is the mechanism used for synchronization between the functional simulator task and the co-simulation tasks.

In the present approach, no blocking synchronization mechanism (mutex, semaphore) should be used inside a quantum. On the other hand, such a mechanism can be used between quantums.

The duplication of the states of the architectural co-simulators ensures data consistency without any synchronization. Indeed, the state variables written by the functional co-simulator task (state reset) are those written by the architectural co-simulators at a previous epoch, and are different than those written by the co-simulators. architectural simulators in the current era.

The EQ(i) event queues are so-called lock-free queues. That is, no mutex is acquired before inserting or extracting an item from the queue.

Claims (9)

Fast simulator of a computer and of software implemented by this computer, the computer comprising at least one processor, a memory hierarchy comprising several levels of cache memories, external memories and an interconnection network providing communication between the cache memories and external memories;
the simulator comprising a plurality of co-simulators respectively associated with a task, and being configured to operate by quantum of instructions, a so-called functional co-simulator (CSF) being configured to operate the simulated software by disregarding the architecture of the computer, at least one other so-called architectural co-simulator (CSAi) being configured to simulate, in parallel, the architectural behavior linked to the architecture of the computer and to determine the values of extra-functional parameters of the computer, and a transfer module (MT) configured to transfer an event (e) signaled by the functional co-simulator (CSF) to an architectural co-simulator (CSAi) subscribed to this event. A simulator according to claim 1, wherein the extra-functional parameters of the computer include processor cycle times, and/or power, and/or reliability. Simulator according to one of the preceding claims, in which the architectural behavior comprises parameters representative of the architecture of the computer. Simulator according to claim 3, in which the parameters representative of the architecture of the computer comprise a number of cache and external memory accesses of the computer, and/or the communications of the interconnection network. Simulator according to one of the preceding claims, in which each architectural co-simulator is configured to simulate a unique type of event. Simulator according to one of the preceding claims, in which, a simulation being broken down into epochs numbered starting from 0, and an epoch corresponding to at least one quantum, the functional co-simulator (CSF) is configured for, at the start of an odd epoch, wait until each architectural co-simulator (CSAi) has finished processing the events of the preceding odd epoch, and at the beginning of an even epoch, wait until each architectural co-simulator (CSAi) has finished processing the treatment of the events of the preceding even epoch. Simulator according to claim 6, comprising two copies of the state (S(i)) of an architectural co-simulator (CSAi), a so-called even copy (S'(i)) for an even epoch and a so-called odd copy (S''(i)) for an odd epoch, the state (S(i)) of an architectural co-simulator (CSAi) comprising the parameters representative of the architecture of the computer, in which:

• an architectural co-simulator (CSAi) is configured to write to the even copy (S'(i)) during an even epoch and to write to the odd copy (S''(i) during an odd epoch, and
• the functional co-simulator (CSF) is configured to read then reset the even copy (S'(i)) between the end of an odd epoch and the start of the next even epoch, and to read then reset the odd copy (S''(i) between the end of an even epoch and the start of the next odd epoch.

A simulator according to claim 1, wherein an epoch corresponds to a single quantum. Method for rapid simulation of a computer and of software implemented by this computer, the computer comprising at least one processor, a memory hierarchy comprising several levels of cache memories, external memories and an interconnection network providing communication between the cache memories and the external memories comprising a plurality of co-simulators respectively associated with a task,
the method operating by instruction quantum, and comprising the steps of:

• simulation of the software by a so-called functional co-simulator (CSF), disregarding the architecture of the computer,
• simulation, in parallel, by at least one other so-called architectural co-simulator (CSA) of the architectural behavior linked to the architecture of the computer and determination of the values of extra-functional parameters of the computer, and
• transfer (MT) of an event signaled by the functional co-simulator to an architectural co-simulator subscribed to this event.