Method and electronic system for managing event streams of associated software application(s), computer program and electronic emulation installation

Abstract

Method and electronic system for managing event streams of software application(s), computer program and associated electronic emulation installation. The invention relates to a method for managing event streams emulated by a set (12) of first emulator(s) (14) comprising event producers, implemented by an electronic system and comprising a processing phase carried out iteratively for successive streams, and comprising: - acquiring from the producers a current stream including a current sequence of event(s) for each producer, each event having a respective date, with respect to an emulated clock common to the producers; - determining a current reordering interval between an initial time and a final time;- reordering events within the current reordering interval, the events to be reordered being the acquired events whose date belongs to the current reordering interval, and being reordered according to their respective dates; - storing the reordered events in a memory (30) for use by a set (16) of second emulator(s) (18). Figure for the abbreviation: Figure 2;

Description

Title of the invention: Method and electronic system for managing event streams of associated software application(s), computer program and electronic emulation installation

[0001] The present invention relates to a method for managing the flow of software application(s) events, emulated by a set of first emulator(s), the method being implemented by an electronic management system; as well as a computer program comprising software instructions which, when executed by a computer, implement such a management method.

[0002] The invention also relates to an electronic system for managing the flow of software application(s) events; as well as an electronic emulation installation comprising such an electronic management system.

[0003] The invention relates to the field of virtual prototyping, or VP (Virtual Prototypes), and emulators that allow the creation of models simulating the behavior of a target hardware architecture and the emulation of a software application on said hardware architecture. The emulator provides developers with a picture of the functional and temporal behavior of the software application's execution on the target hardware architecture. Emulating a software application makes it possible, for example, to identify potential timing issues, blocking, or contention during execution and to measure their impact on overall execution time. Thus, prototyping makes it possible to validate the operation of the software application as well as certain extra-functional properties, such as timing, before actually executing the software application on the hardware architecture, which may still be in the design phase.

[0004] The invention relates more particularly to the field of instruction set simulators, or ISS (from the English Instruction Set Simulators), which functionally simulate instruction set architectures, or ISA (from the English Instruction Set Architectures). An instruction set includes all the instructions supported by the target hardware architecture.

[0005] The performance of virtual prototypes in terms of simulation speed is crucial because it allows realistic benchmark tests to be run within a reasonable timeframe. This is particularly important due to the large number of iterations and comparative analyses required for tasks such as architectural exploration, also known as design space exploration, and software optimizations. Therefore, although modeling extra-functional properties improves the To be precise, it is essential to minimize any overload on the simulation speed as much as possible.

[0006] The article "mcQEMU: Time-Accurate Simulation of Multi-coreplatforms using QEMU" by H. Carvalho et al. (2020) extends the icount model of the QEMU™ (Quick Emulator) emulator to capture the complex temporal behaviors encountered in multi-core platforms. It introduces a new multi-core scheduling algorithm to address the limitations of the icount mode and includes synchronization models for various micro-architectural components within the QEMU™ tool.

[0007] The QEMU™ emulator is free software (from the English open source), and is a machine language code emulator, this emulator being generic by being adapted for different execution units from the group including: an x86 type processor, a PowerPC (PPC) type processor, an ARM type processor, a RISC-V type processor, a MIPS type processor, and more generally any programmable component having an instruction set (for example a GPU, a CISC type processor).

[0008] The article "Accelerate cycle-level full-system simulation of multi-core RISC-V Systems with binary translation" by X. Guo et al (2020) is an ISS designed to capture the cycle-level behavior of multi-core RISC-V systems. It integrates micro-architecture models, such as pipelines and caches, into the ISS.

[0009] The aforementioned articles present approaches where the temporal model, also called the timing model, is inside the instruction set simulator, i.e. inside the ISS.

[0010] The following articles present approaches where the time model is outside the ISS.

[0011] The article "Decoupling processor and memory hierarchy simulators for efficient design space exploration" by F. Jebali et al (2022) concerns a virtual prototyping used for hardware / software or HW / SW co-design and architectural exploration, and presents a simulation approach based on decoupling the processor emulation and the memory hierarchy simulation and executing them in parallel for efficiency purposes, offering improved simulation speed with a good level of accuracy compared to sequential simulation.

[0012] The article "Gathering memory hierarchy statistics in QEMU" by C. Deschamps et al (2019) concerns fast functional verification using transaction-level modeling of hardware / software systems, generally employing fast processor models based on dynamic binary translation. This article describes a first-level cache modeling strategy and how to implement it, then measures the additional costs associated with simulation speed.

[0013] The article “Afast cycle-approximate processor simulator based on QEMU” by SH Kang et al (2016) addresses processor timing simulation for exploring system architecture design space or developing software without available hardware. This article describes a fast and approximate cycle simulation technique for modern superscalar processors executing instructions out-of-order. The proposed simulation technique is designed in two parts: the front end provides correct functional execution of the guest application, and the back end provides a timing model. A processor timing model combining a simple formula-based analytical model and sampled trace scheduling analysis increases simulation speed with minimal loss of accuracy.

[0014] However, event stream management, particularly in the context of multi-core platform emulation, can still be improved.

[0015] The aim of the invention is then to propose a method and an electronic management system enabling better management of a plurality of event streams emulated by a plurality of event producers.

[0016] To this end, the invention relates to a method for managing event streams of software application(s), emulated by a set of first emulator(s), the set of first emulator(s) comprising a plurality of event producers emulating a plurality of event streams from one producer to another, the method being implemented by an electronic management system and comprising a processing phase carried out iteratively for successive event streams, the processing phase being carried out for each respective event stream and comprising the following steps:

[0017] - acquire a current stream of events from event producers; the current stream of events including a current sequence of event(s) for each event producer, each event having a respective date, defined with respect to a common emulated clock for the event producers;

[0018] - determine a current reordering interval between an initial time and a final moment;

[0019] - reorder events within the current reordering interval determined, the events to be reordered being all acquired events whose date belongs to the current reordering interval and the events being reordered according to their respective dates;

[0020] - storing reordered events in memory for use by a set of second emulator(s), the set of second emulator(s) comprising a plurality of event consumers.

[0021] With the tools and methods of the prior art, reversals of events and disorders at the level of the consumption of events are likely to occur, as described in more detail below, and the management method according to the invention then makes it possible to remedy this, by determining successive reordering intervals and reordering the events within said reordering intervals.

[0022] In particular, the management method according to the invention advantageously relates to multi-core / multi-producer simulation for the purpose of evaluating temporal or extra-functional aspects. Indeed, simulation artifacts that may appear can lead to reversals in the order of events, and these reversals can compromise extra-functional models whose result quality is sensitive to the order of events. The management method according to the invention therefore provides a mechanism for monitoring and correcting event streams.

[0023] Furthermore, the management process according to the invention is less intrusive in the sense that it does not impact the internal mechanisms of the ISS, and is implemented by a management system external to the ISS.

[0024] In addition, such a decoupling of the process steps, implemented by associated modules distinct from the management system defined below, promotes the acceleration of the overall execution by allowing parallel execution of the different modules.

[0025] According to other advantageous aspects of the invention, the management process comprises one or more of the following features, taken individually or in all technically possible combinations:

[0026] - the initial instant of the current interval is equal to the final instant of an interval previous determined during a previous iteration for a previous stream of events, and the initial time of the reordering interval associated with the first stream of events being a predefined initial value;

[0027] - each current sequence from a respective producer has a maximum date greater than or equal to the latest date among the date(s) of the event(s) in the sequence, and the final time of the current interval is equal to the minimum of the maximum dates of the current acquired sequences;

[0028] - events in the current flow whose date is later than the final instant of the current reordering interval are reordered during a subsequent iteration for a subsequent flow of events;

[0029] - during the acquisition step, the current flow of events is recorded in a primary memory, and the memory in which events are stored reordered during the storage stage is a second memory, distinct from the first memory;

[0030] - the processing phase further comprises, after the storage step, a step of feedback to the set of first emulators, to inform the set of first emulators of a time lag between these first emulators due to the evaluation of the behavior of the set of second emulator(s);

[0031] - the process further comprises, prior to the treatment phase, a phase a configuration in which each event producer is configured to emulate successive sequences of event(s), where the event(s) in each sequence have dates belonging to a respective sequence interval; and for each respective event producer, two successive sequence intervals of said producer are contiguous and disjoint from each other; and

