Techniques for controlling simulation of hardware offload system

Abstract

Embodiments of the present disclosure relate to techniques for controlling simulation of a hardware offload system. Examples are described for simulating performance of a hardware offload system, including receiving, by a simulator corresponding to a simulation architecture representing the hardware offload system, input data from a user application for processing by the simulation architecture, preparing, by the simulator, corresponding output data for the input data without calculating, by the simulation architecture, the corresponding output data, and returning, by the simulator, the corresponding output data to the user application after the simulation idle time associated with the calculation of the corresponding output data by the simulation architecture.

Description

Background Art

[0001] The described aspects relate to simulator applications and, more particularly, to simulators for hardware offload systems.

[0002] In big data analysis, most of the calculations performed on large data sets are simple and repetitive. Therefore, hardware-based accelerators (such as field programmable gate arrays (FPGAs), graphics processing units (GPUs), etc.) can be used to optimize the calculations. However, designing and optimizing hardware offload systems can be a challenging and time-consuming process, which may lead to high costs for projects that jointly design hardware and software for analysis. In this regard, having a reliable proof of concept (PoC) may be beneficial. When designing the hardware for the analysis engine, a system simulator can be developed to obtain a PoC estimate for the hardware design proposal. Typically, simulators for hardware offload systems are executed on processors (such as central processing units (CPUs)) that can execute applications such as simulators. For example, the simulator can use multiple CPU threads as an offload engine to perform calculations for hardware-based accelerators in the design and simulation hardware. Summary of the invention

[0003] A simplified summary of one or more implementations is presented below in order to provide a basic understanding of such implementations. This summary is not an extensive overview of all anticipated implementations, and is neither intended to identify important or critical elements of all implementations nor to outline the scope of any or all implementations. Its sole purpose is to present some concepts of one or more implementations in a simplified form as a prelude to a more detailed description that is presented later.

[0004] In an example, a computer-implemented method for simulating the performance of a hardware offload system is provided, comprising: receiving, by a simulator corresponding to a simulation architecture representing the hardware offload system, input data from a user application for processing by the simulation architecture; preparing, by the simulator, corresponding output data for the input data without calculating the corresponding output data by the simulation architecture; and returning, by the simulator, the corresponding output data to the user application after a simulation idle time associated with calculating the corresponding output data by the simulation architecture.

[0005] In another example, an apparatus for simulating performance of a hardware offload system is provided, comprising one or more processors and one or more non-transitory memories having instructions thereon. The instructions, when executed by the one or more processors, cause the one or more processors to receive input data from a user application by a simulator corresponding to a simulated architecture representing the hardware offload system for processing by the simulated architecture, prepare, by the simulator, corresponding output data for the input data without computing the corresponding output data by the simulated architecture, and return, by the simulator, the corresponding output data to the user application after a simulated idle time associated with computing the corresponding output data by the simulated architecture.

[0006] In another example, one or more non-transitory computer-readable storage media are provided that store instructions that, when executed by one or more processors, cause the one or more processors to perform a method for simulating the performance of a hardware offload system. The method includes: receiving, by a simulator corresponding to a simulation architecture representing the hardware offload system, input data from a user application for processing by the simulation architecture; preparing, by the simulator, corresponding output data for the input data without computing the corresponding output data by the simulation architecture; and returning, by the simulator, the corresponding output data to the user application after a simulation idle time associated with computing the corresponding output data by the simulation architecture.

[0007] To achieve the foregoing and related ends, one or more implementations include the features fully described below and particularly pointed out in the claims. The following description and the accompanying drawings set forth in detail certain illustrative features of one or more implementations. However, these features are indicative of only a few of the various ways in which the principles of various implementations may be employed, and this description is intended to include all such implementations and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 is a schematic diagram of an example of a system for performing simulation of a hardware offload system according to examples described herein.

[0009] Figure 2 is a flow chart of an example of a method for executing a simulator for a hardware offload system according to examples described herein.

[0010] Figure 3 is a schematic diagram of an example of a system for executing a simulator for a hardware offload system according to examples described herein.

[0011] Figure 4 is a schematic diagram of an example of an apparatus for performing the functions described herein. DETAILED DESCRIPTION

