Method and electronic system for instruction timing during software application emulation

Abstract

Method and electronic system for timing instructions during the emulation of a software application. The present invention relates to a method for timing instructions from among a set of instructions of a software application, emulated during the emulation of said software application by an emulator (12), the method being implemented by an electronic timing system and comprising the following steps: determination of at least one type of instruction to be timed; definition (120) of a time interval between a start time and an end time obtained from the emulator (12), the time interval corresponding to a sequence of successive instructions emulated by the emulator (12) between the start time and the end time; acquisition, (130) from the sequence of instructions, of the instructions corresponding to said at least one type and according to the order of execution;dating (160) of the acquired instructions by estimating for each of said instructions an execution time, each estimated execution time being included in the time interval, the estimated execution times of the acquired instructions being calculated as a function of the number of acquired instructions. Figure for the abbreviation: Figure 5;

Description

Title of the invention: Method and electronic system for timing instructions during the emulation of a software application

[0001] The present invention relates to a method for dating instructions among a set of instructions of a software application, emulated during an emulation of said software application by an emulator, the method being implemented by an electronic dating system.

[0002] The invention also relates to such an electronic system for timing instructions among a set of instructions of a software application, emulated during an emulation of said software application by an emulator.

[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 drifts, 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.

[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] In order to provide a better picture of the temporal behavior of the simulated software application, prior art emulators are instrumented to measure different aspects of the software application's behavior. This instrumentation makes it possible to extract information dynamically during program emulation that is useful for functional or extrafunctional evaluation.

[0006] By way of example, the QEMU (Quick Emulator) emulator provides a virtual model of a target hardware architecture on which to run a software application. During preprocessing, the QEMU emulator divides the set of instructions of the software application to be emulated into a plurality of instruction blocks, Also called basic blocks, or BBs (from the English Basic Black), a block of instructions corresponds to a sequence of successive instructions ending with a branch instruction, while not including any intermediate branch instructions within said sequence; only the final instruction of said sequence is a branch instruction. The QEMU emulator is configured to provide a count of the number of emulated instructions at the end of each respective basic block and an estimated execution time for said basic block.

[0007] However, such an emulator does not give complete satisfaction.

[0008] The aim of the invention is then to propose a method of timing instructions allowing to provide a more precise image of the temporal behavior of an emulated software application.

[0009] To this end, the invention relates to a method for dating instructions from among a set of instructions of a software application, emulated during an emulation of said software application by an emulator, the method being implemented by an electronic dating system and comprising the following steps:

[0010] - determination of at least one type of instruction to be dated;

[0011] - definition of a time interval between a start time and an end time end obtained from the emulator, the time interval corresponding to a sequence of successive instructions emulated by the emulator between the start time and the end time;

[0012] - acquisition, from the sequence of instructions, of the instructions corresponding to said at least one type and according to the order of execution;

[0013] - dating of acquired instructions by estimating for each of said instructions an execution time, each estimated execution time being included in the time interval, the estimated execution times of the acquired instructions being calculated based on the number of acquired instructions.

[0014] The estimated time of execution of the acquired instructions makes it possible to obtain a more precise picture of the temporal behavior than the mere start and end times of each time interval.

[0015] For example, when each time interval corresponds to the execution of a block of instructions, the timestamping method according to the invention then makes it possible to estimate execution times for instructions within the block of instructions. Thus, the detection of instructions causing or likely to cause potential contentions or timing drifts is facilitated.

[0016] Furthermore, determining at least one type of instruction to be timestamped allows the selection of the types of instructions for which timestamping is necessary, depending on the objective of the simulation of the software application's behavior. Thus, the temporal behavior model provided by the method is more easily interpreted.

[0017] Moreover, when the set of dated instructions is strictly smaller than the set of all instructions in the software application, the instrumentation of a reduced subset of instructions makes it possible to limit the slowdown of emulation induced by the instrumentation of instructions.

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

[0019] - the instruction set is emulated by the emulator in a total duration of emulation, the total emulation time being divided into a plurality of successive time intervals, the time intervals are contiguous and the estimated times of execution are of increasing value from one time interval to the next;

[0020] - the estimated execution times are increasing according to the order of execution of the instructions acquired in the time interval;

[0021] - the estimated execution times are calculated according to a uniform distribution, the uniform distribution depending on the number of instructions acquired in the instruction sequence corresponding to the time interval;

[0022] - the estimated execution times are calculated according to a fixed-step distribution, the difference between two estimated successive execution times of a respective time interval being equal to the fixed step;

[0023] - the acquisition of instructions corresponding to said at least one type includes the acquisition of at least one execution context piece of information for each instruction, with the estimated execution times further calculated based on at least one execution context piece of information;

[0024] at least one execution context information preferably comprising at least one element from the group consisting of: an execution latency, a frequency of a processor intended to execute the software application, an instruction counter, and an end-of-quantum indicator;

[0025] - the instruction set comprises successive blocks of instructions, each block instructions being emulated from an estimated start time of execution, the estimated start time of a current block of instructions being less than the estimated start time of a subsequent block of instructions;

[0026] - the dating of the acquired instructions is followed by a transmission step of the sequence of instructions and estimated execution times to an additional emulator external to the emulator;

[0027] - the timestamping of the instructions acquired for a current sequence of instructions is performed simultaneously with the acquisition of instructions from one or more subsequent sequences of instructions, each subsequent sequence of instructions corresponding to instructions emulated during a respective subsequent time interval, subsequent to a current time interval corresponding to the current instruction sequence; and

[0028] - the timestamp of the instructions acquired for the current instruction sequence is performed simultaneously with the definition of the time interval for one or more subsequent sequences of instructions.

[0029] The invention also relates to an electronic system for timing instructions among a set of instructions of a software application, emulated during an emulation of said software application by an emulator, the electronic timing system comprising:

[0030] - a determination module configured to determine at least one type instruction to be dated;

[0031] - a definition module configured to define a time interval between a start time and end time obtained from the emulator, the time interval corresponding to a sequence of instructions emulated by the emulator between the start time and the end time;

[0032] - an acquisition module configured to acquire from the sequence of instructions, instructions corresponding to said instructions of at least one type and according to the order of execution; and

[0033] - a dating module configured to date acquired instructions by estimating for each of the said instructions an execution time, each estimated execution time being included in the time interval, the estimated execution times of the acquired instructions being calculated based on the number of acquired instructions.

[0034] According to other advantageous aspects of the invention, the electronic dating system includes the following feature: the instruction set comprises successive instruction blocks, each instruction block being emulated from an estimated start time, and the system further comprises an increment module configured to increment the estimated start times, the estimated start time of an instruction block being less than the estimated start time of the next instruction block.

[0035] 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:

[0036] [Fig-1] [Fig.1] is a schematic representation of a dating system instructions according to the invention;

[0037] [Fig.2] [Fig.2] is a schematic representation of an example of evolution estimated execution times of several instruction sequences respectively according to the prior art, following an increment according to the invention of the estimated execution times of one sequence to the next, and following a timestamping according to the invention of the estimated execution times within each sequence,

[0038] [Fig.3] [Fig.3] is a view of several time distribution chronograms - according to the dating according to the invention - of estimated execution times within a time interval corresponding to a respective sequence of instructions, in comparison to the prior art where all instructions in the sequence have an estimated execution time equal to the start time of the sequence; each chronogram representing the successive estimated execution times of instructions acquired from the sequence of instructions;

[0039] [Fig.4] [Fig.4] is a view of two curves representing the temporal behavior of the emulated software application, respectively according to the prior art and following the incrementation according to the invention; and

[0040] [Fig. 5] [Fig. 5] is a flowchart of a method for dating instructions, put implemented by the dating system of [Fig.1].

[0041] In [Fig.1], an electronic emulation installation 10 includes an emulator 12, also called the first emulator 12, an electronic dating system 14 and an additional emulator or simulator 16, also called the second emulator 16.

[0042] The emulation installation 10 is configured to emulate a software application, i.e. to simulate the execution of the software application on a target hardware architecture, the target hardware architecture being modeled to reproduce the behavior of the hardware architecture when the software application is executed.

[0043] The software application includes a set of instructions, some or all of which are dateable. In other words, a set of dateable instructions is included within the software application's instruction set. Advantageously, the set of dateable instructions is strictly smaller than the set of all instructions in the software application.

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

[0045] 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 dated 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).