[0032] - if the events of at least one current sequence have disordered dates, the the processing phase also includes a step of classifying events according to their respective dates for each of at least one current sequence;

[0033] the classification step being preferably carried out between the acquisition step and the determination step.

[0034] The invention also relates to a computer program comprising software instructions which, when executed by a computer, implement a management process as defined above.

[0035] The invention also relates to an electronic system for managing the event streams of software application(s), emulated by a set of first emulator(s), the set of first emulator(s) comprising a plurality of event producers emulating a plurality of event streams, the system comprising:

[0036] - an acquisition module configured to acquire a current stream of events from event producers; the current flow of events including a current sequence of event(s) for each event producer, each event having a respective date, defined in relation to a common emulated clock for event producers;

[0037] - a determination module configured to determine a current interval of reordering between an initial moment and a final moment;

[0038] - a reordering module configured to reorder events within of the current reordering interval determined, the events to be reordered being all acquired events whose date belongs to the current reordering interval and the events being reordered according to their respective dates;

[0039] - a storage module configured to store reordered events in a memory for their use by a set of second emulator(s), the set of second emulator(s) comprising a plurality of event consumers;

[0040] the acquisition, determination, reordering and storage modules being implemented for each respective stream of events, iteratively for successive streams of events.

[0041] According to other advantageous aspects of the invention, the electronic management system comprises one or more of the following features, taken individually or in all technically possible combinations:

[0042] - the system further includes a return module configured to perform a feedback to the initial set of emulators; and

[0043] - the system further includes a configuration module capable of configuring each event producer to emulate successive sequences of event(s), where the event(s) of each sequence have dates belonging to a respective sequence interval; and for each respective event producer, two successive sequence intervals of said producer are contiguous and disjoint from each other.

[0044] The invention also relates to an electronic emulation installation comprising:

[0045] - a set of first emulator(s) comprising a plurality of producers of events;

[0046] - a set of second emulator(s) comprising a plurality of event consumers;

[0047] - an electronic system for managing application event streams software(s), emulated by the set of first emulator(s),

[0048] the electronic management system being as defined above and connected between the set of first emulator(s) and the set of second emulator(s).

[0049] The invention will become clearer upon reading the following description, given solely by way of non-limiting example, and made with reference to the drawings in which:

[0050] [Fig-1] [Fig.1] is a view illustrating event reversals and disorder at level of consumption of events likely to occur with state-of-the-art tools and processes;

[0051] [Fig.2] [Fig.2] is a schematic representation of an electronic installation emulation comprising a set of first emulator(s) comprising a plurality of event producers; a set of second emulator(s) comprising a plurality of event consumers; and an electronic system for managing the flow of software application(s) emulated by the set of first emulator(s), the management system being connected between the set of first emulator(s) and the set of second emulator(s);

[0052] [Fig.3] [Fig.3] is a view illustrating, on the one hand, a stream of events emulated by an event producer; and on the other hand, a plurality of event streams emulated by a plurality of event producers;

[0053] [Fig.4] [Fig.4] is a view illustrating the determination of an interval of reordering, then a reordering of events within the determined reordering interval for a current stream of events including a current sequence of event(s) for each event producer;

[0054] [Fig. 5] [Fig. 5] is a view analogous to that of [Fig. 4], for a following flow of events including a subsequent sequence of event(s) for each event producer;

[0055] [Fig.6] [Fig.6] is an example of the implementation of a method according to the invention, managing the flow of software application(s) events, using objects and / or information from the QEMU™ emulator;

[0056] [Fig.7] [Fig.7] is an illustration of the implementation of the example implementation of [Fig.6] for three streams of events emulated by three event producers;

[0057] [Fig. 8] [Fig. 8] is an example of an implementation of part of the method, according to the invention, for managing the event stream of software application(s), for a first implementation, parallelized on two distinct threads, one for the first set of emulator(s) and the management system and the other for the second set of emulator(s); and

[0058] [Fig.9] [Fig.9] is a view analogous to that of [Fig.8], for a second implementation, parallelized on three distinct processes (from the English threads), with implementation of the management system in a process separate from the process of the first set of emulator(s), in order to parallelize the management system with both the first set of emulator(s) and the second set of emulator(s).

[0059] By "event producers" we mean different models of hardware components that generate events which will be processed by other models. These include, for example, guest CPUs (Central Processing Units) and DMA (Direct Memory Access) engines, such as input / output devices; or sets of components considered together, such as a CPU and its non-shared first-level caches.

[0060] The generated event streams are consumed by one or more entities, either models or simulators, called "event consumers". The consumers can model the detailed behavior of different architectural components, such as different L1 first-level caches and hierarchies of memory, or more abstract models that evaluate different measures, such as analytical models of performance or energy consumption.

[0061] In the following description, event producers are denoted EP when designated generally, or individually as EP1, EP2, EP3, ..., EPn, where n is an integer representing the number of event producers. Event consumers are denoted EC when designated generally, or individually as EC1, EC2, ..., ECm, where m is an integer representing the number of event consumers.

[0062] The invention aims to simulate the behavior of one or more target hardware architectures, forming a guest system, the guest system comprising several components that operate in parallel. The parallelism is therefore at the level of the guest system that is simulated.

[0063] The simulation of the guest system on a host machine can be done sequentially or in parallel, depending on the simulator. In both cases, reversals of the order of events can occur, as illustrated in the example in [Fig. 1] below.

[0064] For example, the QEMU™ emulator offers both cases: a sequential TCG (Tiny Code Generator) mode where the different CPUs run on the same process (thread) in Round-Robin; and a parallel mode, called MTTCG (Multi-threaded TCG), where the different CPUs run on different processes (threads).

[0065] A person skilled in the art will then observe that the invention applies in both of the aforementioned simulation cases, i.e. sequential or parallel.

[0066] Figure 1 illustrates two use cases, namely a first use case C1 and a second use case C2, with several event producers EP1, EP2, EP3, ..., EPn (left-hand boxes), where the events of the same producer EP are assumed to be ordered locally, i.e., with respect to a clock on the simulated guest system. It should be noted that the event emission times, which are timestamps relative to a clock on the host machine, differ from the timestamps, denoted ts, which are timestamps relative to the clock on the guest system. The event emission times depend on the execution speed of the producer EP on the host machine. The emission times determine when the consumer EC perceives the event, while the timestamps correspond to when the event occurs in the simulated guest system.

[0067] The events produced serve as input to multiple consumers EC1, EC2, ..., ECm (right-hand box). The behavior of the consumers EC is assumed to be sensitive to the overall order of these events, that is, to the order of the events received from several producers EPI, EP2, EP3, ..., EPn. This is, for example, the case in Memory hierarchy models, where the order of events modifies the state of the cache memory and its future behavior. It is therefore necessary to transmit these events in a global timestamp order, which is the aim of the present invention, while also allowing for the reception of events in parallel.

[0068] The first use case Cl, illustrated in the upper part of [Fig. 1], considers a scenario in which all EP producers run on the same thread while being scheduled cooperatively. This is the case in the TCG mode of the QEMU™ emulator, where multiple CPUs run according to a Round-Robin policy. In this execution semantics, discrepancies in the order of events in terms of event timestamps become apparent when events are considered in the order of their emission date. These discrepancies are detectable when moving from one execution unit (also called a compute unit hereafter) to another within an instruction quantum, revealing that instructions are time-ordered for each execution unit, but that there is no global order encompassing all simulated execution units.

[0069] The second use case C2, illustrated in the lower part of [Fig. 1], considers a scenario in which the different EP producers run on multiple threads. The main source of discrepancies when events are considered in the order of their emission date arises from variations in the rate at which the EP producers emit events. For example, since the third producer EP3 runs faster than the other two EP producers, EP2, the events with the highest timestamps were emitted before the events of the other producers with the lowest timestamps. This leads to event inversions and disorder in event consumption. In [Fig. 1], such inversions, or disorder, are enclosed in an ellipse A.Furthermore, multithreaded execution of EP producers can lead to contention issues when accessing the queue, resulting in a performance loss during event production.

[0070] In both use cases C1 and C2, a reordering phase of all events emitted by all EP producers is advantageous before their processing by EC consumers. It should be noted that a third use case, in which several different ISS instances are used as event generators, could behave very similarly to the second use case C2.