[0012] The specific embodiments described below in conjunction with the accompanying drawings are intended as descriptions of various configurations and are not intended to represent the only configurations in which the concepts described herein can be practiced. For the purpose of providing a thorough understanding of the various concepts, the specific embodiments include specific details. However, it will be apparent to those skilled in the art that these concepts can be practiced without these specific details. In some instances, well-known components are shown in block diagram form to avoid blurring such concepts.

[0013] The present disclosure describes various examples related to controlling a simulation or simulator (e.g., a simulated application) for a hardware offload system. As described, the hardware offload system can be designed to use one or more hardware-based accelerators, such as field programmable gate arrays (FPGAs), graphics processing units (GPUs), data processing units (DPUs), smart network cards (SmartNICs), etc., to process big data or otherwise facilitate big data analysis to perform repeated calculations on large data sets. For example, a DPU may include a system on a chip (SoC) that combines a multi-core processor, a high-performance network, and / or a set of acceleration engines that offload application performance for various functions. A simulator can be used to design, test, or otherwise simulate a hardware offload system to simulate an architecture selected for a hardware offload system. Typically, the simulator is executed as an application on a system based on a central processing unit (CPU). Therefore, the simulator typically uses a CPU core to simulate a hardware intellectual property (IP) core for data processing, wherein the IP core can be a higher performance processor provided by a hardware vendor, such as an FPGA, GPU, DPU, SmartNIC, etc.

[0014] Higher performance processors such as FPGAs provide certain features not found in CPUs to achieve higher performance, such as massively parallel execution, deep pipeline lining, on-the-fly computation, vectorization, high-speed memory (e.g., static random access memory (SRAM)) usage, etc., for actual computation on data or tables, including filtering, aggregation, and projection, etc. In this regard, high performance processors are superior to CPUs (e.g., may have higher performance parameters or metrics than CPUs), and when using a simulator to estimate the benefits or performance of a hardware offload system, it may be difficult for a CPU to achieve the data processing speed of an actual hardware IP core. Therefore, the gap between the estimated results and the actual results may not be consistent.

[0015] Aspects described herein relate to controlling a simulator to obtain corresponding output data of input data without the need for a CPU to perform calculations to calculate the corresponding output data. For example, the simulator may store the corresponding output data of the input data in a memory, wherein the corresponding output data may be calculated in the first (or previous) run of the simulator. During subsequent simulations, the simulator may then retrieve the corresponding output data of the input data without calculating the output data, which may significantly enhance the performance of the simulation. In addition, for more accurate performance results, the simulator may wait for a simulation idle time before returning the retrieved output data, wherein the simulation idle time may correspond to the time when a hardware offload system (or a corresponding high-performance processor) performs associated calculations. In this regard, the performance of the simulated hardware offload system may be measured without being affected by the inefficiency of the CPU on which the simulator is executing. This may allow for providing or obtaining more accurate performance results of the simulation architecture of the hardware offload system.

[0016] As used herein, a processor, at least one processor, and / or one or more processors configured to perform or operable to perform multiple actions, individually or in combination, is intended to include at least two different processors capable of performing different, overlapping or non-overlapping subsets of multiple actions, or a single processor capable of performing all multiple actions. In a non-limiting example where multiple processors can perform different actions in combination, the description of a processor, at least one processor, and / or one or more processors configured to perform actions X, Y, and Z may include at least a first processor configured to perform or operable to perform a first subset of X, Y, and Z (e.g., perform X) and at least a second processor configured to perform or operable to perform a second subset of X, Y, and Z (e.g., perform Y and Z). Alternatively, the first processor, the second processor, and the third processor may be configured to perform or operable to perform a corresponding one of actions X, Y, and Z, respectively. It should be understood that any combination of one or more processors may each be configured to perform or operable to perform any one or any combination of multiple actions.