[0046] 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.

[0047] 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.

[0048] Each instruction belongs to an instruction set associated with the target hardware architecture.

[0049] The first emulator 12 is configured to emulate the software application. The first emulator 12 is typically configured to provide the instructions and the order of execution of the instructions to the timing system 14. In other words, the first emulator 12 is configured to provide a sequence of instructions 20 executable by the target hardware architecture, as shown in the first column from the left in [Fig.2].

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

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

[0052] The first emulator 12 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).

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

[0054] More generally, the first emulator 12 is any instruction set simulator, also called an ISS (from the English Instruction Set Simulator), instrumented to provide sequences of instructions in their emulation order.

[0055] In addition, during preprocessing or on-the-fly processing, the first emulator 12 is configured to divide the set of instructions to be emulated in the software application into a plurality of instruction sequences. Furthermore, the first emulator 12 is configured to subdivide each instruction sequence into one or more instruction blocks. These instruction blocks are also generally called basic blocks or BBs (from the English "Basic Block").

[0056] Each instruction block corresponds to a sequence of successive instructions generally ending with a branch instruction, but without including any intermediate branch instructions within said sequence; only the final instruction of said sequence is a branch instruction. Consequently, if the processor executes the first instruction of the basic block, it must necessarily execute the basic block to its end.

[0057] The first emulator 12 is configured to associate, with each emulated instruction in a block of instructions, a value in an instruction counter. The instruction counter typically depends on the number of instructions contained in one or more blocks of instructions 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.

[0058] When the first emulator 12 is the QEMU emulator, the instruction counter is called the icount. The icount associates with each block of instructions an integer corresponding to the number of emulated instructions before the start of the emulation of that block of instructions. In addition, the QEMU emulator divides the set of emulated instructions into quantums, via the definition of 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 (Central Processing Unit), before handing control over to another emulated processor to execute another quantum, and so on. In other words, a quantum is a notion of duration, typically expressed either in units of time (e.g., seconds), or in cycles, or in instruction counter values. Each quantum corresponds to at least one block of instructions.The icount counter is reset at the beginning of each quantum. An example of an icount counter for an instruction sequence is shown in a second column 22 in [Fig.2], corresponding to the prior art.