[0071] In [Fig.2], an electronic emulation installation 10 comprises a set 12 of first emulator(s) 14 comprising a plurality of EP event producers, said set also being called first set 12; a set 16 of second emulator(s) 18 comprising a plurality of Consumers of EP events, said set also being called the second set 16; and an electronic system 20 for managing the flow of software application(s) events. The electronic management system 20 is connected between the first emulator(s) 14 set 12 and the second emulator(s) 18 set 16, i.e., between the first set 12 and the second set 16.

[0072] The emulation installation 10 is then configured to emulate one or more software applications, that is, to simulate the execution of the software application(s) on a target hardware architecture, the target hardware architecture being modeled to reproduce the behavior of the hardware architecture during the execution of the software application. The software applications are executed successively or in parallel.

[0073] The software application emulation provided by the emulation installation 10 then makes it possible to identify potential timing errors, blockages, or contentions during execution and to measure their impact on overall execution time. The emulation installation 10 thus contributes to the joint validation of the operation of the software application and the target hardware architecture, as well as certain extra-functional properties, such as timing properties, before actually running the software application on the hardware architecture. In other words, the emulation installation 10 provides assistance in validating the operation of the software application.

[0074] Each execution of a software application includes a set of instructions, some or all of which have a timestamp, denoted ts, which is a date relative to the clock of the guest system. In other words, a set of instructions, each with a timestamp, is included in the instruction set of the software application execution. In the examples in Figures 1 to 5 and 7 to 9, the timestamps, or dates relative to the clock of the guest system, correspond to the values ​​indicated after "ts =", or to the values ​​following the letter "e", this letter designating an event. For example, according to the first use case C1 in [Fig. 1], the events produced by the producers EPI to EP3 have the following dates in their order of emission: 4; 6; 16; 18; 2; 14; 30; 32; 32; 34.As another example, according to the timeline in the upper part of [Fig.3], the events produced by the EP producers have the following dates according to their order of issue: 10; 13; 11; 15; 14; 17; 21; 20; 23.

[0075] A person skilled in the art will then understand that, within the meaning of the present invention, an instruction with an associated respective timestamp constitutes an event.

[0076] The instructions are configured to be executed sequentially by an execution unit included in the target hardware architecture, to accomplish tasks defined by the software application. The execution unit is for example a processor, or a programmable logic circuit - also called FPGA (from the English Field Programmable Gate Array), or a dedicated integrated circuit - also called ASIC (from the English Application Specified Integrated Circuit).

[0077] Each instruction corresponds to a specific command or elementary operation to be executed by the execution unit to perform a particular task. For example, an instruction might correspond to the addition of two numbers, a data transfer between memory and the processor, or a comparison of two values, etc. Thus, each instruction is associated with an instruction type indicating the type of command or elementary operation implemented by that instruction. The instruction type to be determined is, for example, chosen from the group comprising: arithmetic instruction; memory access, such as reading or writing to memory; input / output access (or I / O access); branch instruction (conditional or not).

[0078] The execution unit is for example chosen from the group comprising: an x86 type processor, an x84 type processor, a PowerPC (PPC) type processor, an ARM type processor, a RISC-V type processor, a MIPS type processor, and more generally any programmable component having an instruction set (for example a GPU), a CISC type processor.

[0079] Each instruction is, for example, a binary instruction, expressed in a low-level language, such as machine language. By machine language, we mean a language directly interpretable by the execution unit.

[0080] The first set 12 comprises at least one first emulator 14, each first emulator 14 having at least one EP event producer. Advantageously, the first set 12 comprises several first emulators 14. The plurality of EP event producers is configured to emulate a plurality of event streams from one EP producer to another.

[0081] Each first emulator 14 is configured to emulate a respective software application or portion of a software application. Each first emulator 14 is typically configured to provide events to the management system 20. In other words, each first emulator 14 is configured to provide a sequence of events, as shown in Figures 1 or 3 for example.

[0082] The first emulator 14 is for example an instruction set simulator, or ISS (from the English Instruction Set Simulator).

[0083] Preferably, the first emulator 14 is configured to perform a dynamic binary translation or DBT (from the English Dynamic Binary Translation) which allows instructions from the target hardware architecture (or guest system) to be dynamically translated into instructions understandable by the host hardware architecture, or host machine, the execution of which will emulate the behavior of the guest architecture, or guest system. By dynamic, we mean that the translation of instructions is performed in parallel with the simulation of the execution of instructions already translated in the target hardware architecture. In other words, this translation is performed continuously, as the instructions are processed, for example, by instruction block.

[0084] The first emulator 14 is for example the QEMU™ emulator (from the English Quick Emulator), which is a machine language code emulator, this emulator being generic since it supports different execution units among those mentioned above and in free software (from the English open source).

[0085] Alternatively, the first emulator 14 is the Spike emulator, the FastModels emulator from the Arm company, or the OVPsim emulator.

[0086] More generally, the first emulator 14 is any instruction set simulator, also called an ISS (Instruction Set Simulator), instrumented to provide sequences of events in their emulation order. The event set may contain a subset of instructions, or events internal to the emulated target architecture such as cache accesses, or notification events related to the first emulators 14 to be transmitted to the EC consumers, such as the end of execution.

[0087] The second assembly 16 comprises at least one second emulator 18, each second emulator 18 having at least one EC event consumer. Advantageously, the second assembly 16 comprises several second emulators 18.

[0088] Each second emulator 18 is typically configured to receive events from the management system 20. In other words, each second emulator 18 is configured to receive a sequence of instructions executable by a subset or the whole of the target hardware architecture, as shown in Figures 4 and 5 for example.

[0089] The second emulator 18 is, for example, a memory hierarchy model, which takes as input sequences of events and estimates the performance of components, such as caches and interconnects, or of the overall system in terms of performance counters, such as cache hit / miss, memory latencies, or the overall execution time of the emulated application. Alternatively, the second emulator 18 is an abstract model, such as an analytical model, which estimates performance or energy consumption.

[0090] More generally, the second emulator 18 is any model or simulator of the extra-functional behavior of a subset or the whole of the target hardware architecture, which takes as input sequences of events in order to allow an analysis of the extra-functional aspects.

[0091] The electronic management system 20, hereafter referred to as management system 20, is configured to manage event streams from software application(s), emulated by the set 12 of first emulator(s) 14.

[0092] The management system 20 comprises, for example, a configuration module 22, an acquisition module 24, a first memory 26, an analysis device 28, a second memory 30, and a feedback module 32, as shown in [Fig. 2]. In the example of [Fig. 2], the acquisition module 24, the first memory 26, the analysis device 28, and the second memory 30 are connected in series in that order, one after the other. The acquisition module 24 is further connected to the first set 12 to acquire the plurality of event streams produced by the EP producers included in the first emulator(s) 14. The second memory 30 is further connected to the second set 16 to deliver the events reordered by the management system 20 to the EC consumers included in the second emulator(s) 18. The configuration module 22 is optional, and is connected where applicable to the first set 12 of the first emulator(s) 14.The return module 32 is also optional, and is connected where appropriate to the second set 16 of second emulator(s) 18 and to the first set 12 of first emulator(s) 14. The second memory 30 is separate from the first memory 26.

[0093] The analysis device 28 includes, for example, a sorting module 40, also called a reordering module, a determination module 42, a reordering module 44, and a storage module 46. In the example of [Fig. 2], the determination module 42, the reordering module 44, and the storage module 46 are connected in series in that order, one after the other, within the analysis device 28. The sorting module 40 is optional and is connected, if present, to the input of the determination module 42. The determination module 42 is connected to the first memory 26, or to the sorting module 40 if present. The storage module 46 is connected to the second memory 30.

[0094] The management system 20 includes, for example, in addition to the first 26 and second 30 memories used in particular for event storage, a memory and one or more processors associated with the memory, not shown, for implementing the aforementioned modules. The processor(s) and the memory may also be shared with those required for a first emulator 14 or a second emulator 18 respectively, or for the first 26 or second 30 memory.

[0095] The configuration module 22, the acquisition module 24, and the feedback module 32, as well as the analysis device 28 comprising the classification module 40, the determination module 42, the reordering module 44, and the storage module 46, are implemented as one or more software programs, or a software component, executable by the processor. The memory is then capable of storing a software program. The processor is then capable of executing the configuration software, acquisition software, and return software, as well as the classification software, determination software, reordering software, and storage software.

