Simulation method and device
Patent Information
- Application Number
- PCT/EP2024/055559
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-03-04
- Publication Date
- 2025-10-02
Smart Images
Figure EP2024055559_02102025_PF_FP_ABST
Abstract
Description
[0001] SIMULATION METHOD AND DEVICE
[0002] TECHNICAL FIELD
[0003] The present disclosure generally relates to the field of computer technology. For instance, the present disclosure provides a method and a device for simulation.
[0004] BACKGROUND
[0005] With the proliferation of interconnected devices through both wired and wireless technologies, the ability to upgrade and enhance software functionalities throughout a device lifespan has emerged as a critical requirement for modem computing equipment and systems. Traditionally, software simulation on accurate Register Transfer Level (RTL) models offered precise performance estimations within a reasonable timeframe, typically a few dozen minutes for simpler software configurations. However, this approach has become increasingly impractical in recent years, particularly post-2010, due to the exponential growth in software complexity. The accumulation of software features has significantly slowed down traditional RTL model simulations, yielding performance estimations at merely a few kilohertz for complex processor designs, despite the expectation to run millions or trillions of software cycles for accurate performance assessment.
[0006] This limitation has led to the adoption of complex and costly systems such as Mentor Veloce, Cadence Palladium, Synopsys ZeBu, and HAPS. These systems utilize custom Application-Specific Integrated Circuits (ASICs) or general-purpose Field- Programmable Gate Arrays (FPGAs) to accelerate RTL simulations. However, such solutions entail significant financial outlays, sometimes reaching millions of euros, and consume tens of kilowatts per hour. Despite these substantial investments in hardware and energy, the performance improvements achieved are often marginal and come at a considerable cost. For instance, the Cadence Palladium system, despite its rapid RTL compilation capabilities, achieves only 140MG / hr on its Z1 system, which is insufficient for today's complex designs that contain billions of gates. Similarly, Mentor Veloce offers commendable RTL compilation speeds but operates at a frequency approximately 1000 times slower than that of software Instruction Set Architecture (ISA) simulators. Systems like Synopsys ZeBu and HAPS leverage commercial FPGAs from AMD / Xilinx to achieve faster execution speeds, close to 100MHz. However, this advantage is offset by significant increases in RTL compilation time, often necessitating manual design partitioning. Moreover, these designs suffer from limited visibility, hindering debugging efforts and requiring frequent recompilations whenever new signals need to be monitored, further exacerbating delays.
[0007] SUMMARY
[0008] There is a paradox in the realm of computing system development. On one hand, software developers exhibit a preference for Instruction Set Architecture (ISA) simulators, valuing their capability to operate at speeds ranging from 100MHz to GHz levels. However, these simulators fall short in providing cycle-accurate (CA) simulations, a critical shortfall for precise performance analysis. On the other hand, hardware developers lean towards traditional Register Transfer Level (RTL) simulators, which, though slower in execution speed, offer fast compilation times (e.g., compared to emulators and accelerators) and full debug visibility, enabling a thorough examination of the hardware's behaviour during simulations.
[0009] The response from major Electronic Design Automation (EDA) vendors, which have introduced hardware accelerator solutions to bridge these gaps, has not been entirely satisfactory. These solutions often fail to meet the expectations of both software and hardware engineers, leading to the emergence of specialized teams proficient in both domains to manage these tools effectively. From practical experience, it has been observed that preparing a hardware-accelerated model for use typically exceeds the time required to develop software for ISA simulators and hardware for cycle-accurate (CA) simulators. This delay frequently becomes a critical bottleneck in project timelines, despite the undeniable utility of hardware accelerator technologies. Such technologies are still widely employed owing to their unique ability to run complex software flows, thereby exposing subtle bugs within the hardware design that might otherwise remain undetected.
[0010] This dichotomy underscores the urgent need for solutions capable of reconciling the conflicting requirements of speed, accuracy, and visibility in the simulation of computing systems.
[0011] In view of the above-mentioned problems and disadvantages, the present disclosure aims to address these challenges, offering a novel approach that harmonizes the demands of both software development and hardware design, thereby streamlining the simulation process and accelerating project completion.
[0012] These and other objectives are achieved by this disclosure, for instance, as described in the independent claims. Advantageous implementations are further described in the dependent claims.
[0013] A first aspect of this disclosure provides a method for simulating a target circuit design. The target circuit design is typically associated with (or comprises) a plurality of micro-architecture hyper-parameters. The method comprises the following steps: decompiling a binary code to obtain a control flow graph comprising a plurality of basic blocks; generating a plurality of basic block chains based on the plurality of basic blocks taking account of the plurality of micro-architecture hyper-parameters of the target circuit design; determining, for each basic block chain, a context; performing, for each basic block chain, cycle-accurate simulation based on the determined context of each basic block chain, to obtain cycle count information; storing the cycle count information into a database; performing instruction-accurate simulation using the binary code, to obtain instruction traces indicating executed basic block chains; retrieving, for each executed basic block chain, corresponding cycle count information from the database; and determining overall cycle count information of the binary code on the target circuit design by accumulating the retrieved cycle count information of the executed basic block chains.
[0014] Optionally, a basic block may be executed in one or more execution paths. Accordingly, based on the control flow graph, for a particular basic block, one or more basic block chain comprising the particular basic block may be generated. The generated basic block chain comprises a certain number of basic blocks, which is referred to as the length of the basic block chain. Optionally, for a given basic block, basic block chains with various lengths may be generated.
[0015] Optionally, the cycle-accurate simulation of the multiple basic block chains may be performed in a parallel manner.
[0016] In an implementation form of the first aspect, the cycle count information may be stored in the database with a corresponding basic block chain signature as a key.
[0017] Optionally, the signature of the basic block corresponding to the basic block chain may also be used as part of the key. By combining the cycle-accurate simulation and the instruction-accurate simulation, a fast and accurate simulation can be achieved.
[0018] In a further implementation form of the first aspect, the step of retrieving, for each executed basic block chain, corresponding cycle count information from the database may comprise: filtering one or more basic block addresses from the instruction traces; generating a basic block chain signature based on the filtered basic block addresses; and querying the database using the generated basic block chain signature, to retrieve the corresponding cycle count information.
[0019] In a further implementation form of the first aspect, in response to determining that an executed basic block chain is not found in the database, the method may further comprise: performing, for the executed basic block chain that is not found, context recovery and cycle accurate simulation, to obtain corresponding cycle count information; and updating the database with the corresponding cycle count information for the executed basic block chain that is not found.
[0020] In a further implementation form of the first aspect, in response to determining that an executed basic block chain is not found in the database, the method may further comprise extrapolating cycle count information of the executed basic block chain that is not found from one or more similar basic block chains that are found in the database.
[0021] In a further implementation form of the first aspect, the step of determining the context may comprise determining a symbolic representation of each basic block chain, and obtaining a valid context by solving the symbolic representation using symbolic solvers.
[0022] In a further implementation form of the first aspect, for performing cycle-accurate simulation, the method may comprise: converting each basic block chain into instruction streams based on the context; and executing the cycle-accurate simulation of the instruction streams of the basic block chains in parallel.
[0023] Notably, an instruction stream comprises all the instructions from a basic block chain, including branching instructions if any. The context of the basic block chain may be pre-loaded into a cycle-accurate simulator, such that the cycle-accurate simulation starts with the first instruction in the basic block chain, and the pre-loaded context (e.g. CPU architecture register and memory contents) guarantees any branching instruction will jump to the next basic block in the current basic block chain. Alternatively, the context of the basic block chain may be converted into an additional sequence of instructions (context instruction sequence / stream) and then combined with the instruction sequence of the basic block chain, such that the cycle-accurate simulator start the first instruction in the context instruction sequence, followed by a jump into the first instruction of the basic block chain instruction sequence, which then goes through each basic block instruction sequence. Alternatively, there may be no need to regenerate a new instruction sequence for the basic block chain, but rather re-using the existing whole application binary where the basic blocks in the current basic block chain are spread in arbitrary locations. In this case, the context instruction stream may be combined with the whole application binary and executed first by the cycle-accurate simulator, where the context instruction stream can guarantee an execution flow that covers the selected basic blocks in the current basic block chain.
[0024] In a further implementation form of the first aspect, the step of performing instruction-accurate simulation may be decoupled from the step of accumulating the retrieved cycle count information of the executed basic block chains.
[0025] A second aspect of this disclosure provides an apparatus for simulating a target circuit design. The target circuit design is typically associated with (or comprises) a plurality of micro-architecture hyper-parameters. The apparatus is configured to: decompile a binary code to obtain a control flow graph comprising a plurality of basic blocks; generate a plurality of basic block chains based on the plurality of basic blocks taking account of micro-architecture hyper-parameters of the target circuit design; determine, for each basic block chain, a context; perform, for each basic block chain, cycle-accurate simulation based on the determined context of each basic block chain, to obtain cycle count information; store the cycle count information into a database; perform instruction-accurate simulation using the binary code, to obtain instruction traces indicating executed basic block chains; retrieving, for each executed basic block chain, corresponding cycle count information from the database; and determine overall cycle count information of the binary code on the target circuit design by accumulating the retrieved cycle count information of the executed basic block chains.
[0026] In an implementation form of the second aspect, the cycle count information may be stored in the database with a corresponding basic block chain signature as a key.
[0027] In a further implementation form of the second aspect, for retrieving, for each executed basic block chain, corresponding cycle count information from the database, the apparatus may be configured to: filter one or more basic block addresses from the instruction traces; generate a basic block chain signature based on the filtered basic block addresses; and query the database using the generated basic block chain signature, to retrieve the corresponding cycle count information.
[0028] In a further implementation form of the second aspect, in response to determining that an executed basic block chain is not found in the database, the apparatus may be configured to: perform, for the executed basic block chain that is not found, context recovery and cycle accurate simulation, to obtain corresponding cycle count information; and update the database with the corresponding cycle count information for the executed basic block chain that is not found. In a further implementation form of the second aspect, in response to determining that an executed basic block chain is not found in the database, the apparatus may be configured to extrapolate cycle count information of the executed basic block chain that is not found from one or more similar basic block chains that are found in the database.
[0029] In a further implementation form of the second aspect, for determining the context, the apparatus may be configured to determine a symbolic representation of each basic block chain, and obtain a valid context by solving the symbolic representation using symbolic solvers.
[0030] In a further implementation form of the second aspect, for performing cycle-accurate simulation, the apparatus may be configured to: convert each basic block chain into instruction streams based on the context; and execute the cycle-accurate simulation of the instruction streams of the basic block chains in parallel.
[0031] In a further implementation form of the second aspect, the apparatus may be configured to perform instruction-accurate simulation and the accumulation of the retrieved cycle count information in a decoupled manner.
[0032] The apparatus of the second aspect may share the same optional features and advantages as the method of the first aspect accordingly.
[0033] It is noted that the apparatus of the second aspect may share the same optional features and advantages as the method of the first aspect.
[0034] A third aspect of the present disclosure provides a computer program comprising a program code for performing the method according to the first aspect or any of its implementation forms.
[0035] A fourth aspect of the present disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor (or a chipset), causes the method according to the first aspect or any of its implementation forms to be performed.
[0036] It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of the present disclosure, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. BRIEF DESCRIPTION OF DRAWINGS
[0037] The above-described aspects and implementation forms will be explained in the following description in relation to the enclosed drawings, in which:
[0038] FIG. 1 shows a diagram of a method according to this disclosure;
[0039] FIG. 2 shows an example of a method according to this disclosure;
[0040] FIG. 3 shows an example of control flow generation;
[0041] FIG. 4 shows an example of basic block chain generation;
[0042] FIG. 5 shows an example of context recovery;
[0043] FIG. 6 shows an example of cycle count storage;
[0044] FIG. 7 shows an example of cycle count retrieving;
[0045] FIG. 8 shows an application scenario of this disclosure; and
[0046] FIG. 9 shows a further application scenario of this disclosure.
[0047] DETAILED DESCRIPTION OF EMBODIMENTS
[0048] A list of key terms used in the present disclosure is briefly explained as follows, without losing generality in their meanings commonly known in the field.
[0049] Instruction- Accurate (I A) simulate r / simulation:
[0050] An IA simulator concerns software visible effects, namely the architectural state and instruction behaviors. All microarchitecture behaviors and its impact on cycle counts are not considered in the IA simulator.
[0051] The IA simulator may also be referred to as an instruction set simulator (ISS).
[0052] Cycle-Accurate (CA) simulator / simulation:
[0053] A C A simulator is a computer program that simulates a microarchitecture on a cycle-by-cycle basis. The CA simulator is used to model an entire processor (e.g., CPU) architecture and micro-architecture such that event-driven simulation may be used. RTL modeling in Verilog and VHDL are the most common forms of CA simulation. SystemC as an event-driven simulator is also capable of doing cycle accurate modeling. A CA model normally can be used to directly generate RTL, go through synthesis and serve as an input source for final physical implementation.
[0054] Hardware-Accelerator
[0055] A hardware accelerator includes Boolean processors, special ASIP accelerators, FPGA based accelerators. Those are no-longer software-based simulation, but hardware assisted simulation acceleration.
[0056] The present disclosure proposes a fully automated hybrid simulation solution, where an IA simulator and CA simulator are employed. By performing application specific, micro-architecture hyper-parameter guided application binary and control-flow- graph analysis, a large number of basic block chains are generated and are calibrated directly on the CA simulator with symbolically recovered context information. Then an IA simulation and run-time signature matching are performed to retrieve context-aware basic block chain latencies, thus improving both accuracy and speed for performing simulation. Low-cost general purpose computing device / system / cloud may be used to perform the solution.
[0057] FIG. 1 shows a diagram of a method according to this disclosure. The method is for simulating a target circuit design. For instance, the method may be applied to simulating an ARM machine on a host system based on x86 architecture, or vice versa.
[0058] Typically, the target circuit design is associated with or comprises a set of micro-architecture hyper-parameters. The microarchitecture hyper-parameters (or simply microarchitecture parameters) may refer to detailed design specifications and configurations that define how a processor's architecture is implemented at the physical level. The microarchitecture parameters relate to a microarchitecture level, which is a layer of design that translates the instruction set architecture (ISA) into an actual hardware structure. Examples of the microarchitecture parameters include but not limited to: the number of processors, cache size and hierarchy, the number and types of execution units, pipeline depth, the number of outstanding load / store supported, the size and algorithm of the branch prediction unit, etc. The microarchitecture parameters may be obtained as a configuration (config) file.
[0059] The method comprises the following steps 101 to 108.
[0060] Step 101 (control flow graph (CFG) generation): decompiling a binary code 110 to obtain a control flow graph 120 comprising a plurality of basic blocks.
[0061] The binary code 110 may refer to an executable program. A control flow graph is a graphical representation of all possible flows of control in a program (the binary code). Nodes in the CFG are basic blocks. Any method known in the field that is used to construct a control flow graph may be employed in this step, which is not detailed herein.
[0062] Step 102 (basic block chain generation): generating a plurality of basic block chains 130 based on the plurality of basic blocks taking account of the plurality of micro-architecture hyper-parameters of the target circuit design.
[0063] A basic block chain is a possible partial instruction flow of the program. In this step, micro-architecture hyper-parameters such as out-of-order execution window size, branch predictor size and other high-level micro-architecture parameters are taken into account and are used as a guide to generate properly sized basic block chains. Optionally, instruction-accurate simulator runtime feedback may be taken into account to generate more basic block chains if necessary, such that hotspot basic block chain, if not covered during static basic block generation, can be further generated on the fly.
[0064] Step 103 (symbolic context recovery): determining, for each basic block chain 130, a context 140.
[0065] There are multiple ways for performing context recovery of a basic block chain. One such example is by using symbolic solvers, e.g. symbolically solving an equation such that all the branching instructions are branched to the basic blocks in the basic block chain.
[0066] For performing symbolic context recovery, a symbolic representation of the basic block chain is determined. A valid context may be obtained by solving the symbolic representation using symbolic solvers. The symbolic representation is formed for a branching address of each branching instruction, such that the branching address equals to the next basic block in the current basic block chain. Multiple equations are then solved together, where variables in those equations may comprise architecture registers, memory contents, and the like.
[0067] Step 104 (cycle-accurate simulation): performing, for each basic block chain 130, cycle-accurate simulation based on the determined context 140 of each basic block chain 130, to obtain cycle count information 150. The obtained cycle count information comprises information on a cycle count of the last basic block in the basic block chain. One basic block may be associated with multiple cycle count information, since one basic block may correspond to (or may be comprised in) different basic block chains.
[0068] For performing the cycle-accurate simulation, the activities and events of the target circuit design during each simulation clock cycle are simulated. For example, in terms of logic design, cycle-accurate simulation means simulating combinational logic behavior during each clock cycle.
[0069] Optionally, each basic block chain may be converted into instruction streams based on the context. Cycle-accurate simulation of the instruction streams of multiple basic block chains may be performed in a parallel manner. In this way, execution efficiency for the cycle-accurate simulation may be improved.
[0070] The cycle count information 150 of the basic block chain may be indicative of (or comprise information on) the number of clock cycles for executing the last basic block in the basic block chain using the target circuit design. A single basic block may have different clock cycles, since the single basic block may be executed following different basic block chains. For instance, a basic block #A may correspond to multiple basic block chains: a first basic block chain of B -> C -> A, and a second basic block chain of D -> C- > A. In the first basic block chain, executing the last basic block A may need four cycles; while in the second basic block chain, executing the last basic block A may need six cycles.
[0071] Step 105 (result storage): storing the cycle count information 150 into a database 160.
[0072] Optionally, the cycle count information 150 may be stored in the database 160 with a corresponding basic block chain signature as a key.
[0073] For instance, following the example given in step 104 above, the following entries may be stored into the database: {#B + #C + #A || 4}, {#D + #C + #A || 6}. Symbol # herein may denote the address of the corresponding basic block, and symbol + herein may denote concatenation. It is noted that detailed formats for constructing the database is not limited in this disclosure. For instance, the entries may also be in a format of: {#A || #B + #C || 4}, {{#A || #D + #C || 6}. Detailed formats of the database are not limited as long as the database can indicate that a basic block may be executed following different basic block chains and may have different cycle counts.
[0074] Step 106 (instruction-accurate simulation): performing instruction-accurate simulation using the binary code 110, to obtain instruction traces indicating executed basic block chains.
[0075] For instance, following the example given above in step 104-105, an example of instruction traces may comprise a part like: [...]BCAXCAYDCAXBA[...], which may indicate that basic block chains of BCA, CA, DCA, and BA.
[0076] Step 107 (retrieving cycle count information): retrieving, for each executed basic block chain, corresponding cycle count information from the database 160. Optionally, for the corresponding cycle count information from the database, one or more basic block addresses may be filtered from the instruction traces. Then, a basic block chain signature (or simply a “signature”) may be generated based on the filtered basic block addresses. The generated basic block chain signature may be used to query the database, such that the corresponding cycle count information is retrieved.
[0077] For instance, following the example given above in step 106, an example of a signature of the basic block chain BCA may be: #B + #C + #A (i.e., the addresses of the basic blocks are concatenated). This signature is used to query the database 160 and a cycle count of 4 can be obtained.
[0078] Optionally, when an executed basic block chain cannot be found in the database (in the following referred to as a missing basic block chain), symbolic context recovery and cycle-accurate simulation may be performed for the missing basic block chain in order to obtain the cycle count information of the missing basic block chain. Then, the database 160 is updated with the cycle count information of the missing basic block chain.
[0079] Alternatively, the cycle count information of the missing basic block (e.g. the basic block’s runtime signature is missing in the database) may be extrapolated from one or more basic block chains that are similar to the missing basic block chain in the database 160.
[0080] For instance, in the example given above, the basic block chains of CA and BA are missing basic block chains since their signatures cannot be matched in the database. According to the first option mentioned above, the basic block chains CA and BA may be feedback to context recovery and cycle-accurate simulation, in order to obtain the cycle count information accordingly. Alternatively, according to the second option mentioned above, the basic block chain CA is similar to both basic block chains of BCA and DCA. Thus, an averaged (or weighted) cycle count of BCA and DCA may be used as a cycle count for CA. The basic block chain BA is only similar to basic block chain BCA. Accordingly, the cycle count of BCA may be used as the cycle count of BA. It is noted that the estimation scheme shown herein are simple examples for illustration purposes only. Other algorithms may be used to estimate cycle count of a missing basic block chain using similar basic block chains.
[0081] Step 108 (cycle count accumulation): determining overall cycle count information of the binary code on the target circuit design by accumulating the retrieved cycle count information of the executed basic block chains.
[0082] It is noted that the step 105 of instruction-accurate simulation may be decoupled from the step 108 of cycle count accumulation. For instance, the lA-simulation may keep running regardless of whether a signature is found or not. The cycle count accumulation may wait for the result of a particular signature while lA-simulation proceeds.
[0083] FIG. 2 shows an example of a method according to this disclosure. In FIG. 1 and FIG. 2, corresponding elements may share the same features. Some elements in FIG. 1 are not shown in FIG. 2 for the sake of simplicity.
[0084] As illustrated in FIG. 2, a simulation method may comprise three main segments: static analysis, massively parallel execution (of cycle-accurate simulation), and instruction-accurate simulation.
[0085] In the static analysis, a given software application (e.g., in a form of an ELF binary file) is analyzed and its control flow graph is reconstructed. A micro-architecture hyper-parameter guided analysis of the CFG and generating basic block chains then follows. In the massively parallel execution (of cycle-accurate simulation), the context of each basic block chain is recovered. The context is loaded into a cycle-accurate simulator (e.g., either via instruction injection or directly via cycle-accurate simulation resource manipulation). The results of cycle-accurate simulation are collected and are stored in a database (or a hash table).
[0086] The instruction-accurate simulation is extended with basic block chain signature mapping. A cycle count of a particular basic block may be determined by finding the closest basic block chain signature in the database. When a signature is not found, either an average value of all signatures for a particular basic block or an extrapolation using those values may be applied. Alternatively, an online feedback path can be established to perform cycle-accurate simulation for a missing basic block. Once the result is ready, the cycle accumulation may use and accumulate the cycles of the missing basic block.
[0087] The method of FIG. 2 may comprise the following steps:
[0088] Step 201: A target application / software binary 210 is obtained / provided and is analyzed. Its control flow graph is constructed. The control flow graph may comprise control information of the application software. Nodes in the control flow graph are basic blocks.
[0089] Step 202: Basic block chains 230 are generated. Micro-architecture hyper-parameters may be considered for generating the basic block chains. The micro-architecture hyper-parameters may comprise, for instance but not limited to, out-of-order execution window size, branch predictor size and other high-level micro-architecture parameters. The micro-architecture hyperparameters are used as a guide to generate properly sized basic block chains. A basic block chain is a possible partial instruction flow of the application.
[0090] Optionally, in this step, IA simulator run-time feedback may be received to generate more basic block chains if necessary, such that hotspot basic block chain if not covered during static basic block chain generation (“missing basic block chain”), can be further generated on the fly.
[0091] Step 203: Symbolic context is generated (or recovered). In this step, a symbolic representation is generated for each jump instruction, as well as proper constraints for all the instructions in the basic block chain such that the instructions behave legally (e.g. access legal memories). The jump instructions may be associated with constraints that they jump to the basic blocks selected in the basic block chain. The result of the context recovery may be referred to as basic block chain context 240 and may comprise information on architecture registers, memory contents, and the like that is associated with each basic block chain.
[0092] Step 204: A dispatcher function unit is adapted to obtain the recovered basic block chain context, convert them into CA simulator accepted forms (e.g. an instruction stream or a script that sets CA simulator states), and trigger the execution of CA simulation. The CA simulation may be executed in a massively parallel manner, optionally on multiple computing servers.
[0093] Step 205: When each individual CA simulation is completed, the cycle count information is collected and stored in a database, such that the database is a context-aware basic block chain latency database. The database can be a hash table, a relational database, or any key-value database system that supports fast query.
[0094] Step 206: The IA simulator starts running with the same application binary. Instruction address trace is generated.
[0095] Step 207: A dynamic signature mapper unit is adapted to analyze the instruction address trace and re-construct basic block chain signature dynamically. The basic block address from the control flow graph may be used for reconstructing the basic block chain signature. If there is no match, either the signature is fed back to the basic block chain generator to create such basic block chain(s) and then wait for the CA simulation result, or one or more closest matching (or similar) basic block chains are selected and their cycle counts are inferred (e.g. averaged or extrapolated), such that a cycle count for this particular signature is created.
[0096] Step 208: A cycle accumulator is adapted to add the cycle count for the current basic block chain and continues. When the program execution on lA-simulator is completed, all cycles for all basic block chains are accumulated. An estimated overall cycle count information 280 of the application binary 210 is available.
[0097] It is noted that the method of FIG. 2 may be built based on the method shown in FIG. 1. For instance, steps 201-208 correspond to steps 101-108, respectively. The method of the present disclosure may be computer-implemented. A computing apparatus, or a computing system comprising a plurality of computing apparatuses may be used to execute the method of FIG. 1 and FIG.
[0098] 2. The computing apparatus (or the computing system) may comprise functional units adapted to perform the steps mentioned above in FIG. 1 and FIG. 2. For instance, the computing apparatus may comprise: a CFG construction unit adapted to perform step 101 / 201; a basic block chain generation unit adapted to perform step 102 / 202; a symbolic context recovery unit adapted to perform step 103 / 203 ; one or more CA simulators adapted to perform step 104 / 204; one or more IA simulators adapted to perform step 106 / 206; a signature mapping unit adapted to perform step 107 / 207; a cycle accumulation unit adapted to perform step 108 / 208; and an optional signature feedback unit adapted to feedback a missing basic block chain signature during IA simulation to the basic block chain generation unit.
[0099] FIG. 3 shows an example of control flow generation. Given a target software binary 310, a control flow graph 320 can be obtained via static analysis as in step 101 / 201. The control flow graph 320 may comprise a plurality of connected nodes. Each node is a basic block 321.
[0100] FIG. 4 shows an example of basic block chain generation. Following the control flow generation in FIG. 3, for each basic block 321, one or more basic block chains 430 may be obtained as in step 102 / 202. For instance, as illustrated in FIG. 4, for a basic block 321 of 0x1170-0x1180, three basic block chains 430 with a length of three are generated, each comprising the basic block of 0x1170-0x1180. It is noted that the length of the basic block chain may be configurable. For instance, it is also possible that for the basic block of 0x1170-0x1180, further basic block chains with a length of two (or four, five, etc.) may be obtained. The length of the basic block given in FIG. 4 is merely given for illustration purposes only.
[0101] FIG. 5 shows an example of context recovery. Following the basic block chain generation in FIG. 4, FIG. 5 shows an example of a symbolic context (or context patch) 540 determined as in step 103 / 203 for one basic block chain 430 in FIG. 4.
[0102] The symbolic context is indicative of memory and register configurations, and / or jump instructions, such that a branching address can be branched to a corresponding basic block in the basic block chain.
[0103] FIG. 6 shows an example of cycle count storage. Following the context recovery in FIG. 5, CA simulation is executed for each basic block chain with a corresponding context as in step 104 / 204, to obtain a corresponding cycle count. For instance, as illustrated in FIG. 6, for a basic block chain of 0x1178-0x1180, 0x1178-0x1180, 0x1178-0x1180, the cycle count for the last basic block (0x1178-0x1180) in this basic block chain is equal to five. Accordingly, the cycle count is stored into a database 660. The database 660 may be a context-aware basic block latency database. FIG. 6 shows an exemplary entry of the database 660: {target basic block, basic block chain signature, cycle}. The basic block chain signature may be used to identify (or index) a basic block chain that comprises the target basic block as the last basic block. Alternatively, if the target basic block is already indicated by the basic block chain signature, it is not necessary to have a separate column for the target basic block in the database 660. The basic block signature (and the target basic block if present) may be used as a key to query the cycle count in the database 660. One target basic block may be associated with multiple cycle count information. Since one basic block may correspond to multiple basic block chains, which is illustrated in FIG. 4 and FIG. 6.
[0104] FIG. 7 shows an example of cycle count retrieving. After IA simulation is performed using the target software binary 310, instruction traces indicating executed basic block chains (denoted as “IA traces” in FIG. 7) may be obtained. Based on the IA traces, one or more executed basic block chains may be obtained. For instance, as illustrated in FIG. 7, a basic block chain of 0x1178-0x1180, 0x1178-0x1180, 0x1178-0x1180 is identified, and the basic block chain signature is used to query the database 660. A corresponding cycle count equal to five can be successfully retrieved via the signature mapping.
[0105] It is noted that in case that the signature of an executed basic block chain cannot be found in the database (“missing basic block chain”), the signature of the missing basic block chain may be feedback to the steps of basic block chain generation, context recovery, and C A simulation, to obtain the cycle count.
[0106] Alternatively, the signature mapping may employ statistical methods to reduce the missing rate. The cycle count may be derived from one or more similar basic block chains that can be found in the database. For instance, when there is a missing basic block chain with a signature of ABCD, latency information and occurrence rate of signature XY CD and MNCD can be statistically combined to extrapolate latency information for signature ABCD (since the target basic block D is present in these basic block chains).
[0107] After the IA simulation is completed for the target software binary, the cycle counts of all the executed basic block chains are accumulated, to obtain an overall estimated cycle count of the target software binary.
[0108] It is noted that the contents, instructions and addresses shown in FIG. 3-FIG. 7 are for illustration purposes only. The instructions, addresses, and trace outputs vary across different software binaries.
[0109] It is further noted that in FIG. 1-FIG. 7, corresponding steps and elements may share the same features. For instance, steps 101- 108 correspond to steps 201-208, respectively. Elements 110, 210 and 310 correspond to each other. Elements 120 and 320 correspond to each other. Elements 130, 230 and 430 correspond to each other. Elements 140, 240 and 430 correspond to each other. Elements 140, 240 and 440 correspond to each other. Elements 150 and 650 correspond to each other. Elements 160 and 660 correspond to each other.
[0110] FIG. 8 shows an application scenario of this disclosure. The simulation method of this disclosure may be utilized for processor- centric simulations. A computing apparatus / system may be configured to emulate a processor along with critical memory subsystems, facilitating the execution of the disclosed simulation method. This configuration interconnects the processor and key memory subsystems, collectively establishing a comprehensive simulation environment that represents the target circuit design. Compiled software images or binaries can be loaded into the system's memory components, allowing the processor to execute these binaries. Throughout the execution process, the processor is capable of accessing all connected memory units, each of which may exhibit varying latency characteristics.
[0111] FIG. 9 shows a further application scenario of this disclosure. A computing apparatus / system may be configured to emulate multiple heterogeneous processors. Each processor is modeled as a processor simulator, incorporating a level 0 cache and tightly coupled memories as integral components of the simulator. The computing apparatus / system may also comprise a variety of devices, such as DDR controllers and hardware accelerators, contributing to the comprehensive model of the system under design (target circuit design). This ensemble of components and processors simulates the target circuit design, providing a detailed representation of the system's architecture and functionality.
[0112] As illustrated in FIG. 8 and FIG. 9, the disclosed method is applicable across multiple scenarios during the processor or circuit design phase, including:
[0113] Processor Verification: This involves testing the proper functionality of the processor's micro-architecture design to ensure it meets specified criteria;
[0114] Processor Architecture Exploration: In this process, various design options for the processor are evaluated to identify the most efficient architecture;
[0115] System on Chip (SoC) Integration Verification: This step tests the accuracy of component integration within an SoC, ensuring seamless operation among all parts; and
[0116] SoC Architecture Exploration: This involves identifying the optimal architectural design for a SoC, balancing performance, power, and area considerations.
[0117] For these use cases, the processor simulator can be an IA simulator, CA simulator, or a proposed hybrid simulator that integrates both IA and CA simulation capabilities. The hybrid simulator may be used in all those cases due to fast simulation speed with user-defined accuracy levels.
[0118] The hybrid simulator may also be used for processor CA-model verification, where large software application can be cut into smaller chunks and executed in parallel. The verification speed can be substantially accelerated as the smaller chunks is usually much smaller than the whole application.
[0119] In each scenario, the processor simulator may operate independently from the rest of the system. The remaining system components can be implemented using a variety of technologies such as Register Transfer Level (RTL) languages (e.g., Verilog, VHDL), SystemC, Field-Programmable Gate Arrays (FPGAs), accelerators, etc.
[0120] In summary, the present disclosure provides a hybrid simulation solution, where CA simulation and IA simulation are combined to perform target circuit design simulation. A fast and accurate simulation performance may be achieved. In particular, CFG static analysis and partitioning with context recovery are performed for a binary, such that a plurality of basic block chains is generated statically. The multiple basic block chains are typically short, such that massively parallel execution of the CA simulation is possible. In this way, the simulation duration can be substantially reduced. There is no need to perform hardware modifications to a simulator. Therefore, the present disclosure may be applied to any simulator.
[0121] Further, dynamic signature mapping and the optional latency extrapolation may be used to retrieve the cycle count (latency) information. The latency accuracy is proportional to the computation cost. Thus, the present disclosure is adjustable for different requirement (instead of one accuracy for all applications). For instance, the length of the basic block chain may be increased in order to achieve a relatively high delay accuracy. In this case, the cycle-accurate simulation duration is relatively prolonged. To the contrary, the length of the basic block chain may be reduced in order to achieve a fast cycle-accurate simulation. In this case, the delay accuracy may be relatively decreased.
[0122] The present disclosure may be applied to any computing apparatus / system. The computing apparatus for executing the method of this disclosure may comprise processing circuitry or a chipset configured to respectively perform, conduct or initiate the various operations described herein. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. Optionally, the processing circuitry (or the chipset) comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the devices to perform, conduct or initiate the operations or methods described herein.
[0123] The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.
Claims
CLAIMS1. A method for simulating a target circuit design comprising a plurality of micro-architecture hyper-parameters, the method comprising: decompiling ( 101 ) a binary code (110) to obtain a control flow graph (120) comprising a plurality of basic blocks; generating (102) a plurality of basic block chains (130) based on the plurality of basic blocks taking account of the plurality of micro-architecture hyper-parameters of the target circuit design; determining (103), for each basic block chain (130), a context (140); performing (104), for each basic block chain (130), cycle-accurate simulation based on the determined context (140) of each basic block chain, to obtain cycle count information (150); storing (105) the cycle count information (150) into a database (160); performing (106) instruction-accurate simulation using the binary code (110), to obtain instruction traces indicating executed basic block chains; retrieving (107), for each executed basic block chain, corresponding cycle count information from the database (160); and determining (108) overall cycle count information of the binary code (110) on the target circuit design by accumulating the retrieved cycle count information of the executed basic block chains.
2. The method according to claim 1, where the cycle count information (150) is stored in the database (160) with a corresponding basic block chain signature as a key.
3. The method according to claim 1 or 2, wherein the retrieving, for each executed basic block chain, corresponding cycle count information from the database (160) comprises: filtering one or more basic block addresses from the instruction traces; generating a basic block chain signature based on the filtered basic block addresses; and querying the database (160) using the generated basic block chain signature, to retrieve the corresponding cycle count information.
4. The method according to claim any one of claims 1 to 3, wherein in response to determining that an executed basic block chain is not found in the database, the method further comprises: performing, for the executed basic block chain that is not found, context recovery and cycle accurate simulation, to obtain corresponding cycle count information; and updating the database with the corresponding cycle count information for the executed basic block chain that is not found.
5. The method according to any one of claims 1 to 3, wherein in response to determining that an executed basic block chain is not found in the database, the method further comprises extrapolating cycle count information of the executed basic block chain that is not found from one or more similar basic block chains that are found in the database.
6. The method according to any one of claims 1 to 5, wherein the determining (103) the context comprises determining a symbolic representation of each basic block chain, and obtaining a valid context by solving the symbolic representation using symbolic solvers.
7. The method according to any one of claims 1 to 6, wherein for performing (104) cycle-accurate simulation, the method comprises: converting each basic block chain into instruction streams based on the context; and executing the cycle-accurate simulation of the instruction streams of the basic block chains in parallel.
8. The method according to any one of claims 1 to 7, wherein the step of performing (106) instruction-accurate simulation is decoupled from the step (107) of accumulating the retrieved cycle count information of the executed basic block chains.
9. An apparatus for simulating a target circuit design, the apparatus being configured to: decompile a binary code to obtain a control flow graph comprising a plurality of basic blocks; generate a plurality of basic block chains based on the plurality of basic blocks taking account of micro-architecture hyper-parameters of the target circuit design; determine, for each basic block chain, a context; perform, for each basic block chain, cycle-accurate simulation based on the determined context of each basic block chain, to obtain cycle count information; store the cycle count information into a database; perform instruction-accurate simulation using the binary code, to obtain instruction traces indicating executed basic block chains; retrieving, for each executed basic block chain, corresponding cycle count information from the database; and determine overall cycle count information of the binary code on the target circuit design by accumulating the retrieved cycle count information of the executed basic block chains.
10. The apparatus according to claim 9, where the cycle count information is stored in the database with a corresponding basic block chain signature as a key.
11. The apparatus according to claim 9 or 10, wherein for retrieving, for each executed basic block chain, corresponding cycle count information from the database, the apparatus is configured to: filter one or more basic block addresses from the instruction traces; generate a basic block chain signature based on the filtered basic block addresses; and query the database using the generated basic block chain signature, to retrieve the corresponding cycle count information.
12. The apparatus according to claim any one of claims 9 to 11, wherein in response to determining that an executed basic block chain is not found in the database, the apparatus is further configured to: perform, for the executed basic block chain that is not found, context recovery and cycle accurate simulation, to obtain corresponding cycle count information; and update the database with the corresponding cycle count information.
13. The apparatus according to any one of claims 9 to 11, wherein in response to determining that an executed basic block chain is not found in the database, the apparatus is configured to extrapolate cycle count information of the executed basic block chain that is not found from one or more similar basic block chains that are found in the database.
14. A system comprising one or more apparatus according to any one of claims 9 to 13.
15. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to any one of claims 1 to 8.