[0059] The dating system 14 is for example an extension of the first emulator 12.

[0060] In the example of [Fig. 1], the electronic dating system 14 comprises a a determination module 30, a definition module 32, an acquisition module 34, a dating module 36, an incrementation module 38 and a transmission module 39.

[0061] In addition, the dating system 14 includes a database 44.

[0062] The database 44 is configured to store the instructions emulated by the first emulator 12 in execution order. For example, the database 44 is configured to store the instruction sequence 20 as the instruction set is emulated. In one embodiment, the database 44 does not store the entire instruction sequence 20, but only the instructions selected according to the instruction type determined by the determination module 30.

[0063] The electronic dating system 14 is formed for example of a memory 40 and one or more processors 42 associated with the memory 40. The processor(s) 42 and the memory 14 can also be shared with those required for the emulator 12 or the second emulator 16.

[0064] The determination module 30, the definition module 32, the acquisition module 34, the dating module 36, the incrementing module 38 and the transmission module 39 are implemented as one or more software programs, or a software component, executable by the processor 42. The memory 40 is then capable of storing determination software, definition software, acquisition software, dating software, incrementing software and transmission software, as well as the database 44. The processor 42 is then capable of executing the determination software, the definition software, the acquisition software, the dating software, the incrementing software and the transmission software.

[0065] In an alternative not shown, the determination module 30, the definition module 32, the acquisition module 34, the dating module 36, the increment module 38 and the transmission module 39 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).

[0066] When the determination module 30, the definition module 32, the acquisition module 34, the timing module 36, the incrementing module 38, and the transmission module 39 are implemented as one or more software programs, i.e., as a computer program, it is also capable of being stored 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. For 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 comprising software instructions is then stored on the readable medium.

[0067] The determination module 30 is configured to determine at least one type of instruction to be dated.

[0068] The type of instruction to be dated is determined according to the objective of the simulation of the behavior of the software application.

[0069] For example, to model memory hierarchies, following only the memory access instructions is sufficient. This is the case in the example in [Fig.2] where the memory access instructions denoted "mem" are dated, the other instructions being denoted "instr".

[0070] In addition or alternatively, the determination module 30 is configured to determine a plurality of instruction types to be dated. For example, if the objective of the simulation is to monitor the performance of the modeled execution unit, it is advantageous to date several different instruction types in order to obtain additional dating information.

[0071] The definition module 32 is configured to define a time interval between a start time TIinter and an end time TFinter. By way of example, a time interval corresponds to a set of instructions having the same instruction counter value, such as the same icount counter value, at the time of the analysis of the instruction sequences to be time-stamped, which are the instructions observable by the definition module 32. Thus, as illustrated in [Fig. 2], the first interval corresponds to the base block BB0. The second interval corresponds to the base blocks BB1 and BB2, because there are no instructions of the type(s) to be time-stamped (the mem type in this example) in the base block BB2, which is therefore not discernible by the definition module 32.

[0072] The instruction set is emulated by the first emulator 12 in a total emulation time ttot, the total emulation time ttot being divided into a plurality of successive time intervals.

[0073] The time intervals defined by the definition module 32 are preferably contiguous. In other words, the end time TFinter of a current time interval corresponds to the start time TIinter of the following time interval; and so on until the total emulation time ttot is reached.

[0074] The time interval corresponds to a sequence of successive instructions emulated by the first emulator 12 between the start times TIinter and the end times TFinter of said time interval.

[0075] Each instruction sequence is included in the instruction execution trace of the emulated software application. Each instruction sequence comprises at least the instructions of the type to be started from one or more successive instruction blocks.

[0076] Preferably, each instruction sequence comprises a single block of instructions. According to this preference, each instruction sequence typically consists of a single block of instructions.

[0077] In the case where the first emulator 12 is a QEMU emulator, the time interval is for example a block of instructions, i.e. a basic block; or a quantum typically comprising several basic blocks.

[0078] The sequence of instructions, as well as the start time TIinter and the end time TFinter, can be determined from the elements provided by the first emulator 12.

[0079] The start time TIinter and the end time TFinter of each interval are, for example, determined from the instruction counter of each instruction block, provided by the first emulator 12.

[0080] In the examples in Figures 2 to 4, the first emulator 12 is the QEMU emulator and the instruction sequence includes a single block of instructions.

[0081] In the example of [Fig.2], each sequence of instructions or block of instructions BB0, BB1, BB2 and BB3 comprises four, five, three and four instructions respectively.

[0082] The acquisition module 34 is configured to acquire certain instructions from the sequence of instructions corresponding to the defined time interval, and according to the execution order. The type of each acquired instruction is identical to the instruction type to be dated, determined by the determination module 30, or is identical to at least one of the instruction types to be dated if the determination module 30 has determined several instruction types. The acquisition module 34 is, for example, configured to acquire said instructions from the database 44.