[0096] In an alternative not shown, the configuration module 22, the acquisition module 24, and the return module 32, as well as the analysis device 28 comprising the classification module 40, the determination module 42, the reordering module 44 and the storage module 46, are made in the form of a programmable logic component, such as an FPGA (Field Programmable Gate Array) or in the form of a dedicated integrated circuit, such as an ASIC (Application Specified Integrated Circuit).

[0097] When the configuration module 22, the acquisition module 24, and the feedback module 32, as well as the analysis device 28 comprising the classification module 40, the determination module 42, the reordering module 44, and the storage module 46, are implemented in the form of one or more software programs, i.e., in the form of a computer program, it is also capable of being recorded on a computer-readable medium, not shown. A computer-readable medium is, for example, a medium capable of storing electronic instructions and being connected to a bus of a computer system. By way of example, a readable medium is an optical disc, a magneto-optical disc, a ROM, a RAM, any type of non-volatile memory (e.g., EPROM, EEPROM, FLASH, NVRAM), a magnetic card, or an optical card. A computer program containing software instructions is then stored on the readable medium.

[0098] Advantageously, the configuration module 22 is capable of configuring each EP event producer to emulate successive sequences of event(s), where the event(s) of each sequence have dates belonging to a respective sequence interval; and for each respective EP event producer, two successive sequence intervals of said producer are contiguous and disjoint from each other.

[0099] The configuration module 22 is then configured to determine which hardware components are capable of producing events with certain time barrier guarantees, these components being called Time-Fenced Producers, or TFPs.

[0100] The configuration module 22 is typically configured to analyze, for each first emulator 14, the flow of its event production in order to subdivide them into successive finite sequences of event(s), where the event(s) of each sequence have dates belonging to a respective sequence interval; and for for each respective event producer, or TFP, two successive sequence intervals of said TFP are contiguous and disjoint from each other.

[0101] Each TFP is then an event producer configured to emulate successive finite sequences of event(s), denoted {e0, el, e2, ...} in Figures 3 to 5, where the event(s) of each sequence have dates, relative to the clock of the guest system, belonging to a respective sequence interval; with successive sequence intervals contiguous; and the intersection of any two intervals is empty, meaning that the limits of the interval belong to a single interval.

[0102] The index interval j of the producer P is denoted 1 / , and each interval is characterized by a start date, denoted Db(IjP), and an end date De(IjP). The intervals are contiguous, meaning that the end date of the interval 1 / corresponds to the start date of the following interval Ij+iP, i.e., De(IjP) = Db(Ij+iP), and are furthermore disjoint from each other. In other words, all the intervals are then typically defined as follows: [Db(IjP), De(IjP)[; or as follows: ]Db(IjP), De(IjP)].

[0103] The events of an interval IjP are not necessarily ordered with respect to their timestamps, but their timestamps are necessarily delimited by the start date Db(IjP) and the end date De(IjP) of said interval IjP. Thus, the ground truth for measuring the simulated elapsed time consists of capturing the limits of the interval, whose values ​​necessarily increase as the simulation progresses.

[0104] Consequently, a respective TFP typically satisfies the following property:

[0105] [1]

[0106] vee / J, VTs(e) < Ts{e')

[0107] where e, e' denote the respective events of successive intervals 1 / , Ij+iP, and

[0108] Ts denotes a function returning the timestamp of an event.

[0109] The upper part of [Fig. 3] illustrates the flow of events produced by a TFP. It can be observed that each event within an interval is bounded by the start and end dates of the interval, without necessarily being ordered with respect to the other events within the interval. The example assumes an interval including the upper bound and excluding the lower bound, i.e., ]Db(IjP), De(IjP)]. This convention will be used in the following Figures 4 and 5.

[0110] In these figures 3 to 5, each event is represented in the form of a rectangle with the letter "e" inside the rectangle and a number corresponding to the timestamp associated with the event; each symbol with the two head-to-tail triangles represents an end of interval for a given EP producer, i.e. a respective De(IjP); and each dotted box represents a data structure receiving and storing events in the order of their occurrence.

[0111] Regarding this configuration, a person skilled in the art will observe that the first Emulators 14 aim to reproduce the behavior of real hardware modules which, by their nature, produce events in the order of the physical time flow. Therefore, each hardware module model aims to produce its events in sequence.

[0112] However, at the system level, software simulation of hardware module models generally cannot exhibit a sufficient level of parallelism to allow modeling each component in parallel. Parallelism is then emulated by successively evaluating the evolution of each component over time periods, also known as sequential scheduling. This is done, for example, with cooperative scheduling in SystemC, or in QEMU™ models, or with preemptive mechanisms.

[0113] Furthermore, while some parallelism exists in software simulation, the processes (threads) that execute them are often difficult to synchronize, and events produced by different producers can become intertwined. For these two reasons, event producers do not necessarily conform to the definition of TFP.

[0114] However, due to the underlying nature of the hardware modules of the simulation software, it is still possible to convert these producers into TFPs, as demonstrated below by the proof by exhaustion.

[0115] If we consider sequential scheduling, two cases arise:

[0116] - the time allocated to each module is constant. Then, once all the Once the modules have been executed, the interval sizes are aligned with this amount of time, and the end dates of the different intervals are set to the end of the guest time allocated to each module. In this way, the producer, which encompasses all the modules, constitutes a TFP (Time-Focused Process). It is important to note that events are not ordered within the interval's start and end boundaries, but rather that all events occurring during the interval have timestamps that correspond to its boundaries.

[0117] - The guest time allocated to each module is variable. One solution is then to divide the producer into sub-producers (one for each hardware module), which are naturally ordered (due to their hardware nature). Each sub-producer then constitutes a TFP.

[0118] If we consider parallel scheduling (multithreading), two cases also arise:

[0119] - the producer processes (threads) synchronize from time to time after a A certain waiting time is required. This synchronization mechanism can then be used for define a common end of interval, and the set of producing processes constitutes, for example, a single TFP.

[0120] - the producer processes (threads) are not synchronized, each process A process must be considered an independent producer and is therefore a TFP only if it models a single hardware model. For each process that models multiple hardware models, the rules of sequential scheduling are applied. This case also covers the identification of TFPs when both sequential and parallel scheduling are used in the first set of emulators.14

[0121] Once the various TFPs have been correctly identified, the configuration module 22 is optionally configured to subdivide them into smaller TFPs, for example, based on hardware structure. This can be beneficial when it allows for stronger properties than those of the TFP, for example, the production of ordered events, by eliminating the analysis costs at a later stage, typically via the optional classification module 40.

[0122] A person skilled in the art will also understand that the present invention aims to simulate the behavior of a real object, and that it therefore does not concern EP event producers that would produce events with a random timestamp.

[0123] The acquisition module 24 is configured to acquire a current stream of events from the EP event producers, typically from the TFPs. The current stream of events includes a current sequence of event(s) for each EP event producer, each event having a respective date, defined with respect to a common emulated clock for the EP event producers. In other words, the event date is the timestamp, defined above, associated with the event.

[0124] The acquisition module 24 is further configured to store, i.e. record, each current stream of acquired events in the first memory 26.

[0125] The analysis device 28 comprising the determination module 42, the reordering module 44 and the storage module 46, as well as, optionally, the classification module 40, is then configured to analyze each current stream of acquired events, stored in the first memory 26.

[0126] According to the above-mentioned optional supplement, the sorting module 40, also called the reorganization module, is configured to, if the events of at least one current sequence have disordered dates, sort the events according to their respective dates for each of the at least one current sequence.

[0127] The sorting module 40 is, for example, configured to extract, from the first memory 26, the events and boundaries of successive intervals of a single TFP; then, for each interval, to reorganize the events according to their timestamp (i.e., their date according to the guest system clock). Each intra-TFP interval can be reorganized separately from the others. Therefore, the reorganization of events within each intra-TFP interval guarantees by construction a correct global reorganization of events in the TFP under consideration, thanks to the definition of the TFP which provides for a correct evolution of the start and end dates of successive intervals.

[0128] The output of the sorting module 40 is a set of ordered event streams, each corresponding to a TFP. It should be noted that there is no overall order between the event streams of the different TFPs.

[0129] This classification module 40 advantageously reduces considerably the cost, in terms of resources and computation time, of the subsequent operations described below.