[0017] As used herein, a memory, at least one memory, and / or one or more memories, individually or in combination, configured to store or having stored thereon instructions executable by one or more processors to perform a plurality of actions, is intended to include at least two different memories capable of storing different, overlapping, or non-overlapping subsets of instructions for performing a plurality of actions, or a single memory capable of storing instructions for performing all of the plurality of actions. In a non-limiting example of one or more memories, individually or in combination, capable of storing different subsets of instructions for performing different actions in a plurality of actions, a description of a memory, at least one memory, and / or one or more memories configured or operable to store or having stored thereon instructions for performing actions X, Y, and Z may include: at least a first memory configured or operable to store or having stored thereon a first subset of instructions for performing a first subset of X, Y, and Z (e.g., instructions for performing X); and at least a second memory configured or operable to store or having stored thereon a second subset of instructions for performing a second subset of X, Y, and Z (e.g., instructions for performing Y and Z). Alternatively, the first memory, the second memory, and the third memory may be configured to store or have stored thereon a first subset of instructions for performing X, a second subset of instructions for performing Y, and a third subset of instructions for performing Z, respectively. It should be understood that any combination of one or more memories may each be configured to or operable to store or have stored thereon any one or any combination of instructions that may be executed by one or more processors to perform any one or any combination of a plurality of actions. In addition, one or more processors may each be coupled to at least one of the one or more memories and configured to or operable to execute instructions to perform a plurality of actions. For example, in the above non-limiting example of different subsets of instructions for performing actions X, Y, and Z, a first processor may be coupled to a first memory storing instructions for performing action X, and at least a second processor may be coupled to at least a second memory storing instructions for performing actions Y and Z, and the first processor and the second processor may execute the respective subsets of instructions in combination to complete the execution of actions X, Y, and Z. Alternatively, the three processors may access one of three different memories, each storing one of the instructions for performing X, Y, or Z, and the three processors may execute the respective subsets of instructions in combination to complete the execution of actions X, Y, and Z. Alternatively, a single processor may execute instructions stored on a single memory or distributed across multiple memories to complete the execution of actions X, Y, and Z.

[0018] Now go to Figures 1 to 4 , examples are depicted with reference to one or more components and one or more methods that can perform the actions or operations described herein, where the components and / or actions / operations in dashed lines may be optional. Figure 2The operations described in the description are presented in a particular order and / or are presented as being performed by example components, but in some examples, the order of actions and the components performing the actions may vary depending on the implementation. In addition, in some examples, one or more of the actions, functions, and / or described components may be performed by a specially programmed processor, a processor executing specially programmed software or computer-readable media, or by any other combination of hardware components and / or software components capable of performing the described actions or functions.

[0019] Figure 1 1 is a schematic diagram of an example of a system for performing simulation of a hardware offload system according to aspects described herein. The system includes a device 100 (e.g., a computing device) including a processor(s) 102 (e.g., one or more processors) and / or a memory / memory(s) 104 (e.g., one or more memories). In an example, the device 100 may include a processor(s) 102 and / or a memory / memory(s) 104 configured to execute or store instructions or other parameters associated with providing an operating system 106, which may execute one or more applications, services, etc. In another example, the device 100 may execute a virtual machine (VM) 108, which may execute a user application 110 and / or a simulator 112. For example, the user application 110 may include a user application that provides input to the simulator 112 and receives output from the simulator 112 (such as input / output for big data analysis), so that the simulator 112 can simulate calculations performed by the simulation architecture of the hardware offload system.

[0020] For example, the processor(s) 102 and the memory / memories 104 may be separate components communicatively coupled via a bus (e.g., on a motherboard or other portion of a computing device, on an integrated circuit such as a system on a chip (SoC), etc.), components integrated with each other (e.g., the processor(s) 102 may include the memory / memories 104 as an onboard component 101), etc. In other examples, the processor(s) 102 may include multiple processors 102 of multiple devices 100, the memory / memories 104 may include multiple memories 104 of multiple devices 100, etc. The memory / memories 104 may store instructions, parameters, data structures, etc. for use / execution by the processor(s) 102 to perform the functions described herein.

[0021] Furthermore, the device 100 may include substantially any device that may have a processor(s) 102 and a memory / memories 104, such as a computer (e.g., a workstation, a server, a personal computer, etc.), a personal device (e.g., a cellular phone, such as a smart phone, a tablet, etc.), a smart device, such as a smart television, etc. Furthermore, in examples, various components or modules of the device 100 may be located within a single device, as shown.

[0022] In an example, the simulator 112 may optionally include an output preparation module 114 for preparing output to be returned to the user application as part of the simulation, an idle time calculation module 116 for calculating the idle time to wait before returning the prepared output data, and / or a data return module 118 for returning data (e.g., after the calculated idle time). The simulator 112 can simulate the architecture of the desired hardware offload system so that the user application 110 can provide input data to the simulator and / or receive corresponding output data from the simulator, just as it is provided to the hardware offload system and / or received from the hardware offload system. In an example, the simulator 112, the user application 110, or another application can measure the performance of the simulator 112 to determine the expected or estimated performance of the actual hardware offload system using the actual architecture simulated by the simulator 112. As described, for example, the hardware offload system may include one or more higher performance processors, such as (multiple) FPGAs, (multiple) GPUs, (multiple) DPUs, (multiple) SmartNICs, etc., and the performance of the architecture of the designed hardware offload system can be simulated by the simulator 112.