[0083] The person skilled in the art will observe that different embodiment variants are possible for the acquisition by the acquisition module 34 of the instructions of the type or types determined by the determination module 30.

[0084] According to a first embodiment, the acquisition corresponding to the filtering, i.e., the selection, of instructions according to the determined type and the retrieval of said instructions is carried out in a single global step, the said instructions being both filtered and retrieved for storage in the database 44 during this step. The acquisition module 34 is then configured to both filter the instructions according to the determined type and retrieve them from the sequence, for storage in the database 44.

[0085] According to a second embodiment, said acquisition is carried out in two steps, namely, first filtering the instructions according to the determined type, and then retrieving the previously filtered instructions. The acquisition module 34 is then configured to first filter, that is, select, the instructions according to the type determined by the determination module 30; then later to retrieve the emulated instructions resulting from this filtering.

[0086] According to a third embodiment, the acquisition is again performed in two steps, but in the reverse order of the second embodiment mentioned above, namely, first the retrieval of the instructions, and then the filtering according to the determined type of the previously retrieved instructions. The acquisition module 34 is then configured to first retrieve all the emulated instructions of the sequence and store them in the database 44; and then to filter—within the database 44—the retrieved instructions according to the type determined by the determination module 30.

[0087] In the example in [Fig.2], the acquisition module 34 is configured to acquire only memory access instructions, denoted "mem".

[0088] The acquisition module 34 acquires a number C of instructions corresponding to at least one type to be dated for each defined time interval.

[0089] In the example in [Fig. 2], the acquisition module 34 successively acquires two "mem" instructions within a first interval corresponding to instruction block BB0; two "mem" instructions within a second interval corresponding to instruction blocks BB1 and BB2; and four "mem" instructions within a third interval corresponding to instruction block BB3. The ends of the intervals can be detected by a change in the value of the icount counter associated with each instruction acquired by the acquisition module 34.

[0090] Alternatively, the acquisition module 34 is configured to acquire all the instructions included in the instruction sequence, the acquisition module 34 being further configured to identify the instructions corresponding to the type to be dated.

[0091] In addition, the acquisition module 34 is configured to acquire, for each acquired instruction, a set E comprising at least one execution context piece of information for said instruction. This at least one execution context piece of information includes, for example, at least one element from the group consisting of: an execution latency of previous instructions, a frequency of a processor intended to execute the software application, an instruction counter, and an end-of-quantum indicator. The set of information E is, for example, stored by the database 44 and transmitted by the first emulator 12.

[0092] The dating module 36 is configured to date the acquired instructions by estimating for each of said instructions an execution time ts.

[0093] The acquired instructions are provided by the acquisition module 34 and correspond to at least one type of instruction to be dated.

[0094] The estimated execution times ts are typically increasing according to the execution order of the instructions acquired in the time interval. In other words, a first instruction is emulated before a second instruction during emulation. will have an estimated execution time ts less than or equal to the estimated execution time ts of the second instruction, the first and second instructions belonging to the same sequence of instructions.

[0095] Each estimated execution time ts is included in the time interval. In other words, each estimated execution time ts is between the start time TIinter and the end time TFinter of the time interval considered.

[0096] The execution times ts preferably correspond to a quantized instant of the time interval, i.e., a sampled instant or a discretized instant of the time interval. For example, a quantized instant can be a number of processor execution cycles.

[0097] The estimated execution times ts of the instructions acquired from a sequence of instructions are calculated as a function of the number C of instructions acquired.

[0098] According to the addendum where the acquisition module 34 also acquires, for each acquired instruction, the set E of execution context information, the estimated execution times ts are further calculated based on the information contained in each set E, in particular based on the execution latency of previous instructions; the frequency of the processor intended to execute the software application, i.e., the clock frequency of the emulated processor; the instruction counter; and / or the end-of-quantum indicator. Thus, the image of the temporal behavior of the software application in the hardware architecture provided by the emulation installation 10 takes into account one or more of these execution context pieces of information.

[0099] In the example in [Fig. 2], the first quantum contains three base blocks BB0, BB1, and BB2, the last of these three base blocks, BB2, not containing an instruction of the type to be dated. This base block, BB2, is therefore not taken into account by the dating system 14, and the next instruction of the type to be dated is the first instruction of the following quantum, after the value of the counter icount has been reset. The dating system 14 then observes a single interval that takes into account the effects of the instructions in base blocks BB1 and BB2, which results in an interval length L of 8, since the change in the value of the counter icount at the level of base block BB2 is not visible.

[0100] To improve the consideration of the impact of the last basic blocks of a quantum, even if these basic blocks do not contain an instruction of the type(s) to be dated, the first emulator 12 advantageously provides the dating system 14, at the end of each quantum, with the end-of-quantum indicator, and even, in addition, the total number of instructions that were executed during the elapsed quantum. This makes it possible to improve the dating of instructions even if there is an unknown number of basic blocks that do not contain an instruction of the type to be dated.

[0101] Those skilled in the art will note that in the second quantum, denoted Quantum 1, of the example in [Fig. 2], the first basic block BB3 starts with a non-zero value in the icount counter. This illustrates the case where some emulators allow a quantum to exceed its instruction budget in special cases, for example, when a basic block starts before, or finishes after, the instruction budget. The difference is then accounted for as an offset or compensation at the beginning of the next quantum.