[0130] Those skilled in the art will note that in the example at the bottom of [Fig. 3], the event streams represented for the three EP event producers in parallel from the perspective of the guest system, and which are subsequently repeated in the examples of Figures 4 and 5, have not undergone this optional sorting, since the events within certain sequences of these streams are not ordered. For example, in the second sequence of the first stream, the event with timestamp 14 is placed before the one with timestamp 12. Similarly, in the second sequence of the second stream, the event with timestamp 8 is placed before the one with timestamp 6; and in the second sequence of the third stream, the event with timestamp 13 is placed before the one with timestamp 11, and the one with timestamp 15 is placed before the one with timestamp 14.

[0131] The determination module 42 is typically configured to take as input multiple streams from different TFPs originating from the first memory 26, and to identify the intervals within which it is possible to reorder inter-TFP events. These intervals are called reordering intervals or RIs, because they will be used by subsequent modules 44, 46 to reorder events from all TFPs and produce a total order of events.

[0132] The determination module 42 is configured, for each respective stream of events processed by the analysis device 28, i.e. previously acquired by the acquisition module 24, to determine a current reordering interval RI between an initial instant Imin and a final instant Imax.

[0133] The initial time Imin of the current interval is advantageously equal to the final time Imax of a previous interval determined during a previous iteration for a previous stream of events, and the initial time Imin of the reordering interval RI associated with the first stream of events being a predefined initial value, such as the value zero.

[0134] A person skilled in the art will understand that the reordering interval RI is a reordering time interval, that the initial time Imin is an initial time instant, and similarly that the final time Imax is a final time instant.

[0135] Each current sequence from a respective EP producer has a maximum date greater than or equal to the latest date among the date(s) of the event(s) in the sequence, and the final instant Imax of the current interval is advantageously equal to the minimum of the maximum dates of the current sequences acquired from each EP producer.

[0136] The reordering interval RI is obtained by identifying the time limits, relative to the time of the guest system, within which the analysis device 28 is certain to have received all events (i.e., no time-stamped event within these limits will be produced subsequently).

[0137] To better understand the behavior of the determination module 42, the lower part of [Fig. 3] gives an example of a subset of events in the data structure at a point in the simulation. It should be noted that the data structure continues to receive and store events on the fly.

[0138] For the sake of readability in [Fig. 3], and in the following Figures 4 and 5, a temporal flow is considered that is approximately the same on the host machine and on the guest system, while exhibiting illustrative local variations. The data structure is therefore stretched so that the start and end dates of the intervals respect the overall order of the guest system in the image.

[0139] Since all producers respect the preceding property [1], the time flow is measured by capturing and aligning the interval ends of all TFPs.

[0140] The determination module 42 is configured to determine the reordering intervals ]Imin> Imax] based on the intervals of the individually collected TFPs. The initial Imin and final Imax times are determined based on the timestamps of the available events.

[0141] The start of the reordering interval, denoted Imin, is chosen to be less than the earliest date of all available events, that is, events that have not already been scheduled in previous reordering intervals. Therefore, it can be defined either by finding the earliest available event date, or more simply by using the final time Imax of the previous reordering interval (since all events less than this final time Imax have already been processed), and, for example, the value zero for the first interval.

[0142] The determination module 42 is configured to determine the end of the reordering interval, i.e. the final time Imax, by first retrieving the last end dates

[0143]

[0144]

[0145]

[0146]

[0147]

[0148]

[0149]

[0150]

[0151]

[0152]

[0153]

[0154] of all known intervals for each producer, then finding the nearest end date among these intervals, which is then used as the Imax end time. This means that all available events with a timestamp prior to the final Imax time will be included in the reordering interval; that is, they will be reordered according to their timestamp. Events with a timestamp subsequent to the final Imax time are retained to be scheduled during later reordering intervals. If no end of interval is yet available for some producers, the determination module 42 is configured to wait for their availability. If a producer has finished its execution (which can be notified by specific events), as soon as all its events have been scheduled, the determination module 42 is configured to no longer consider this producer for the determination of the final time Imax of the current reordering interval. More formally, the final time Imax of the current reordering interval typically satisfies the following equation: [2] Imax ~ minP€II max{DjzJ) i / J Iz} where P is a TFP, fl is the set of TFPs, IjP represents the index interval j of producer (TFP) P, and De(IjP) represents the end date of said interval, and h is the set of intervals received in the data structure at the real time t. Furthermore, it follows that if the previous property [1] and equation [2] are verified, then all events occurring up to the final instant Imax of the current reordering interval have already been received. In the example shown in the lower part of [Fig. 4], the first analysis zone represents the set of TFP intervals whose end dates are known to the determination module 42, at a given time tl of the host machine. It encompasses all events that can be selected for reorganization at this stage, and the dashed line referenced RE indicates a limit of the events perceived at the start time of the analysis performed for the first analysis zone by the analysis device 28 in this example. In [Fig. 4], the different TFP intervals of the first analysis zone, delimited by the AZ box in this figure, end respectively at times 7, 5 and 10, and the final time Imax of the current reordering interval is then fixed at the nearest date, i.e. Imax=5. The first reordering interval RI is therefore the interval ]0,5], with the chosen predefined initial value equal to the value zero.

[0155] In [Fig.4], the LEI reference indicates the last known end of interval among all the intervals of the different TFPs, and this last end of the interval then corresponds to date 10, i.e. LEI=10.

[0156] The reordering module 44 is configured to reorder events within the determined current reordering interval RI, the events to be reordered being all acquired events whose date belongs to the current reordering interval RI and the events being reordered according to their respective dates.

[0157] In addition, events in the current flow whose date is later than the final instant Imax of the current reordering interval RI are advantageously reordered during a subsequent iteration for a subsequent flow of events, as explained above.

[0158] In other words, the reordering module 44 is configured to retrieve events from the current reordering interval RI determined by the determination module 42, and then to reorder them according to their respective dates, i.e., according to their respective timestamps. The reordering module 44 thus ensures an overall ordering of events within the current reordering interval RL

[0159] The reordering module 44 is then configured to transmit the reordered events to the storage module 46 within the current reordering interval RL

[0160] For the first reordering interval RI, namely the interval ]0,5], the two events whose timestamp is earlier than or equal to the final time Imax, namely 5, i.e., the two events with date 5, are reordered by the reordering module 44 within this reordering interval, as represented by the arrow RO in the lower part of [Fig. 4]. The events that have undergone this reordering are removed from the events to be reordered and are then represented by hatching in the lower part of [Fig. 4], and also in [Fig. 5].

[0161] For the first analysis zone AZ, the reordering performed is then shown by the arrow RF in [Fig.4], and concerns the two events of date 5.

[0162] The other events, whose timestamps are 7 and 10, are retained for scheduling at later reordering intervals, as shown in [Fig. 5]. This measure is advantageous because it is not guaranteed that all events prior to timestamp 7 or 10 have been received from all TFPs.

[0163] At the beginning of the subsequent analysis phase, illustrated in [Fig. 5], the last known interval for all producers is respectively 14, 12 and 15, as represented by the analysis area delimited by the AZ box in [Fig. 5]. Thus, the final time Imax of the current reordering interval is 12, and all events up to and including timestamp 12 are scheduled to be reordered. For this current reordering interval, the initial time Imin is equal to the final time Imax of the previous reordering interval, as summarized by the relation Imin = (Imax)pre in [Fig. 5], i.e., Imin = 5 in this example. In other words, the current reordering interval RI for this subsequent analysis phase is then the interval ]5,12].

[0164] These events to be reordered by the reordering module 44 then correspond to the events represented by hatching in the lower part of [Fig. 5], which were not already represented by hatching in the upper part of [Fig. 5]. The result of this reordering for the subsequent analysis phase is designated by the arrow RF in the lower part of [Fig. 5].

[0165] Events with timestamps 13, 14 and 15 are kept in the event queue for a later analysis phase.

[0166] A person skilled in the art will observe that the classification, or reorganization, of events carried out optionally by the classification module 40 is also called intra-sequence reordering, i.e. within a respective sequence; and that the reordering carried out by the reordering module 44 is also called inter-sequence reordering, i.e. between sequences, since it is operated on several sequences from different producers.

[0167] The storage module 46 is configured to store the reordered events in the second memory 30 for use by the second set 16 of second emulator(s) 18, the second set 16 comprising a plurality of EC event consumers.