[0023] For example, the user application 110 may execute to provide input data to the simulator 112, which may occur in the VM 108 or otherwise. For example, the device 100 may execute a machine simulator, which may initialize the VM 108 on the device 100. The simulator may execute the simulator 112 (e.g., in the VM 108), and the user application 110 may also execute in the VM 108. According to aspects described herein, the simulator 112 may receive the input data, the output preparation module 114 may prepare corresponding output data for the input data, and the data return module 118 may return the corresponding output data to the user application 110. Because the performance of the architecture of the simulated hardware offload system may exceed the capabilities of the processor (e.g., the processor 102) executing the simulator 112, the simulator 112 may avoid calculating the corresponding output data, and may return the output data as retrieved from the memory / memories 104, which may allow the simulator 112 to execute at a speed more comparable to the architecture of the simulated hardware offload system. For example, the simulator 112 may calculate and store (e.g., in the memory / memories 104) corresponding output data for input data received from the user application 110 in an initial (or previous) run of the simulation. In any case, the output preparation module 114 may obtain the corresponding output data for the input data from the memory / memories 104 to return to the user application 110.

[0024] In one example, the speed of memory retrieval may be faster than the calculations to be performed by the architecture of the simulated hardware offload system, and therefore, the idle time calculation module 116 may calculate the idle time that the simulator 112 will wait before the data return module 118 returns the corresponding output data. In an example, the idle time calculation module 116 may calculate the idle time based on a throughput metric representing the performance of the architecture of the simulated hardware offload system (e.g., the time it will take for the architecture to perform calculations on the received input data to calculate the corresponding output data). The throughput metric may be configurable, which may allow different hardware offload systems to be simulated. In any case, by avoiding the calculation of the corresponding output data, the simulator 112 may achieve performance that is more closely aligned with the architecture of the simulated hardware offload system, even though the performance of the (multiple) processors 102 is more limited than higher performance processors in the architecture of the simulated hardware offload system.

[0025] Figure 2 is a flow chart of an example of a method 200 for executing a simulator for a hardware offload system according to aspects described herein. For example, the method 200 may be performed by a device 100 executing a simulator 112 and / or one or more components thereof for simulating a hardware offload system.

[0026] In method 200, at action 202, input data from a user application may be received by a simulator corresponding to a simulation architecture representing a hardware offload system for processing by the simulation architecture. For example, simulator 112 may be a simulator corresponding to a simulation architecture representing a hardware offload system. For example, the hardware offload system may include one or more higher performance processors, such as (multiple) FPGAs, (multiple) GPUs, (multiple) DPUs, (multiple) SmartNICs, etc., and simulator 112 may simulate its performance and operation. In an example, simulator 112, for example, in combination with (multiple) processors 102, memory / multiple memories 104, operating system 106, emulator (e.g., Qemu), etc., may receive input data from a user application for processing by the simulation architecture. For example, a user application 110 may interface with simulator 112 to provide input data thereto, and simulator 112 may provide corresponding output data for the input data. The simulator typically calculates corresponding output data for the input data; however, aspects described herein relate to preparing output data in other ways to prevent having to calculate output data via simulator 112, which may be slower than the simulation architecture due to limitations of (multiple) processors 102. In one example, simulator 112 can receive input data from user application 110 using direct memory access (DMA) with user application 110 (e.g., based on DMA information received from user application 110). In one example, as described, the input data can correspond to big data analysis or other data sets for which repeated calculations are desired.

[0027] In method 200, at act 204, corresponding output data for the input data may be prepared by the simulator without computing the corresponding output data by the simulation architecture. In an example, output preparation module 114, for example, in conjunction with processor(s) 102, memory / memories 104, operating system 106, simulator 112, may prepare corresponding output data for the input data without computing the corresponding output data by the simulation architecture. In an example, when preparing the corresponding output data at act 204, the corresponding output data may optionally be retrieved from the memory at act 206. In an example, output preparation module 114 may retrieve the corresponding output data from the memory / memories 104 without computing the corresponding output data, which may allow mitigation of inefficiencies in computing the output data using processor 102, and more closely aligning the performance of the simulation architecture with the actual architecture of the simulated hardware offload system.