[0102] Another case where the end-of-quantum indicator is advantageous is where the value of the counter icount increases from one date-type instruction to the next, despite a change of quantum between these two date-type instructions.

[0103] That being said, a person skilled in the art will understand that when the instructions of the type to be dated are frequent and / or the quantums are sufficiently large and of substantially constant size, known from the dating system 14, the instructions of the type to be dated, i.e. the monitored instructions, are sufficiently numerous for each quantum so that the transition from one quantum to the next, i.e. the change of quantum, is detectable from the only decrease in the value of the instruction counter, such as the icount counter, for the monitored instructions, without it being necessary to use an end-of-quantum indicator.

[0104] Among the set E of execution context information, the frequency of the emulated processor is used, for example, to calculate a value for the time step At, the time step At being typically equal, up to numerical rounding, to the inverse of the frequency of the emulated processor. The value of the instruction counter, such as the counter icount, is used, for example, to determine a value for the start time TIinter, the start time TIinter being, for example, equal to the product of the instruction counter value and the time step At. The quantum end flag is used, for example, to more easily detect a quantum change as described above, such a quantum change being used, for example, to calculate a value for the length L of the time interval. The average duration of an instruction can be used to determine the execution time from the counter icount.This value can be estimated from an IPC (instructions per cycle) value, commonly accepted for certain architectures. The average instruction time typically corresponds to a ratio of the icount counter divided by the IPC value. As an example, latencies related to the memory hierarchy can also be determined; these could then be added to the instruction times, each latency typically adding to the duration of a corresponding instruction, i.e., the ratio of the icount counter divided by the IPC value.

[0105] In the example in [Fig. 3], the dating module 36 is configured to calculate the estimated execution times ts following a uniform distribution, the uniform distribution depending on the number C of instructions acquired in the instruction sequence corresponding to the time interval.

[0106] The timing module 36 is further configured to determine a number L of quantized instants within the time interval. The time step At between two quantized instants typically corresponds to the basic time unit that the emulation installation 10 uses to model the progression of time. The time elapsed between the start instant TIinter and the end instant TFinter is therefore equal to L * At, where L is a natural number. The time step At is typically the processor's duty cycle, i.e., the duration of one period of its clock frequency. For example, a processor clocked at 2 GHz would have a time step of 0.5 ns.

[0107] The estimated execution times ts of the acquired instructions are then each equal to one of the quantized times. When the first emulator 12 is a QEMU emulator, the number L of quantized times typically depends on the counter icount.

[0108] In [Fig. 3] at the top, a first group 50 of timing diagrams represents the temporal distribution of estimated execution times within a time interval for three different instruction sequences, according to the prior art. Each sequence corresponds to a configuration (a), (b) or (c) with an associated timing diagram from the first group 50.

[0109] On the timing diagrams of the first group 50, all acquired instructions have an estimated execution time ts identical and equal to the start time TIinter of the time interval.

[0110] On a second group 60 of chronograms at the bottom of [Fig. 3] corresponding to the dating according to the invention, the estimated execution times ts are distributed according to a respective uniform distribution over the number L of quantified times included in the time interval. On [Fig. 3], the number L of quantified times is equal to 5.

[0111] In configuration (a) and configuration (b), the number C of acquired instructions is less than or equal to the length L of the time interval. In particular, in configuration (a), the number C of acquired instructions is equal to L, i.e., L = C = 5; and in configuration (b), the number C of acquired instructions is less than L, here C = 3 < L = 5. In configuration (c), the number C of acquired instructions is greater than the length L of the time interval, here C = 13 > L = 5.

[0112] In these configurations (a), (b) and (c), the dating module 36 according to the invention is configured to determine a date D;, the date D; corresponding to an estimated time ts of execution of an instruction of index i, expressed for example as an integer number of time steps At from the start time TIinter of the corresponding time interval.

[0113] The date D; satisfies, for example, the following equation:

[0114] [1] [01151 D^TI^ + floor^y^t

[0116] where D is the estimated date,

[0117] TIinter is the starting time of the corresponding time interval,

[0118] i is an element in the set {0, 1, ..., Cl} corresponding to the index of the instruction in the interval,

[0119] L is the length of the time interval,

[0120] C is the number of instructions to be time-stamped within the time interval,

[0121] floor is the floor function, also called the lower floor function (from the English word floor), and

[0122] At is the time step.

[0123] In configuration (a), L = C = 5, and according to the preceding equation [1], the estimated execution time satisfies A Tinter + floor = TIinter + ï* A t- Thus the estimated execution value The time of the first acquired instruction Do is thus equal to TIinter, the estimated time of the second acquired instruction D1 is equal to TIinter + At. And successively until the last acquired instruction D4 = TIinter + 4* At.

[0124] In configuration (b), L = 5 and C = 3, and according to the preceding equation [1], the estimated execution time satisfies / ). _ j'y + floor * A / • The estimated execution time of the first acquired instruction D() is thus again equal to TIinter. For subsequent instructions, their times are evaluated as follows: • = TIinter + A t car fiOOr (IaA) _ (1.66.) = 1 • A = TIinter + -'* A t car ffoor ( - floor (3.33.) =3

[0125] In configuration (c), L = 5 and C = 13, and according to the preceding equation [1], the estimated execution time satisfies [) _ yy + floor ( At- The estimated execution time of the first acquired instruction Do is thus always equal to TIinter. For subsequent instructions, their times are evaluated as follows: . = TIinter car fioor (1^2) = floor (0.38.) =0 • A = Attempt because floor ( ) = floor ( 0.76. ) = 0 * H3-TIinter+ f car f loor ( ) -floor .15.) = 1 • A = TIinter + A t car floor ( ^ ) = floor ( 1.53. ) = 1 • D5 = TIitlter+At car fioorCA^.^ - fioor = 1 • = + At car fioorÇèfA'j = ffoor (2.30.) =2 D^TI^+2* At carfloor^-y^] =■ floor(2.69.) =2 • D* = TIinter + 3* A t car floor ( ^ ) = floor ( 3.07. ) = 3 D9 = TIinter + 3* At car fioor ( = floor ( 3.46.. ) = 3 Dw=TI^er + 3*car floOr(^) = TIintcr+4* A t car f^r ( -^ ) = floor ( 4.23. ) = 4 ^12 - TIinter+4- A t car floor ( _ floor (4.61..) =4

[0126] It should also be noted that, in any case considered, no estimated execution time is equal to TFinter = TIiater + L* A t. Indeed, the estimated time of the last instruction is Dc i = TIinter + floor (1 < TIinter + L* A 6 VL€ e N'

[0127] According to another embodiment, the estimated execution times ts are calculated according to a fixed-step distribution. The difference between two successive estimated execution times of a respective time interval is equal to the fixed step. The estimated execution times ts are calculated one by one from the start time TIinter, or respectively from the end time TFinter, by adding or respectively subtracting the fixed step. If the product of the number C of acquired instructions and the fixed step is greater than the duration of the time interval, three implementations are technically feasible. According to a first implementation, the fixed step is reduced until the set of acquired instructions can have an estimated execution time ts included within the considered time interval.According to a second implementation, instructions whose estimated execution time ts, calculated without correction, is not included in the time interval are packaged and associated with a single estimated execution time, for example, the last time preceding the TFinter end time. According to a third implementation, the instructions are retained and then appended to the beginning of the instructions in the next interval.

[0128] The increment module 38 is configured to estimate a start time ts' of an instruction block.

[0129] The estimated start times of execution ts' depend for example on the number of instructions included in the preceding blocks of instructions.

[0130] In addition, the increment module 38 is configured to increment the estimated start times ts' of one instruction block to the next. The estimated start time ts' of a current instruction block is then less than the estimated start time ts' of the following instruction block. This incrementation can occur before or after the processing performed by the timestamping module 36.

[0131] Thus, the estimated start times of execution ts' are increasing until they reach the total execution time ttot, as represented by the curve 80 at the bottom of [Fig.4].

[0132] The estimated start time ts' of a current block of instructions is equal to the sum of the estimated start time ts' of the previous block and the execution time of the previous block.

[0133] The increment module 38 then generates a continuous increase in the start times of execution ts', in particular from one quantum to the next, as seen in a third column 24 in [Fig.2], while at the output of the QEMU emulator the counter icount is reset at each start of quantum, as illustrated in the second column 22 in [Fig.2] and in the curve 70 at the top of [Fig.4].

[0134] The increment module 38 thus allows a growth of the estimated execution times ts, calculated by the dating module 36 from one time interval to the next.

[0135] In other words, according to this addition, the estimated execution times ts are incremented from one time interval to the next, without resetting the estimated execution time at the beginning of each time interval. Thus, the estimated execution times ts for instructions in a current time interval are less than the estimated execution times ts for instructions in a time interval subsequent to the current time interval.

[0136] In addition, when the increment is performed after the timestamping, the increment module 38 is configured to update all estimated execution times ts of each instruction within each time interval whose estimated start time ts' it increments.

[0137] The transmission module 39 is configured to transmit the dated instructions to the second emulator 16.

[0138] In particular, the transmission module 39 transmits all the instructions according to the order of execution, each instruction being associated with its calculated estimated time of execution.

[0139] In addition, the transmission module 39 is configured to remove from database 44 the instructions transmitted to the second emulator 16, in order to save space in database 44.

[0140] The second emulator 16 is configured to simulate the behavior of the set of dated and ordered instructions on a complementary model of the target architecture.

[0141] The second emulator 16 is, for example, an external emulator to the first emulator 12. The second emulator 16 is then distinct from the first emulator 12 and is also called an additional emulator. The second emulator 16 is, for example, an extra-functional simulator. Compared to functional simulators, which provide a program view for functional validation purposes, extra-functional simulators allow for the modeling of extra properties. Functional parameters, such as performance, power, surface area, thermal performance, etc., are used to provide system designers with feedback on the effects of architectural choices, thereby optimizing the architecture's suitability for the target application. Examples of such architectural choices include the memory hierarchy structure, processor cache parameters, and communication network parameters.

[0142] Alternatively, the second emulator 16 is the first emulator 12, which allows for a loop.

[0143] A method for dating instructions among the instruction set of the software application by the dating system 14 will now be described with reference to [Fig.5].

[0144] During a first step 100, at each new emulated instruction, the first emulator 12 transmits the emulated instruction and a counter providing an indication of the order of execution.

[0145] When the first emulator 12 is the QEMU emulator, it transmits the emulated instruction and the icount associated with said instruction.

[0146] In a second step 110, the dating system 14 stores the data transmitted by the first emulator 12 in the database 44. Thus, in the database 44 is formed the sequence of instructions 20 and the first column 22 of the [Fig.2].

[0147] In a third step 120, the definition module 32 extracts the last instruction stored in the database 44 during step 110, and determines whether said instruction allows a complete time interval to be defined, that is to say whether said instruction is the first instruction of a new sequence of instructions, determining the end of the previous sequence.

[0148] If the extracted instruction does not allow a complete time interval to be defined, step 120 is repeated for each new instruction emulated and stored in database 44 until a complete time interval is obtained, which will then be defined between respective start times TIinter and end times TFinter.

[0149] The start time TIinter is equal to the counter icount of the first instruction transmitted by the first emulator 12 during the first step 100 in the case of a QEMU emulator. Subsequently, the start time TIinter corresponds to the last end time TFinter defined during a previous step 120.

[0150] If the extracted instruction is the first of a new sequence of instructions, determining the end of the previous sequence, called the current instruction sequence, then the fourth step 130 is carried out.

[0151] During step 130, the acquisition module 34 acquires, from the current instruction sequence, instructions corresponding to at least one type determined by the determination module 30.

[0152] The acquired instructions are extracted from database 44. The acquired instructions are arranged according to the order of execution.

[0153] Those skilled in the art will observe that the example in [Fig. 5] corresponds to the case where the acquisition is carried out in two steps and according to the third embodiment, namely, first the retrieval 110 of the instructions, and then the filtering 130 according to the determined type of the previously retrieved instructions. The acquisition module 34 is then configured to first retrieve, in step 110, all the emulated instructions of the sequence and store them in the database 44; and then to filter—within the database 44 and in step 130—the retrieved instructions according to the type determined by the determination module 30.

[0154] Each acquired instruction is furthermore associated, for example, with an icount counter in the case of a first emulator 12 of type QEMU.

[0155] The acquired instructions are then dated during a dating phase 140.

[0156] In the example of [Fig.5], the instruction blocks correspond to the time intervals and the dating phase 140 includes an increment step 150 and a dating step 160.

[0157] During the increment step 150, the increment module 38 ensures the growth of the estimated start times ts' of the instruction blocks from one instruction sequence to the next.

[0158] For example, we can see in the second column 22 of [Fig.2] that the icount counter is reset to zero at the end of a quantum. The increment step 150 avoids this reset.

[0159] In particular, during the increment step 150, the increment module 38 associates with each block of instructions in the current sequence of instructions, a start time ts' equal to the sum of the start time ts' of the previous block, or interval, of instructions and the total number of instructions in the previous block, or interval, of instructions, the start times ts' being each expressed for example as an integer number of time steps At.

[0160] The result of the increment step 150 is shown for example in the third column 24 of [Fig.2].

[0161] The instructions acquired from the current instruction sequence of the at least one type to be dated are dated, by the dating module 36 and within the respective sequence, during the dating step 160.

[0162] The timing module 36 estimates an execution time for each of said instructions. Each estimated execution time ts is included in the time interval corresponding to the current instruction sequence.

[0163] The dating module 36 applies, for example, a uniform distribution or a fixed-step distribution, as described previously.

[0164] In [Fig.2], the result of the dating phase 140, and in particular of the dating step 160, is shown in a fourth and final column 26, starting from the left of [Fig.2]. The estimated dating times ts are increasing according to the order of execution of the instruction set of the emulated software application.

[0165] In an alternative not shown, the order of execution of the increment step 150 and the timestamping step 160 of the estimated execution times ts is reversed. According to this alternative, the estimated execution times tss are then calculated first for each instruction sequence, and then incremented from one instruction sequence to the next.

[0166] The dated instructions are transmitted to the second emulator 16 by the transmission module 39 during a final transmission step 170, in order to be simulated by the second emulator 16.

[0167] Those skilled in the art will observe that the timing system 14 according to the invention further enables decoupling of the first emulator 12 and the second emulator 16 through the implementation of the database 44. Thus, the first emulator 12 can continuously produce instrumented instructions, enabling it to have an efficient execution flow and maximize its performance, which should be maintained at its highest level despite the annotation, in particular the timing of the instructions. The timing system 14, and by extension the second emulator 16, are thus able to retrieve and process instructions independently, while being bounded by the progress of the first emulator 12.

[0168] Optionally, the timing phase 140 and the transmission step 170 are performed in parallel with the acquisition steps 110, 130, or even the definition step 120. Thus, the timing of the instructions acquired for a current instruction sequence is performed simultaneously with the acquisition of the instructions for a subsequent instruction sequence, the subsequent instruction sequence corresponding to the emulated instructions during a later time interval, subsequent to a current time interval corresponding to the current instruction sequence. The simultaneous implementation of these steps 110, 120, 130 on the one hand, and 150, 160, 170 on the other, improves the performance of the emulation system 10 in terms of emulation speed, as the emulation is relatively slowed down by the addition of the timing system 14.

[0169] A person skilled in the art will then understand that, generally speaking, the steps of the dating process can be parallelized, both with each other and within each other, in the form of an execution pipeline. This ensures that the duration of the longest step in the process is as close as possible to that required by the first emulator 12. This allows for an event production flow by the first emulator 12 equivalent to that of the dating system 14, and possibly subsequent emulators, such as The second emulator 16, and thus avoids any timing penalty from the dating, once the pipeline priming phase has passed. Different implementation examples can lead to different pipeline slicing strategies depending on the effective duration of each phase.

[0170] In addition, once transmitted the instructions are optionally deleted from database 44 in order to free up storage and limit slowdowns related to an overloaded memory.

[0171] It is thus understood that the instruction dating process and the dating system 14 according to the invention make it possible to provide a more accurate picture of the temporal behavior of the emulated software application.

Claims

Demands

1. A method for dating instructions from a set of instructions of a software application, emulated during an emulation of said software application by an emulator (12), the method being implemented by an electronic dating system and comprising the following steps: - determining at least one type of instruction to be dated; - defining (120) a time interval between a start time (TIinter) and an end time (TFinter) obtained from the emulator (12), the time interval corresponding to a sequence of successive instructions emulated by the emulator (12) between the start time (TIinter) and the end time (TFinter); - acquiring, (130) from the sequence of instructions, the instructions corresponding to said at least one type and according to the order of execution;- dating (160) of the acquired instructions by estimating for each of said instructions an execution time (ts), each estimated execution time (ts) being included in the time interval, the estimated execution times (ts) of the acquired instructions being calculated as a function of the number (C) of acquired instructions.;

2. A method according to claim 1, wherein the instruction set is emulated by the emulator (12) in a total emulation time, the total emulation time being divided into a plurality of successive time intervals, the time intervals being contiguous and the estimated execution times (ts) are of increasing value from one time interval to the next.

3. A method according to claim 1 or 2, wherein the estimated execution times (ts) are increasing according to the order of execution of the instructions acquired in the time interval.

4. A method according to any one of the preceding claims, wherein the estimated execution times (ts) are calculated according to a uniform distribution, the uniform distribution depending on the number (C) of instructions acquired in the instruction sequence corresponding to the time interval.

5. A method according to any one of claims 1 to 3, wherein the estimated execution times (ts) are calculated according to a fixed-step distribution, the difference between two estimated times successive execution (ts) of a respective time interval being equal to the fixed step.

6. A method according to any one of the preceding claims, wherein the acquisition (130) of the instructions corresponding to said at least one type comprises the acquisition of at least one execution context information for each instruction, the estimated execution times being further calculated as a function of the at least one execution context information; the at least one execution context information preferably comprising at least one element from the group consisting of: an execution latency, a processor frequency intended to execute the software application, an instruction counter, and an end-of-quantum indicator.

7. A method according to any one of the preceding claims, wherein the instruction set comprises successive blocks of instructions, each block of instructions being emulated from an estimated start time (ts'), the estimated start time (ts') of a current block of instructions being less than the estimated start time (ts') of a subsequent block of instructions.

8. A method according to any one of the preceding claims, wherein the timing (160) of the acquired instructions is followed by a transmission step (170) of the instruction sequence and the estimated execution times to an additional emulator (16) external to the emulator (12).

9. A method according to any one of the preceding claims, wherein the timing (160) of the instructions acquired for a current sequence of instructions is performed simultaneously with the timing (130) of the instructions of one or more subsequent sequences of instructions, each subsequent sequence of instructions corresponding to the emulated instructions during a respective subsequent time interval, later than a current time interval corresponding to the current sequence of instructions.

10. A method according to claim 9, wherein the timing (160) of the instructions acquired for the current sequence of instructions is performed simultaneously with the setting (120) of the time interval for one or more subsequent sequences of instructions.

11. Electronic system (14) for dating instructions among a set of instructions of a software application, emulated during an emulation of said software application by an emulator (12), the electronic dating system (14) comprising: - a determination module (30) configured to determine at least one type of instruction to be dated; - a definition module (32) configured to define a time interval between a start time (TIinter) and an end time (TFinter) obtained from the emulator (12), the time interval corresponding to a sequence of instructions emulated by the emulator (12) between the start time (TIinter) and the end time (TFinter); - an acquisition module (34) configured to acquire, from the sequence of instructions, instructions corresponding to at least one type and in the order of execution; and - a dating module (36) configured to date the acquired instructions by estimating for each of said instructions an execution time (ts), each estimated execution time (ts) being included in the time interval, the estimated execution times (ts) of the acquired instructions being calculated as a function of the number (C) of acquired instructions.

12. System (14) according to claim 11, wherein the instruction set comprises successive instruction blocks, each instruction block being emulated from an estimated start time (ts'), and the system (14) further comprises an increment module (38) configured to increment the estimated start times (ts'), the estimated start time (ts') of an instruction block being less than the estimated start time (ts') of the next instruction block.

Images