[0168] In other words, the storage module 46 is configured to receive events in the order following the reordering performed, and then to store them in the same order in the second memory 30, for example as a database of ordered events. Advantageously, said database is structured to support multiple readers, so that several EC consumers can retrieve events simultaneously.

[0169] The acquisition module 24, determination module 42, reordering module 44 and storage module 46 are implemented for each respective event stream, iteratively for successive event streams.

[0170] A person skilled in the art will observe that the generated event sequences are not necessarily of the same length from one EP event producer to another. In the particular case where the generated event sequences are of the same length From one EP event producer to another, for example according to quantums, this allows for implementation simplifications. In particular, the reordering intervals can be aligned with the different quantums, which would simplify the determination of the Imin and Imax bounds of these intervals.

[0171] For example, the QEMU™ emulator divides the set of emulated instructions into quantums by defining an instruction budget (sometimes called a quantum budget). A quantum corresponds to the number of instructions that execute sequentially on a single emulated processor, or CPU, before handing control over to another emulated processor to execute a quantum, and so on. In other words, a quantum is a notion of duration, typically expressed either in units of time (e.g., seconds), cycles, or instruction counter values.

[0172] The feedback module 32 is configured to provide feedback to the set 12 of first emulators 14, to inform the set 12 of first emulators 14 of extra-functional information, such as a time lag between these first emulators 14 due to the evaluation of the behavior of the set 16 of second emulator(s) 18.

[0173] This feedback contains, for example, an estimate of the overall latency of the current event interval, or an estimate of performance counters, such as the number of accesses or the performance of the different cache levels in terms of hit / miss rate, or more generally any extra-functional information (consumption, temperature, performance...).

[0174] For example, if we consider "memory access" type events, some processors within the first set 12 may access remote memory (central or even on-chip in a NUMA architecture) which results in additional latency compared to other processors which would have accessed only their caches.

[0175] In addition, the return module 32 is configured to retrieve a time lead, i.e. a temporal lead, from the second emulators 18 to inform the first emulators 14. The time lead of the second emulators 18 of the second set 16 with respect to the first set 12 typically corresponds to the aforementioned latency, and it is therefore preferable to take it into account to increase a running time of the first emulators 14 of the first set 12.

[0176] This feedback mechanism performed by the feedback module 32 is also useful to ensure that the first emulator or each first emulator 14 does not execute too many tasks before the second emulator or each second emulator 18, i.e. does not run too far ahead of the second emulator or emulators 18. It can therefore be used to impose a limitation on the anticipation time of the first emulators 14, so that the impact of the second emulator 18 on the first 14 is taken into account at the time of adaptation. This advantageously limits the amount of events to be stored in the first and second memories 26, 30, since the first emulators 14 will be stopped if the second emulator 18 is too slow to consume the events generated by the first emulator(s) 14.

[0177] A method for managing software application event streams according to the invention, implemented by the electronic management system 20, includes a processing phase carried out iteratively for successive event streams, the processing phase - carried out for each respective event stream - comprising several successive steps.

[0178] The processing phase begins with an initial acquisition step, denoted ACQ in [Fig. 2], during which the acquisition module 24 acquires a current stream of events from the EP event producers. The current stream of events includes a current sequence of event(s) for each EP event producer, each event having a respective date, defined with respect to the emulated clock common to the EP event producers.

[0179] The processing phase then includes a determination step, during which the determination module 42 determines the current reordering interval RI between the initial time Imin and the final time Imax.

[0180] Optionally, if the events in at least one current sequence have disordered dates, the processing phase advantageously includes a sorting step, in which the sorting module 40 sorts the events according to their respective dates for each of the at least one current sequence. The sorting step is preferably performed between the acquisition step and the determination step.

[0181] The processing phase includes, after the determination step, a reordering step, during which the reordering module 44 reorders the events within the current reordering interval RI, determined during the preceding determination step. The events to be reordered are all acquired events whose date falls within the current reordering interval RI, and the events are reordered according to their respective dates.

[0182] The processing phase finally includes a storage step, during which the storage module 46 stores the reordered events in the second memory 30 for use by the second set 16 of second emulator(s) 18.

[0183] The steps of classification (optional), determination, reordering, storage form a sub-phase of analysis, noted ANA in [Fig.2].

[0184] As an optional addition, the processing phase further includes, after the storage step, a return step, denoted RET in [Fig. 2], during which the module return 32 performs the feedback to the set 12 of first emulators 14, to inform the set 12 of first emulators 14 of a possible time lag between these first emulators 14 due to the evaluation of the behavior of the set 16 of second emulator(s) 18.

[0185] The processing phase is carried out iteratively, that is to say, is repeated regularly, to process successive flows of events as they occur, for the plurality of EP event producers in parallel; and the steps of acquisition, classification (optional), determination, reordering, storage and return (optional), forming the processing phase are then also repeated regularly.

[0186] In addition, the management method according to the invention further includes, prior to the processing phase, a configuration phase, denoted CONF in [Fig.2], during which each event producer EP is configured, by the configuration module 22, to emulate successive sequences of event(s), where the event(s) of each sequence have dates belonging to a respective sequence interval; and for each respective event producer EP, two successive sequence intervals of said producer are contiguous and disjoint from each other.

[0187] An example of implementation of the management process defined above will now be described for the QEMU™ emulator with reference to Figures 6 and 7.

[0188] For the configuration step, the set 12 of the first emulators 14 consists of a QEMU™ emulator containing multiple CPUs and peripherals. Each execution unit or peripheral forms, for example, a TFP. Events corresponding to a CPU / peripheral are generated in order, but there is no overall order among all CPUs / peripherals. The QEMU™ emulator defines the notion of instruction budget, hereafter called quantum budget, which is a quantity of guest system time shared among all CPUs after which all CPUs synchronize. This example implementation then takes advantage of the inherent decomposition of execution time into quantums to represent the TFP intervals. Thus, each quantum corresponds to a TFP interval. These synchronization points are used to define the reordering intervals.

[0189] Events are assumed to be timestamped for each CPU / device, e.g., on the basis of instruction / event counting.

[0190] For the acquisition stage, during emulation, each CPU / device (i.e., TFP) executes its quantum budget and stores the corresponding events in a queue, for example, a FIFO (First In, First Out) type queue. These queues are also called PQEQs (Producer Quantum Event Queues). To avoid unlimited use of the first memory 26, the use of limited queues is preferred, typically by setting the maximum capacity of each queue to the budget quantum multiplied by the number of parallel computing units of the TFP (i.e., the parallelism of event production of the TFP). For each producer, two queues are advantageously associated, one for even quantums and one for odd quantums. Queues whose events have been analyzed and reorganized can be reused. The set of FIFO queues corresponding to all CPUs and peripherals forms a database stored in the first memory 26.A person skilled in the art will observe that more than two queues can be used, in particular to further decouple the first emulators 14 from the second emulators 18, and thus smooth out variations in execution speeds between the first and second emulators 14, 18, and obtain an overall execution speed constrained by the average of the slowest execution speed between that for the first emulators 14 and that for the second emulators 18.

[0191] It should be noted that during this time, the analysis device 28 and the second emulator(s) 18 cannot access the ongoing quantum events of the first emulator(s) 14 until the end of the corresponding quantum. When all events belonging to a TFP interval (common to all TFPs in this example) are emitted and available for analysis, i.e., at the end of the quantum, the analysis device 28 can analyze and rearrange the events according to their timestamp. This ensures that the second emulator(s) 18 receive the events in the correct order.

[0192] For the analysis subphase, all events from all TFPs corresponding to a quantum are available for evaluation at the beginning of this analysis subphase. Events are evaluated based on their timestamp and reordered accordingly before being sent to consumers. Evaluation continues as long as the queues contain events. When all queues corresponding to the same quantum are empty, processing moves on to the next quantum. Processing ends when all queues for the last quantum are empty.

[0193] The implementation of the optional sorting module 40 depends on the choice of data structure used for the first memory 26. For example, if an unordered data structure, such as FIFO queues, has been used, the sorting step is advantageous. In the case of an ordered data structure, such as priority queues, the sorting step is not necessary.

[0194] In this example implementation, the events corresponding to each TFP are ordered by construction and assumed to be time-stamped. Therefore, it is not necessary to implement the 40 sorting module, and simple FIFO queues are used.