[0028] In the method 200, optionally at act 208, corresponding output data may be calculated in a previous run of the simulator and stored in memory. In an example, the simulator 112, e.g., in conjunction with the processor(s) 102, the memory / memories 104, the operating system 106, etc., may perform an initial or previous run of the simulator 112 (e.g., based on input data from the user application 110 or otherwise), and may store the calculated corresponding output data in the memory / memories 104. For example, in the initial run, the simulator 112 may receive input data, calculate output data, and the output preparation module 114 may store the output data in the memory / memories 104. In an example, the output preparation module 114 may store the output data with a mapping to the input data to facilitate retrieval of the output data from the memory / memories 104 based on data from the user application 110 in a subsequent run of the simulator 112. In one example, the output preparation module 114 may store the output data with an identifier generated based on the input data to facilitate quick retrieval of the output data in the next run.

[0029] For example, if the input data offloaded for simulation includes a decompression operator, the output may be the decompressed data. Since the input data from the user application 110 does not change, the decompressed data does not change either. Therefore, during the initial run, the simulator 112 may cache the output data simulated on the simulator 112 into the memory / memories 104 using a mapping structure similar to the following:

[0030] <Compressed data identification key 1, decompressed data>

[0031] <Compressed data identification key 2, decompressed data> ...

[0033] <compressed data identification key n, decompressed data>

[0034] In this example, when retrieving corresponding data in a subsequent run, the output preparation module 114 can obtain output data corresponding to each input data based on mapping the input data identifiers to the decompressed output data, where the retrieval can be performed faster than a full computation operation.

[0035] In the method 200, at action 210, the corresponding output data may be returned to the user application by the simulator after a simulated idle time associated with the calculation of the corresponding output data by the simulated architecture. In an example, the data return module 118, for example, in conjunction with the processor(s) 102, the memory / memories 104, the operating system 106, the simulator 112, etc., may return the corresponding output data to the user application after a simulated idle time associated with the calculation of the corresponding output data by the simulated architecture. For example, the data return module 118 may return the output data retrieved from the memory / memories 104 during this run of the simulator 112 without calculation. The idle time may correspond to the time that the simulation architecture calculates the output data to provide the simulator 112 performance that is more closely aligned with the actual performance of the simulated actual architecture. In addition, in one example, the data return module 118 may return the output data to the user application 110 using DMA (e.g., based on DMA information received from the user application 110). In one example, the output preparation module 114 may prepare the data for output after the simulated idle time, and the data return module 118 may return the prepared data. In either case, simulator 112 may wait for simulation idle time before returning prepared data.

[0036] In method 200, optionally at action 212, a simulated idle time can be obtained or calculated based on a throughput metric associated with the simulated architecture. In an example, the idle time calculation module 116, for example, in combination with (multiple) processors 102, memory / multiple memories 104, operating system 106, simulator 112, etc., can obtain or calculate the simulated idle time based on a throughput metric associated with the simulated architecture. For example, the simulated architecture can be associated with a throughput metric achievable using a corresponding processor (e.g., (multiple) FPGAs, (multiple) GPUs, (multiple) DPUs, (multiple) SmartNICs, etc.). The throughput metric can be used to generate an idle time that the data return module 118 can wait before returning the corresponding output data to the user application to better represent the performance of the architecture of the simulated hardware offload system. For example, the idle time calculation module 116 can calculate the idle time t based on a formula similar to the following:

[0037]

[0038] Size 输入数据is the size of the input data received from the user application, and tps may be the throughput associated with the architecture of the hardware offload system (e.g., the throughput of a higher performance processor or associated hardware IP core, etc.). The size of the input data may be determined on a set of input data from the user application 110 during a first run of the simulator 112. Additionally, the throughput metric may be configured to allow simulation of other architectures having different throughput metrics.