[0195] The implementation of the determination module 42 is simplified thanks to the semantics of quantums, which are used to synchronize the TFPs. The reordering intervals are then aligned with the quantums, since the quantums satisfy equation [2] and ensure property [1].

[0196] Figure 6 illustrates, in block diagram form, a possible implementation of the reordering module 44 in this implementation example. Since each producer's event queue (PQEQ) is ordered according to the production time in the guest system, or date of issue (and which must be consistent with the simulated timestamp order), the idea is to track the oldest element in each event queue (the one that was produced first, therefore having the lowest timestamp). Obtaining these events, which are in fact the heads of the different PQEQs, corresponds to block 100 in Figure 6. Then, to determine the oldest event among the different PQEQs, an ordered data structure is used, specifically a priority queue, where the order is defined by the timestamps of the events.This data structure is called IPEQ (Inter Producer Event Queue). The elements of this structure can be either pointers to the heads of the different PQEQs, or directly the events extracted from each PQEQ head. Inserting events (or pointers to events) into 1TPEQ corresponds to block 110. The head of the IPEQ is the oldest event in all the queues, i.e., the different PQEQs, corresponding to the event with the earliest timestamp, and obtaining the head of the IPEQ corresponds to block 120.

[0197] Once the oldest IPEQ event has been sent to the consumers, it is replaced by the next event from the same producer's queue. In [Fig. 6], block 130 corresponds to the selection of the oldest IPEQ event, and block 140 to its sending to consumers EC1, EC2, ..., ECm. In this [Fig. 6], the diamond-shaped block 145 then corresponds to a test to determine whether the event queue corresponding to the event that has just been processed is empty or not.

[0198] If it is not empty (result corresponding to the letter N), the reordering module 44 moves to the next block 150 to obtain the new head of the same PQEQ in order to replace the event processed in the IPEQ, then to block 160 to insert this new head into the IPEQ, before returning to block 120 to obtain the head of the IPEQ. It should be noted that the insertion of a new element into an ordered structure generates an automatic reordering of the structure.

[0199] The test corresponding to block 145 checks whether the current event queue—i.e., the queue corresponding to the event that has just been sent to the consumers—is empty (result corresponding to the letter Y), meaning that all events in the queue for this PQEQ have been consumed. If so, the reordering module 44 proceeds to test block 170 (diamond-shaped) to determine whether this is the end of the respective quantum, or not, in which case there are still events remaining in the various queues of the current quantum.

[0200] If the respective quantum is not finite (result corresponding to the letter N), the reordering module 44 returns to block 120 to process the other IPEQ events (from the other PQEQs). Otherwise, if the respective quantum is finite (result corresponding to the letter Y), that is, if all the PQEQs of this quantum are empty, the reordering module 44 proceeds to test block 180 (diamond-shaped) to determine whether all the quantums have been analyzed or not.

[0201] If there is one or more quantums left to analyze (result of block 180 corresponding to the letter N), the reordering module 44 returns to block 100 to process a new quantum.

[0202] Thus, even if all the events of a PQEQ of a TFP are consumed (result of block 145 corresponding to the letter Y), the reordering step continues with the remaining PQEQs corresponding to other TFPs (arrow looping back from block 170 to block 120). This is repeated until all the PQEQs corresponding to the current quantum are empty (result of block 170 corresponding to the letter Y), which means that all the events of the quantum being evaluated have been processed. At that point, the reordering step can move on to processing the next quantum (arrow looping back from block 180 to block 100), that is, analyzing and reordering the PQEQs of the opposite parity class, provided that all the TFPs have finished executing that quantum.

[0203] Otherwise, if all the quantums have been analyzed (result of block 180 corresponding to the letter Y), there are no more events to process and the reordering phase awaits the provision of new elements by the first emulators.

[0204] It should be noted that the size of the IPEQ is limited by the number of producers, which ensures the efficiency of the insertion and removal operations.

[0205] Figure 7 then illustrates, in a more concrete way, particularly with regard to the contents of PQEQ and IPEQ, the implementation of blocks 100 to 160 of Figure 6, with the example presented in Figure 1 and the QEMU™ emulator. The numbers 100 to 160 indicated in Figure 7 correspond to the blocks in Figure 6 having the same numbers.

[0206] In [Fig. 7], at step a, the PQEQ heads are read or extracted and the IPEQ is initialized with them (step b). Then, using the IPEQ structure, the event with the lowest timestamp is found (it belongs to the PQEQ of the middle TFP and has timestamp ts = 2) and extracted from it (step c), then sent to the EC consumer(s) (step d). Next, the event that is now at the head of the same middle TFP (the one with timestamp ts = 24) is retrieved (step a') to populate the IPEQ (step b'). The event with the lowest timestamp is found (it belongs to the PQEQ of the top TFP and has timestamp ts = 4) and extracted from it (step c'), then sent to the consumer(s) (step d'). Next, the event that is now at the head of the same top TFP (the one with timestamp ts = 6) is retrieved (step a”) to fill the IPEQ (step b”).This iterative process continues until no event is found in either of the PQEQs.

[0207] Fig. 8 shows a possible integration of the processing phase in a decoupled simulation environment, where the ISS running the CPU models runs on one process (thread) and the memory hierarchy models run on another process (thread).

[0208] The left-hand side of [Fig. 8] shows the instruction execution flow of the ISS. In this specific use case, during the interpretation of basic instruction blocks, only memory accesses are instrumented. It should be noted that the implementation described in this figure includes a mechanism for timestamping memory accesses before committing them to the event queues corresponding to the different execution units. [Fig. 8] illustrates the case where a process (thread) operates all the execution units and the scheduling mechanism used is a Round-Robin policy.

[0209] The right-hand side of [Fig. 8] (the left and right sides being separated by two parallel lines diagonally to [Fig. 8]) shows a memory hierarchy model, composed of several levels of caches, among other components, for example interconnects and main memory banks. The first-level caches (L1) constitute the interface between the CPUs and the memory hierarchy.

[0210] Figure 8 shows an example of integration with the QEMU™ emulator, and each first emulator 14 is configured to divide the instruction set to be emulated in the software application into a plurality of instruction sequences. Each first emulator 14 is configured to subdivide each instruction sequence into one or more instruction blocks. Instruction blocks are also commonly referred to as basic blocks or BBs (Basic Black). Each instruction block consists of a series of successive instructions, generally ending with a branch instruction, but without any intermediate branch instructions within said sequence; only the final instruction of said sequence is included. a branch instruction. Each first emulator 14 is configured to associate, with each emulated instruction in an instruction block, a value in an instruction counter. The instruction counter typically depends on the number of instructions contained in one or more instruction blocks preceding the block to which the instruction associated with the counter belongs. Those skilled in the art will observe that the value of the instruction counter is not necessarily different from one instruction to another. When the first emulator 14 is the QEMU™ emulator, the instruction counter is called the icount. Each quantum corresponds to at least one instruction block. The icount is reset at the beginning of each quantum. In Figures 8 and 9, the reference QT (Quantum Time) denotes the quantum time.

[0211] The type of instruction depends on the objective of the simulation of the software application's behavior. For example, to model memory hierarchies, following only memory access instructions is sufficient. This is the case in the examples in Figures 8 and 9, where memory access instructions, denoted "mem", are processed and placed for this purpose in a basic block instruction buffer BB_STK, while other instructions are denoted "instr".

[0212] In [Fig. 8], block 200 corresponds to the detection of the end of a base block, hereafter BB, then block 210 represents the calculation of the timestamps of the events of said BB, and finally block 220 represents the insertion into the PQEQ of the timestamped events of said BB. Those skilled in the art will note that in the implementation illustrated in [Fig. 8], the end of a BB is visible only at the first memory event of the following BB.

[0213] Block 230 then represents the initialization of the IPEQ with the heads of the PQEQs of the current quantum, then block 240 represents the selection of the head of the IPEQ, which is extracted from the corresponding PQEQ and sent to memory 30 (block 250), from which it will be extracted to be sent to (or read by) the consumer(s) EC (block 260).

[0214] Finally, block 270 represents the transition to other events to be processed from the IPEQ, block 280 corresponds to pushing the next event from the same CPU, for processing.