[0039] Thus, when obtaining or calculating simulated idle time at action 212, for example, optionally at action 214, the throughput metric can be configured to implement a performance metric in a simulated architecture. In an example, the idle time calculation module 116, for example, in conjunction with the (multiple) processors 102, the memory / multiple memories 104, the operating system 106, the simulator 112, etc., can configure the throughput metric to implement a performance metric in a simulated architecture. In one example, the idle time calculation module 116 can provide an interface that allows the specification of a throughput metric for the architecture of the hardware to be simulated or communicate with an interface that allows the specification of a throughput metric for the architecture of the hardware to be simulated. Thus, the idle time calculation module 116 can calculate and provide idle time based on the hardware offload system performance to allow for a more accurate or precise simulation of the actual architecture of the hardware offload system.

[0040] In some examples, the performance of the simulation architecture may be tracked or measured by simulator 112, by user application 110, or by a different application. For example, the performance of the calculation of simulation output data, or other metrics such as the speed of operation, the speed at which data processing is completed, processor speed, memory capacity or performance, the number of memory accesses, the time of memory accesses, etc. may be monitored while the simulator 112 is executing.

[0041] Figure 3is a schematic diagram of an example of a system 300 for executing a simulator for a hardware offload system according to aspects described herein. For example, the system 300 may include a user application 110 and a simulator 112, as described. The simulator 112 may include a simulator firmware 302 for performing a simulation of a hardware offload system architecture, a perform calculation step 304, and a dynamic random access memory (DRAM) 306 for storing output data during one run of the simulation for use in the next run of the simulation. For example, the simulator firmware 302 may be executed on one or more processors, such as (multiple) processors 102 that may include a CPU. In addition, for example, the DRAM 306 may be similar to or may include at least a portion of the memory / memories 104. According to aspects described herein, at the perform calculation step 304, a memory retrieval operation 308 may be performed to obtain output data corresponding to the input data from the DRAM 306, rather than calculating the output data. As described, for example, simulator 112 may perform a previous run of a simulation in which output data was calculated, and may store the calculated output data in DRAM 306 for use in subsequent runs of the simulation to provide more accurate performance for the architecture of the simulated hardware offload system.

[0042] In the system 300, the user application 110 may send a command 310 to the simulator 112 to simulate. The user application 110 may then send DMA data 312 to the simulator 112. The simulator firmware 302 may simulate the architecture of the hardware offload system to receive input data using DMA, process the data (e.g., by performing a calculation step 304), and provide the resulting output data to the user application 110 via DMA (e.g., DMA data 314). The simulator 112 may then send a completion entry (CQE) 316 to the user application 110 to indicate that the output data has been returned. In an example, during the execution of the calculation step 304, the output data previously stored in the DRAM 306 is retrieved from the DRAM 306 instead of calculating the output data. In addition, during the execution of the calculation step 304, the simulator 112 may wait for an idle time before returning the output data to the user application 110 via the DMA data 314.

[0043] The goal of the simulator 112 may be to obtain correct output data, and it may not be important how the hardware offload system achieves computing the correct output data. Therefore, the process of the offload operation performed in the execution calculation step 304 can be viewed as a black box. In this regard, a memory retrieval operation can be used to obtain the output data, which can have a higher speed performance than the calculation operation, which can offset the performance difference between the (multiple) processors 102 executing the simulator 112 and the higher performance processors of the simulated hardware offload system. In addition, the server (e.g., device 100) executing the simulator 112 can have sufficient memory capacity for storing the results of the calculations of the simulated architecture (e.g., as obtained in an initial or previous run of the simulator 112 on input data from the user application 110).

[0044] For example, the simulator 112 can be utilized for a specific workload of input data from the user application 110. In this example, output data calculated for the input data during a first run of the simulation can be cached in the DRAM 306. In a later run, the output data cached in the DRAM 306 can be retrieved and output to the user application 110 based on the configurable IP core performance (e.g., based on a configured throughput metric and an associated computed idle time, as described). Thus, for example, the simulation architecture can be idle for a specific period of time, and then output data selected from the cached data of a set of input data can be returned to the user application 110. In this regard, the throughput of the simulated IP core can become a configurable parameter, as described. In addition, for example, the throughput metric can be tuned to execute the simulator 112 with different simulation architectures (e.g., the throughput metric or the associated idle time can be halved to simulate twice the performance of the offload IP core). Thus, using the simulator 112, the hardware offload system or IP can be executed at a controlled desired performance, and / or the end-to-end system performance can be tested with an increase (or decrease) in the number of hardware offload IPs.