[0215] The circled digits 0, 1, 2, and 4 illustrate the order in which the aforementioned blocks are implemented for the processing phase. Block 230, associated with the circled digit 0, is implemented first, followed by block 240, associated with the circled digit 1, which is itself implemented before block 250, associated with the circled digit 2. Finally, blocks 270 and 280, associated with the circled digit 4, are implemented before proceeding to the next event to be processed. In this example, block 260, associated with the circled digit 3, is not necessarily implemented before blocks 270 and 280, associated with the digit 4, and alternatively, it may be implemented in parallel with blocks 270 and 280, associated with the number 4, given that block 260 associated with number 3 is on a different process (thread) than the process associated with the other blocks corresponding to numbers 0, 1, 2 and 4.

[0216] It should be noted that for this two-thread implementation, where there is no additional thread for the processing phase, it is advantageous to add as many operations as possible to the faster process. This is generally the execution unit process because ISSs, especially those based on Dynamic Binary Translation (DBT), employ inherent abstraction and acceleration mechanisms for maximum efficiency.

[0217] Figure 9 shows a three-process (threaded) variant, where the processing phase in the intermediate part is executed on a separate process. The three processes correspond to the three parts shown in Figure 9, separated from each other by parallel diagonal lines. Quantum processing in the different parts is pipelined, so that each part processes a different quantum. In Figure 9, blocks 200 to 280 correspond to those described previously opposite Figure 8.

[0218] In both cases, those of Figures 8 and 9, the execution unit process (thread) fills a set of execution unit queues with the corresponding events. The process assumes the availability of PQEQ for the current quantum and begins by initializing the IPEQ with the head elements (or pointers to the head elements) of each PQEQ. It is recalled that the events of each PQEQ are assumed to be filled in the order of their timestamp. The head of the IPEQ priority queue corresponds to the oldest event and must be the first to be consumed by the memory hierarchy. Once the event is consumed, that is, sent to be processed by the memory process (thread), it is replaced by the next event of the same PQEQ, and the IPEQ is reordered according to the timestamp of the newly arrived event.

[0219] One variant involves rearranging the events of a quantum on the fly, during the execution of the TFPs of the same quantum, i.e., without waiting for the quantum execution to finish, and using a globally ordered data structure for all the TFPs. However, the event processing by consumers must wait for the end of a quantum (final instant Imax) before beginning to process the events of a quantum in their correct order. This variant requires a large, globally ordered data structure to contain all the events of all the TFPs of the same quantum.

[0220] Another variant is that since the producers run very quickly compared to the processing phase, several host processes (threads) can be used, each process (thread) executing the processing phase for one quantum. In other words, what is expensive in terms of execution time is the processing phase, and it can then It can be advantageous to have multiple instances of this processing phase, implemented in parallel and started as soon as the data is available. Consequently, the decoupling between the execution of EP producers and EC consumers can be greater than one quantum. Therefore, multiple event queues per producer would be necessary to ensure that EP producers can write to the event queues without memory protection, and that the event queues processed by the processing phase include all events of a single quantum. However, this solution would lead to the accumulation of a large number of quantum-sized events.

[0221] The invention advantageously relates to online simulation, that is, when the software application runs and interacts with the user in real time. However, those skilled in the art will observe that the principles of the invention also apply to offline simulations, that is, when simulators generate traces by running one or more complete software applications and store the traces, which serve as input for other simulators.

[0222] It is thus understood that the management process and the management system 20 according to the invention make it possible to better manage a plurality of event streams emulated by a plurality of event producers.

Claims

Demands

1. A method for managing the event streams of software application(s), emulated by a set (12) of first emulator(s) (14), the set (12) of first emulator(s) (14) comprising a plurality of event producers (EP) emulating a plurality of event streams, the method being implemented by an electronic management system (20) and comprising a processing phase carried out iteratively for successive event streams, the processing phase - carried out for each respective event stream - comprising the following steps: - acquiring (ACQ) a current event stream from the event producers (EP); the current event stream including a current sequence of event(s) for each event producer (EP), each event having a respective date, defined with respect to an emulated clock common to the event producers (EP);- determine a current reordering interval (RI) between an initial time (Imin) and a final time (Imax); - reorder events within the determined current reordering interval (RI), the events to be reordered being all acquired events whose date belongs to the current reordering interval (RI) and the events being reordered according to their respective dates; - storage of the reordered events in a memory (30) for use by a set (16) of second emulator(s) (18), the set (16) of second emulator(s) (18) comprising a plurality of event consumers (EC).

2. A method according to claim 1, wherein the initial time (Imin) of the current interval is equal to the final time (Imax) of a previous interval determined during a previous iteration for a previous stream of events, and the initial time (Imin) of the reordering interval (RI) associated with the first stream of events is a predefined initial value.

3. A method according to claim 1 or 2, wherein each current sequence from a respective producer (EP) has a maximum date greater than or equal to the latest date among the date(s) of the event(s) in the sequence, and the final time (Imax) of the current interval is equal to the minimum of the maximum dates of the current acquired sequences.

4. A method according to any one of the preceding claims, wherein the events of the current stream whose date is later than the final instant (Imax) of the current reordering interval (RI) are reordered during a subsequent iteration for a subsequent stream of events.

5. A method according to any one of the preceding claims, wherein, during the acquisition step (ACQ), the current stream of events is recorded in a first memory (26), and the memory (30) in which the events reordered during the storage step are stored is a second memory (30), distinct from the first memory (26).

6. A method according to any one of the preceding claims, wherein the processing phase further comprises, after the storage step, a feedback (RET) step of information to the set (12) of first emulators (14), to inform the set (12) of first emulators (14) of a time lag between these first emulators (14) due to the evaluation of the behavior of the set (16) of second emulator(s) (18).

7. A method according to any one of the preceding claims, wherein the method further comprises, prior to the processing phase, a configuration phase (CONF) in which each event producer (EP) is configured to emulate successive sequences of event(s), where the event(s) of each sequence have dates belonging to a respective sequence interval; and for each respective event producer (EP), two successive sequence intervals of said producer (EP) are contiguous and disjoint from each other.

8. A method according to any one of the preceding claims, wherein if the events of at least one running sequence have disordered dates, the processing phase further comprises a step of classifying the events according to their respective dates for each of the at least one running sequence; the classifying step being preferably carried out between the acquisition step and the determination step.

9. A computer program comprising software instructions which, when executed by a computer, implement a method according to any one of the preceding claims.

10. Electronic system (20) for managing the flow of software application(s) events, emulated by a set (12) of first emulator(s) (14), the set (12) of first emulator(s) (14) comprising a plurality of event producers (EP) emulating a plurality of event flows, the system (20) comprising: - an acquisition module (24) configured to acquire a current flow of events from the event producers (EP); the current flow of events including a current sequence of event(s) for each event producer (EP), each event having a respective date, defined with respect to an emulated clock common to the event producers (EP); - a determination module (42) configured to determine a current reordering interval (RI) between an initial time (Imin) and a final time (Imax);- a reordering module (44) configured to reorder events within the determined current reordering interval (RI), the events to be reordered being all acquired events whose date belongs to the current reordering interval (RI) and the events being reordered according to their respective dates; - a storage module (46) configured to store reordered events in a memory (30) for use by a set (16) of second emulator(s) (18), the set (16) of second emulator(s) (18) comprising a plurality of event consumers (EC); the acquisition (24), determination (42), reordering (44) and storage (46) modules being implemented for each respective stream of events, iteratively for successive streams of events.

11. System (20) according to claim 10, wherein the system (20) further comprises a feedback module (32) configured to provide feedback to the set (12) of first emulators (14).

12. System (20) according to claim 10 or 11, wherein the system (20) further comprises a configuration module (22) capable of configuring each event producer (EP) to emulate successive sequences of event(s), where the event(s) of each sequence have dates belonging to a respective sequence interval; and for each respective event producer (EP), two successive sequence intervals of said producer are contiguous and disjoint from each other.

13. Electronic emulation installation (10) comprising: - a set (12) of first emulator(s) (14) comprising a plurality of event producers (EP); - a set (16) of second emulator(s) (18) comprising a plurality of event consumers (EC); - an electronic system (20) for managing the flow of software application(s) events, emulated by the set (12) of first emulator(s) (14), the electronic management system (20) being according to any one of claims 10 to 12 and being connected between the set (12) of first emulator(s) (14) and the set (16) of second emulator(s) (18).

Images