[0045] Figure 4 An example of a device 400 is shown, which is similar to the device 100 ( Figure 1 ) are similar or identical, including Figure 1 . In one implementation, device 400 may include processor(s) 402, which may be similar to processor(s) 102, for performing processing functions associated with one or more of the components and functions described herein. Processor(s) 402 may include a single or multiple groups of processors or a multi-core processor. Furthermore, processor(s) 402 may be implemented as an integrated processing system and / or a distributed processing system.

[0046] The device 400 may also include a memory / memories 404, which may be similar to the memory / memories 104, such as for storing local versions of applications executed by the processor(s) 402, such as the emulator 112, related modules, instructions, parameters, etc. The memory / memories 404 may include types of memory available to a computer, such as random access memory (RAM), read-only memory (ROM), tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof.

[0047] In addition, the device 400 may include a communication module 406 that provides for establishing and maintaining communications with one or more other devices, parties, entities, etc. using hardware, software, and services as described herein. The communication module 406 may carry communications between modules on the device 400, as well as communications between the device 400 and external devices (such as devices located across a communication network and / or devices connected serially or locally to the device 400). For example, the communication module 406 may include one or more buses, and may also include a transmit chain module and a receive chain module associated with a wireless or wired transmitter and receiver, respectively, which are operable to interface with external devices.

[0048] Additionally, the device 400 may include a data store 408, which may be any suitable combination of hardware and / or software that provides mass storage of information, databases, and programs employed in conjunction with the implementations described herein. For example, the data store 408 may be or may include a data repository of applications and / or related parameters (e.g., simulator 112, related modules, instructions, parameters, etc.) being executed or not currently being executed by the processor(s) 402. Furthermore, the data store 408 may be a data repository for the simulator 112, related modules, instructions, parameters, etc., and / or one or more other modules of the device 400.

[0049] Device 400 may include a user interface module 410 that is operable to receive input from a user of device 400 and may also be operable to generate output for presentation to the user. User interface module 410 may include one or more input devices, including but not limited to a keyboard, a numeric keypad, a mouse, a touch-sensitive display, navigation keys, function keys, a microphone, a speech recognition component, a gesture recognition component, a depth sensor, a gaze tracking sensor, a switch / button, any other mechanism capable of receiving input from a user, or any combination thereof. In addition, user interface module 410 may include one or more output devices, including but not limited to a display, a speaker, a tactile feedback mechanism, a printer, any other mechanism capable of presenting output to a user, or any combination thereof.

[0050] For example, any combination of an element, any part of an element, or an element can be implemented with a "processing system" including one or more processors. Examples of processors include microprocessors, microcontrollers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout this disclosure. One or more processors in a processing system can execute software. Software should be broadly interpreted as meaning instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, processes, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description languages, or otherwise.

[0051] Therefore, in one or more implementations, one or more of the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on a computer-readable medium or encoded as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media. The storage medium may be any available medium that can be accessed by a computer. For example, but not limited to, such a computer-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer. The disks and optical disks used herein include compact disks (CDs), laser optical disks, optical disks, digital versatile disks (DVDs), and floppy disks, wherein the disks typically reproduce data magnetically, while the optical disks reproduce data optically using lasers. The above combinations should also be included in the scope of computer-readable media.

[0052] The previous description is provided to enable those skilled in the art to practice the various implementations described herein. Various modifications to these implementations will be apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations. Therefore, the claims are not intended to be limited to the implementations shown herein, but should be given a full scope consistent with the language claims, wherein references to singular elements are not intended to mean "one and only one", unless explicitly stated, but "one or more". Unless otherwise explicitly stated, the term "some" refers to one or more. All structural and functional equivalents that are known to or later become known to those of ordinary skill in the art and are identical to the elements of the various implementations described herein are intended to be covered by the claims. In addition, regardless of whether such disclosures are explicitly recorded in the claims, anything disclosed herein is not intended to be dedicated to the public. Unless the element is explicitly recorded using the phrase "module for...", any claim element should not be interpreted as a module plus function.

Claims

1. A computer-implemented method for simulating the performance of a hardware offload system, comprising: receiving, by a simulator corresponding to a simulation architecture representing the hardware offload system, input data from a user application for processing by the simulation architecture; preparing, by the simulator, corresponding output data for the input data without computing the corresponding output data by the simulation architecture; as well as The corresponding output data is returned by the simulator to the user application after a simulation idle time associated with computing the corresponding output data by the simulation architecture. 2 . The computer-implemented method of claim 1 , wherein preparing the corresponding output data comprises retrieving the corresponding output data from a memory, wherein the corresponding output data was calculated during a previous run of the simulator and stored in the memory.

3. A computer-implemented method according to claim 2, wherein the corresponding output data was mapped to the input data in the memory during the previous run of the simulator, and wherein preparing the corresponding output data includes retrieving the corresponding output data mapped to the input data.

4. The computer-implemented method of claim 1 , further comprising: The simulated idle time is calculated based on a throughput metric associated with the simulated architecture.

5. The computer-implemented method of claim 4, wherein the simulated idle time is a function of the throughput metric and a size of the input data.

6. The computer-implemented method of claim 4, further comprising: The throughput metric is configured to implement a performance metric in the simulation architecture.

7. The computer-implemented method of claim 1, wherein the simulator is executed by a first processor, and wherein the simulation architecture is associated with one or more second processors having higher performance parameters than the first processor.

8. The computer-implemented method of claim 1 , further comprising: Direct memory access (DMA) information is received from the user application, wherein returning the corresponding output data to the user application is via DMA to the user application.

9. An apparatus for simulating performance of a hardware offload system, the apparatus comprising one or more processors and one or more non-transitory memories having instructions thereon, wherein the instructions, when executed by the one or more processors, cause the one or more processors to: receiving, by a simulator corresponding to a simulation architecture representing the hardware offload system, input data from a user application for processing by the simulation architecture; preparing, by the simulator, corresponding output data for the input data without computing the corresponding output data by the simulation architecture; as well as The corresponding output data is returned by the simulator to the user application after a simulation idle time associated with computing the corresponding output data by the simulation architecture.

10. An apparatus according to claim 9, wherein the instructions, when executed by the one or more processors, cause the one or more processors to prepare the corresponding output data at least in part by retrieving the corresponding output data from a memory, wherein the corresponding output data was calculated during a previous run of the simulator and stored in the memory.

11. An apparatus according to claim 10, wherein the corresponding output data was mapped to the input data in the memory during the previous operation of the simulator, and wherein the instructions, when executed by the one or more processors, cause the one or more processors to prepare the corresponding output data at least in part by retrieving the corresponding output data mapped to the input data.

12. The apparatus of claim 9, wherein the instructions, when executed by the one or more processors, cause the one or more processors to calculate the simulated idle time based on a throughput metric associated with the simulated architecture.

13. The apparatus of claim 12, wherein the simulated idle time is a function of the throughput metric and a size of the input data.

14. The apparatus of claim 12, wherein the instructions, when executed by the one or more processors, cause the one or more processors to configure the throughput metric to implement a performance metric in the simulation architecture.

15. The apparatus of claim 9, wherein the simulator is executed by a first processor, and wherein the simulation architecture is associated with one or more second processors having higher performance parameters than the first processor.

16. The apparatus of claim 9, wherein the instructions, when executed by the one or more processors, cause the one or more processors to receive direct memory access (DMA) information from the user application, wherein returning the corresponding output data to the user application is via DMA to the user application.

17. One or more non-transitory computer-readable storage media storing instructions that, when executed by one or more processors, cause the one or more processors to perform a method for simulating performance of a hardware offload system, wherein the method comprises: receiving, by a simulator corresponding to a simulation architecture representing the hardware offload system, input data from a user application for processing by the simulation architecture; preparing, by the simulator, corresponding output data for the input data without computing the corresponding output data by the simulation architecture; as well as The corresponding output data is returned by the simulator to the user application after a simulation idle time associated with computing the corresponding output data by the simulation architecture.

18. The one or more non-transitory computer-readable storage media of claim 17, wherein preparing the corresponding output data comprises retrieving the corresponding output data from a memory, wherein the corresponding output data was calculated during a previous run of the simulator and stored in the memory.

19. One or more non-transitory computer-readable storage media according to claim 18, wherein the corresponding output data was mapped to the input data in the memory during the previous run of the simulator, and wherein preparing the corresponding output data includes retrieving the corresponding output data mapped to the input data.

20. The one or more non-transitory computer-readable storage media of claim 17, the method further comprising calculating the simulated idle time based on a throughput metric associated with the simulated architecture.

Images