Method for determining hardware design parameters, parameter performance simulation system, device and product

Abstract

This application provides a method, a parameter performance simulation system, an apparatus, and a product for determining hardware design parameters. The method includes: generating multiple sets of different hardware parameter combinations; simulating a data processing process for each set of hardware parameter combinations, the data processing process including reading source data based on a descriptor table and performing compression or decompression processing, and writing the processed target data to a target address; wherein, when simulating the data processing process for any hardware parameter combination, the structure of the descriptor table matches that hardware parameter combination; and determining the hardware parameter combination that maximizes the efficiency of data compression or decompression processing based on the time consumed by simulating the data processing process for each set of hardware parameter combinations. This method enables a systematic and quantitative comparison of descriptor depth, descriptor granularity, and data block size before hardware physical implementation, thereby avoiding the blindness caused by relying on design experience to predict parameters.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for determining hardware design parameters, a parameter performance simulation system, equipment, and product. Background Technology

[0002] In modern data centers, high-performance computing, and edge storage scenarios, real-time and efficient data compression and decompression are key to improving effective storage capacity and reducing data transmission bandwidth. Therefore, dedicated hardware acceleration engines for compression / decompression are widely integrated into system-on-chips, smart network interface cards (NICs), or storage controllers. These engines typically employ a descriptor-based direct memory access mechanism. Software drives the filling of the data to be processed into a descriptor structure in memory, while the hardware engine polls to obtain and parse valid descriptors, thereby asynchronously completing data transfer and compression / decompression calculations to achieve high throughput.

[0003] In related technologies, the design of such compression / decompression hardware acceleration engines relies heavily on the designer's experience and estimations to determine architectural parameters such as the depth of the descriptor buffer, the granularity of the descriptor, and the size of the data block in a single direct memory access operation.

[0004] However, designers' experience-based predictions are often inaccurate. Before the physical implementation of the hardware, it is impossible to accurately and efficiently determine the combination of hardware architecture parameters that achieves the optimal balance between compression / decompression processing efficiency and resource consumption. As a result, hardware designs are often delivered in a suboptimal state, facing the risk of wasted on-chip resources or throughput not meeting expectations. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a method, parameter performance simulation system, device, and product for determining hardware design parameters. This method enables a systematic quantitative comparison of descriptor depth, descriptor granularity, and data block size before physical hardware implementation, thereby avoiding the blindness caused by relying on design experience to predict parameters.

[0006] The first aspect of this application provides a method for determining hardware design parameters, comprising: generating multiple sets of different hardware parameter combinations, each hardware parameter combination including the number of first-level descriptors in a descriptor table, the number of second-level descriptors pointed to by the first-level descriptors, and the size of the data blocks pointed to by the second-level descriptors; the descriptor table being applied to a hardware acceleration engine for storing data information, the hardware acceleration engine being used to perform data compression and / or decompression processing; simulating a data processing process for each set of hardware parameter combinations, the data processing process including reading source data based on the descriptor table and performing compression or decompression processing, and writing the processed destination data to a target address; wherein, when simulating the data processing process for any hardware parameter combination, the structure of the descriptor table is matched with that hardware parameter combination; and determining the hardware parameter combination that maximizes the efficiency of data compression or decompression processing based on the time consumed by simulating the data processing process for each set of hardware parameter combinations.

[0007] In some implementations, the descriptor table in this method includes a source descriptor table for storing source data information and a destination descriptor table for storing destination data information; reading source data based on the descriptor table and performing compression or decompression processing, and writing the processed destination data to the target address, includes: reading source data based on the source descriptor table and performing compression or decompression processing, and writing the processed destination data information to the destination descriptor table.

[0008] In some implementations, the method further includes: writing data information from the input data file into the source descriptor table; and writing destination data into the output data file based on the destination descriptor table.

[0009] In some implementations, data information from the input data file is written to the source descriptor table, including: querying the source first-level descriptor whose status flag value is the first value, indicating that the descriptor is available; if a source first-level descriptor with the status flag value of the first value is found, data from the input data file is filled into the data block pointed to by the second-level descriptor pointed to by that source first-level descriptor; if all data blocks pointed to by the second-level descriptor are filled, the status flag value of the source first-level descriptor is updated to the second value, indicating that the descriptor is unavailable.

[0010] In some implementations, source data is read from the source descriptor table and compressed or decompressed. This includes: querying the source-level descriptor table for a status flag value of the second value; if a source-level descriptor with the second value is found, a delay function is created and the system enters a sleep state; the delay function updates the status flag value of the source-level descriptor to the first value after a first delay, and the sleep duration is the second duration; the first duration is determined based on the transmission delay characteristics of the data bus, and the second duration is determined based on the data block size and data compression ratio corresponding to the current hardware parameter combination; upon exiting the sleep state, the system confirms the completion of data compression or decompression and generates the simulated target data.

[0011] In some implementations, the processed destination data information is written into the destination descriptor table, including: querying the destination first-level descriptor table with a status flag value of the first value; if a destination first-level descriptor with a status flag value of the first value is found, filling the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor with simulated destination data; if all data blocks pointed to by the second-level descriptor pointed to by the destination first-level descriptor are filled, updating the status flag value of the destination first-level descriptor to the second value.

[0012] In some implementations, destination data is written to the output data file based on the destination descriptor table, including: querying the destination first-level descriptor with a status flag value of the second value from the destination descriptor table, where the second value indicates that the descriptor is unavailable; if a destination first-level descriptor with a status flag value of the second value is found, reading data based on the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor and writing it to the output data file; if all the data corresponding to the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor has been written to the output data file, updating the status flag value of the destination first-level descriptor to the first value, where the first value indicates that the descriptor is available.

[0013] In some implementations, the simulation unit determines the hardware parameter combination that maximizes the efficiency of data compression or decompression based on the time consumed by simulating the data processing process for each set of hardware parameter combinations. This includes: determining the number of secondary descriptor targets that maximizes the cost-effectiveness of data compression or decompression based on the time consumed by simulating the data processing process for each set of hardware parameter combinations; and determining the number of primary descriptor targets and the data block size that maximize the efficiency of data compression or decompression based on the number of secondary descriptor targets and the time consumed by simulating the data processing process for each set of hardware parameter combinations.

[0014] A second aspect of this application provides a parameter performance simulation system, comprising: a storage unit for simulating and maintaining a descriptor table, the descriptor table including a primary descriptor, secondary descriptors pointed to by the primary descriptors, and data blocks pointed to by the secondary descriptors; the descriptor table is applied to a hardware acceleration engine for storing data information, the hardware acceleration engine for performing data compression and / or decompression processing; a control unit for generating multiple different hardware parameter combinations, the hardware parameter combination including the number of primary descriptors in the descriptor table, the number of secondary descriptors pointed to by the primary descriptors, and the size of the data blocks pointed to by the secondary descriptors; a simulation unit for simulating a data processing process for each hardware parameter combination generated by the control unit, the data processing process including reading source data from the descriptor table of the storage unit and performing compression or decompression processing, and writing the processed destination data into the descriptor table of the storage unit; wherein, when the simulation unit simulates the data processing process for any hardware parameter combination, the structure of the descriptor table in the storage unit matches the hardware parameter combination; the control unit is also used to determine the hardware parameter combination that maximizes the efficiency of data compression or decompression processing based on the time consumed by the simulation unit in simulating the data processing process for each hardware parameter combination.

[0015] A third aspect of this application provides an electronic device, comprising: a memory and a processor; the memory is connected to the processor and is used to store a program; the processor is used to implement the method for determining hardware design parameters provided in any implementation of the first aspect by running the program in the memory.

[0016] The fourth aspect of this application provides a computer program product, including computer program instructions, which, when run by a processor, cause the processor to execute a method for determining hardware design parameters provided in any implementation of the first aspect described above.

[0017] In the design of compression / decompression hardware acceleration engines, the lack of means to quantitatively analyze real data streams and the complete system environment before hardware implementation leads to the blind determination of key microarchitectural parameters such as the number of first-level descriptors, the number of second-level descriptors, and the data block size. This application addresses this issue by generating multiple sets of different hardware parameter combinations and simulating a complete data compression or decompression process using a structurally matched descriptor table for each parameter combination. The time consumed in each simulated data processing iteration is used as the basis for parameter selection. This allows for a systematic quantitative comparison of descriptor depth, descriptor granularity, and data block size before physical hardware implementation. This avoids the blindness caused by relying on design experience to predict parameters, enabling the hardware design to obtain a near-optimal parameter starting point verified by simulation early in the project. This ensures that the actual designed hardware acceleration engine has good performance while reducing the time and cost of design space exploration. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the architecture of a parameter performance simulation system provided in an embodiment of this application.

[0020] Figure 2 This is a flowchart illustrating a method for determining hardware design parameters provided in an embodiment of this application.

[0021] Figure 3 This is a schematic diagram of another parameter performance simulation system provided in an embodiment of this application.

[0022] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0024] In the design of hardware acceleration engines for compression and decompression, to achieve descriptor-based data compression or decompression, a common approach is for the software driver to fill the source address, destination address, and data size of the data to be processed into the descriptor table and set a valid flag. The hardware engine polls valid descriptors, initiates direct memory access to read data from the source address, processes it through the compression or decompression core, writes the result to the destination address via direct memory access, and finally writes back the descriptor state. This scheme transfers tasks between the software driver and the hardware engine through the descriptor table, enabling data movement and computation to be executed in a pipelined manner. Therefore, it is widely used in data compression and decompression acceleration scenarios in systems-on-chips, smart network interface cards, and storage controllers.

[0025] In related technologies, the design of such compression / decompression hardware acceleration engines relies heavily on the designer's experience and estimations to determine architectural parameters such as the depth of the descriptor buffer, the granularity of the descriptor, and the size of the data block in a single direct memory access operation.

[0026] However, designers' experience-based predictions are often inaccurate. Before the physical implementation of the hardware, it is impossible to accurately and efficiently determine the combination of hardware architecture parameters that achieves the optimal balance between compression / decompression processing efficiency and resource consumption. As a result, hardware designs are often delivered in a suboptimal state, facing the risk of wasted on-chip resources or throughput not meeting expectations.

[0027] For example, when decompressing files of tens of gigabytes, the output data size is unknown until processing is complete. Inappropriate parameter configuration can cause hardware stalls, descriptor chain breaks, or memory overflows, resulting in a decrease in effective throughput.

[0028] In addition, software simulation can be used for parameter evaluation. However, traditional simulation models usually simulate data movement, calculation and state write-back in sequence, which cannot reflect the time overlap of descriptor release, calculation and bus access in real hardware. The simulation fidelity is insufficient, the reliability of the parameter conclusions is limited, and parameter optimization often needs to be carried out after RTL or even FPGA implementation, which is time-consuming and costly.

[0029] To address the aforementioned technical problems, this application proposes a different technical approach. The core concept of this application is to generate multiple sets of different hardware parameter combinations, each combination including the number of first-level descriptors in the descriptor table, the number of second-level descriptors pointed to by the first-level descriptors, and the size of the data blocks pointed to by the second-level descriptors. For each set of hardware parameter combinations, using source and destination descriptor tables with structures matching that combination, the complete data processing process is simulated: writing from the input data file to the source descriptor table, reading source data based on the source descriptor table and performing compression or decompression, writing the processed destination data to the destination descriptor table, and writing it out to the output data file. Then, based on the simulated data processing time corresponding to each set of hardware parameter combinations, the target value for the number of second-level descriptors and the target combination of the number of first-level descriptors and the data block size are determined in stages. This application solves the problems of parameter determination relying on empirical estimation and insufficient simulation fidelity in related technologies, achieving hardware parameter determination based on quantized simulation before hardware physical implementation.

[0030] Figure 1 This is a schematic diagram of the architecture of a parameter performance simulation system provided in an embodiment of this application.

[0031] See Figure 1 As shown, the parameter performance simulation system includes a test control layer, a simulation core layer, and a circular buffer layer. The test control layer contains control units, the simulation core layer contains simulation units, and the circular buffer layer contains storage units. The control units are connected to the simulation units via a parameter configuration interface, and the simulation units are connected to the storage units via a descriptor interaction interface.

[0032] The test control layer is implemented using automated scripts. The control unit is used to maintain simulation parameter configurations, send parameter combinations to the simulation unit, and receive statistical information such as processing time and throughput returned by the simulation unit.

[0033] The simulation core layer is implemented by a multi-threaded application. The simulation unit runs a source thread, a hardware simulation thread, and a destination thread. The source thread reads source data from the input data file and fills the corresponding data block in the source descriptor table. The hardware simulation thread reads source data according to the source descriptor table, simulates compression or decompression processing, and writes the processed destination data into the corresponding data block in the destination descriptor table. The destination thread reads destination data from the destination descriptor table and writes the destination data to the output data file.

[0034] The circular buffer layer resides in shared memory. The storage unit maintains the source and destination descriptor tables, as well as the data buffer associated with the descriptor tables. Both the source and destination descriptor tables include a first-level descriptor, a second-level descriptor pointed to by the first-level descriptor, and a data block pointed to by the second-level descriptor. The first-level descriptor carries a status flag indicating whether the corresponding descriptor is available. Access to the status flags by each thread in the simulation unit is performed atomically, and the source and destination descriptor tables are used cyclically during the simulation.

[0035] The aforementioned parameter performance simulation system can run on any device or apparatus. For example, the parameter performance simulation system code can be run on the processor of any device or apparatus to realize the functions of the aforementioned parameter performance simulation system.

[0036] Based on the aforementioned parameter performance simulation system, this application provides a method for determining hardware design parameters. This method can be executed by the aforementioned parameter performance simulation system, specifically by a processor running the aforementioned parameter performance simulation system.

[0037] See Figure 2 As shown, the method includes: S101, Generate multiple different combinations of hardware parameters.

[0038] The hardware parameter combination includes the number of first-level descriptors in the descriptor table, the number of second-level descriptors pointed to by the first-level descriptors, and the size of the data block pointed to by the second-level descriptors; the descriptor table is applied to the hardware acceleration engine to store data information, and the hardware acceleration engine is used to perform data compression and / or decompression processing.

[0039] Specifically, in this embodiment, the descriptor table can adopt a multi-level descriptor structure, which may include a first-level descriptor, second-level descriptors pointed to by the first-level descriptors, and data blocks pointed to by the second-level descriptors. The number of first-level descriptors is denoted as N, the number of second-level descriptors pointed to by each first-level descriptor is denoted as M, and the size of the data block pointed to by each second-level descriptor is denoted as B. A first-level descriptor may include an address field, a status flag field, and information indicating the number of associated second-level descriptors; a second-level descriptor may include an address field and a data block size field, where the address field points to the corresponding data block. The descriptor table is used to store data information, which may include the address of the source data, the address of the destination data, the data block size, the descriptor status, and control information related to data movement.

[0040] The hardware acceleration engine can be a descriptor-based compression and / or decompression hardware acceleration engine. Its key parameters to be determined include the number of primary descriptors (N), the number of secondary descriptors (M) pointed to by the primary descriptors, and the size of the data block pointed to by the secondary descriptors (B). The hardware acceleration engine can include a descriptor acquisition and parsing unit, a data transfer channel, and a compression / decompression computation core. The descriptor acquisition and parsing unit is used to acquire and parse tasks according to the descriptor table. The data transfer channel is used to transfer data according to the address and B in the secondary descriptors. The compression / decompression computation core is used to perform compression or decompression processing on the read source data. Since N, M, and B affect the depth of the descriptor circular buffer, the descriptor subdivision granularity, and the granularity of a single data transfer, the combination of these parameters will jointly affect hardware throughput, processing latency, and buffer resource usage.

[0041] In this embodiment, the hardware parameter combination includes three dimensions: the number of first-level descriptors N in the descriptor table, the number of second-level descriptors M pointed to by the first-level descriptors, and the data block size B pointed to by the second-level descriptors. These three parameters jointly determine the hierarchical structure and data granularity of the descriptor table. The number of first-level descriptors N determines the depth of the descriptor circular buffer, affecting the hardware's ability to hide input / output (I / O) latency; the number of second-level descriptors M determines the number of data streams that can be processed in parallel under each first-level descriptor, affecting hardware scheduling complexity; and the data block size B determines the data granularity of a single Direct Memory Access (DMA) operation, affecting transmission efficiency and buffer utilization. The joint parameterization of these three parameters allows design space exploration to cover all key dimensions affecting hardware performance.

[0042] When generating multiple different combinations of hardware parameters, these combinations can be generated under fixed hardware resource constraints. For example, the total on-chip buffer capacity C_total = N × M × B (where N is the number of first-level descriptors, M is the number of second-level descriptors, and B is the data block size) can be fixed, and a series of representative parameter combinations can be generated under this constraint. Generating parameter combinations under constant hardware resource constraints ensures that all tests are fairly compared at the same hardware cost, thus purely revealing the impact of the parameter structure itself on performance, rather than performance differences caused by different total resources. This allows the finally determined optimal parameter combination to achieve the best balance between throughput and resource efficiency within a given resource budget.

[0043] For example, the total on-chip buffer capacity C_total can be 4MB, 8MB, or 16MB. Different C_total values ​​correspond to different hardware resource budget levels. Experiments show that increasing from 4MB to 8MB results in a significant performance gain (greater than 15%), while increasing from 8MB to 16MB results in a small performance gain (less than 5%). Therefore, choosing an appropriate C_total helps determine the buffer capacity configuration with the highest resource utilization.

[0044] In some embodiments, multiple sets of different hardware parameter combinations can be generated by the control unit in the parametric performance simulation system, each set including N, M, and B. For example, with a fixed total on-chip buffer capacity C_total for simulation, multiple candidate combinations can be generated according to C_total = N × M × B, allowing comparison of different candidate combinations under similar hardware resource constraints. As an example, C_total can be set to 8MB, and candidate combinations can include N=8, M=1, B=1024KB, N=16, M=1, B=512KB, or N=32, M=2, B=128KB, etc. The above values ​​are merely examples for illustrative purposes; in other embodiments, C_total, N, M, and B can be adjusted according to the target hardware resources, total data volume, and compression or decompression load characteristics.

[0045] S102. Simulate the data processing process for each group of hardware parameter combinations.

[0046] The data processing procedure includes reading source data based on a descriptor table and performing compression or decompression, as well as writing the processed destination data to a target address. When simulating the data processing procedure for any combination of hardware parameters, the structure of the descriptor table is matched to that hardware parameter combination.

[0047] Specifically, in this embodiment, for any combination of hardware parameters, the simulation unit establishes a descriptor table in the storage unit that matches the combination of hardware parameters. Matching means that the number of first-level descriptors in the descriptor table equals N in the combination, the number of second-level descriptors associated with each first-level descriptor equals M in the combination, and the size of the data block pointed to by each second-level descriptor equals B in the combination. Therefore, different parameter combinations correspond to different descriptor table structures, and the simulation unit operates based on the descriptor organization method corresponding to that parameter combination when subsequently processing source data, generating target data, and recording time consumption.

[0048] The simulation unit can simulate the data processing process through a multi-threaded application. This multi-threaded application can include a source thread for simulating software-driven task submission, a hardware simulation thread for simulating hardware behavior, and a destination thread for collecting simulation results. The source thread can read source data from the input data file and, according to the descriptor table corresponding to the current hardware parameter combination, fill the data block pointed to by the secondary descriptor. The hardware simulation thread can read source data based on the descriptor table, simulate data movement, compression, or decompression processing by the hardware acceleration engine, and generate simulated destination data. The destination thread can write the processed destination data to a target address, which can be a destination data buffer in shared memory or a write location in the output data file.

[0049] During the simulated data processing, the simulation unit reads the source data based on the descriptor table and performs compression or decompression. Specifically, the hardware simulation thread can locate the data block containing the source data according to the pointing relationship between the first-level and second-level descriptors, and determine the data granularity for this processing based on the current B. For compression processing, the hardware simulation thread can simulate the size of the compressed target data and processing latency based on the preset compression ratio and data block size; for decompression processing, the hardware simulation thread can simulate the size of the decompressed target data and processing latency based on the input compressed data, the preset compression ratio, and the data block size. This simulation process does not require the actual implementation of a specific compression algorithm, and the processing time of the compression / decompression calculation core can also be characterized by the computational latency related to B and the compression ratio.

[0050] After compression or decompression, the simulation unit writes the processed destination data to the target address. The target address can be determined by the address field in the descriptor table, for example, by the address field in the secondary descriptor pointing to the destination data block. If the source and destination descriptor tables are used to maintain the source and destination data respectively, the hardware simulation thread can fill the obtained simulated destination data into the corresponding data block in the destination descriptor table after the calculation is completed, and then the destination thread writes the data to the output data file. If a unified descriptor table is used for abstract simulation, the source and destination address information in the descriptor table can indicate the read and write positions respectively. All of the above implementations can be used to characterize the data link of the hardware acceleration engine reading source data and outputting processing results based on descriptors.

[0051] S103. Based on the time consumed by simulating the data processing process for each set of hardware parameter combinations, determine the hardware parameter combination that maximizes the efficiency of data compression or decompression.

[0052] Specifically, the control unit records the data processing time for each combination of hardware parameters. This time can be the total processing time T_total from the start of processing the specified total amount of data to the completion of writing the target data to the target address. With a fixed total amount of data, a shorter T_total indicates a higher simulation throughput for that hardware parameter combination. The control unit can also calculate the throughput based on T_total, for example, by dividing the total amount of data by T_total to obtain the amount of data processed per unit time. It can also simultaneously record auxiliary statistics such as thread activity time and resource usage to analyze the impact of parameter changes on performance.

[0053] In some embodiments, the control unit can set the total amount of data to be processed to a fixed value, such as performing a decompression simulation on a compressed file of a fixed size, or performing a compression simulation on a source file of a fixed size. The control unit sequentially sends each set of N, M, and B to the simulation unit. The simulation unit reinitializes the descriptor table and associated data blocks according to the current parameters, and returns T_total after completing the complete data processing simulation. The control unit writes each set of parameters and the corresponding T_total into the performance data set, and sorts, filters, or performs multidimensional analysis on the performance data set after all candidate combinations have been run.

[0054] Based on the simulation data processing time corresponding to each hardware parameter combination, the control unit determines the hardware parameter combination that maximizes the efficiency of data compression or decompression. The determination method can include: selecting the hardware parameter combination with the shortest T_total; or, when the difference in T_total is less than a set threshold, selecting the hardware parameter combination with higher resource utilization and lower descriptor control complexity; or, under a fixed C_total condition, first eliminating combinations with significantly longer processing times, and then determining the recommended combination from the remaining combinations by considering the impact of N, M, and B on hardware implementation complexity. Therefore, the resulting parameters not only reflect simulation performance but also coordinate with hardware resource constraints.

[0055] For example, with C_total fixed at 8MB, simulations of different combinations of N, M, and B reveal that some combinations, while having larger data blocks, have fewer first-level descriptors, resulting in weaker latency concealment capabilities under load fluctuations or I / O wait scenarios. Other combinations have a deeper number of first-level descriptors, better maintaining pipeline continuity, but if B is too small, it may lead to higher descriptor scheduling overhead. By comparing using T_total as a unified quantification metric, a more suitable parameter configuration for the target hardware acceleration engine can be achieved between descriptor depth, descriptor granularity, and data block size.

[0056] This application's embodiments generate multiple sets of N, M, and B combinations before hardware physical implementation, and construct a matching descriptor table for each combination to perform a complete data processing simulation. This eliminates the reliance on design experience for parameter selection. Since each simulation covers the process of reading source data based on descriptors, performing compression or decompression, and writing destination data, the resulting processing time T_total reflects the synergistic effects between descriptor organization, data block granularity, and processing latency. Therefore, simulation-verified parameter combinations can be obtained early in the hardware design process, providing quantitative basis for the design of subsequent descriptor acquisition and parsing units, data transfer channels, and compression / decompression calculation cores. This ensures that the actual designed hardware acceleration engine has good performance and avoids wasting design resources.

[0057] In some embodiments, the descriptor table is divided into a source descriptor table and a destination descriptor table. The source descriptor table stores source data information, and the destination descriptor table stores destination data information. Source data includes data to be compressed or decompressed, and source data information may include the address of the data block containing the source data, the size of the data block, and the status flags of the corresponding descriptor. Destination data includes data obtained after compression or decompression, and destination data information may include the address of the data block containing the destination data, the size of the data block, and the status flags of the corresponding descriptor. By maintaining the source and destination descriptor tables separately, the simulation unit can simulate the behavior of the hardware acceleration engine in reading tasks at the source and writing results back at the destination, thus decoupling the data read path and write path at the descriptor level. This separation structure allows the source and destination ends to independently allocate and reclaim descriptors, avoiding resource contention when a single descriptor table simultaneously undertakes read and write tasks, and facilitating the parallelization of the read / write pipeline. The source descriptor table and the destination descriptor table maintain data address information independently, which allows the hardware engine to write processing results to the destination independently while reading source data, achieving overlap of read and write operations in time and improving the overall data processing throughput.

[0058] Specifically, the source descriptor table may include multiple source-level descriptors, one or more source-level descriptors pointed to by each source-level descriptor, and source data blocks pointed to by each source-level descriptor. The destination descriptor table may include multiple destination-level descriptors, destination-level descriptors pointed to by each destination-level descriptor, and destination data blocks pointed to by each destination-level descriptor. The source and destination descriptor tables may adopt the same or corresponding multi-level descriptor structure, that is, a first-level descriptor is used to point to a group of second-level descriptors, and a second-level descriptor is used to point to the corresponding data block. The number of first-level descriptors is N, the number of second-level descriptors pointed to by each first-level descriptor is M, and the size of the data block pointed to by each second-level descriptor is B.

[0059] In one implementation, both the source and destination descriptor tables reside in shared memory and correspond to independent data buffers. The source data block carries the source data to be compressed or decompressed, while the destination data block carries the destination data obtained after simulated compression or decompression. Both the source and destination level-one descriptors can be configured with status flags, such as a valid flag, to indicate whether the corresponding level-one descriptor is currently available for use by the corresponding thread. Reading and writing status flags by each thread can be performed atomically to reduce state contention during concurrent access.

[0060] Based on the above-mentioned source descriptor table and destination descriptor table settings, when reading source data based on the descriptor table and performing compression or decompression processing, and writing the processed destination data to the target address, specifically, the source data is read based on the source descriptor table and performed compression or decompression processing, and the processed destination data information is written to the destination descriptor table.

[0061] For example, in the simulation core layer, the simulation unit can run source threads, hardware simulation threads, and destination threads. Source threads simulate the process of software drivers submitting source data tasks to hardware. They can read source data from the input data file and fill the corresponding source data block in the source descriptor table. Hardware simulation threads simulate the processing of the hardware acceleration engine. They can read source data based on the source descriptor table, perform timing simulations of compression or decompression processing, and write the processed destination data information into the destination descriptor table. Destination threads simulate the process of software-side data retrieval. They can read destination data from the destination descriptor table and write the destination data into the output data file.

[0062] Specifically, when the hardware simulation thread performs data processing, it can poll the source-end first-level descriptors in the source-end descriptor table. When it detects that the source data corresponding to a certain source-end first-level descriptor is ready, the hardware simulation thread reads the source data from the source-end data block according to the source-end second-level descriptor pointed to by that source-end first-level descriptor, and simulates the processing latency required for compression or decompression calculation according to the data block size B corresponding to the current hardware parameter combination and the preset data compression ratio. After the processing latency is completed, the hardware simulation thread generates simulated target data, or generates target data information to represent the processing result.

[0063] After obtaining the simulated destination data, the hardware simulation thread can further poll the first-level destination descriptors in the destination descriptor table. When a first-level destination descriptor is detected to be available, the hardware simulation thread writes the simulated destination data into the destination data block corresponding to the second-level destination descriptor pointed to by that first-level destination descriptor, and updates the corresponding status in the destination descriptor table, enabling the destination thread to recognize that the destination data can be reclaimed. Thus, the data processing process forms a closed loop: reading source data from the source descriptor table, performing compression or decompression processing by the hardware simulation thread, and then writing the destination data information into the destination descriptor table.

[0064] In this embodiment, the source descriptor table and the destination descriptor table can be used cyclically in a circular buffer manner. The source thread is only responsible for filling and submitting the source descriptor resources. After acquiring the source descriptor resources, the hardware simulation thread performs source data reading and processing, and writes the results to the destination descriptor resources. The destination thread is only responsible for reading and releasing the destination descriptor resources. Since the source and destination descriptor resources are independent of each other, the source data submission process will not directly occupy the descriptor slots of the destination result recycling process, and the destination result recycling process will not directly affect the descriptor slots of the source task submission process.

[0065] By employing the above method, the simulation process can more closely approximate the actual data flow of a descriptor-based hardware acceleration engine. During compression or decompression, the output data size may vary with the compression ratio. If the source and destination share the same descriptor table, it becomes difficult to reflect the independent occupancy, release, and timing relationships between source task submission and destination result write-back. This embodiment splits the descriptor table into a source descriptor table and a destination descriptor table, allowing for separate observation of resource usage during source reading, computation, and destination write-back. This makes the processing time obtained under different hardware parameter combinations more accurately reflect the descriptor management behavior during real hardware operation.

[0066] Optionally, the number of first-level descriptors N, the number of second-level descriptors M pointed to by each first-level descriptor, and the data block size B pointed to by each second-level descriptor in the source and destination descriptor tables can be set to be the same to facilitate parameter comparison under the same resource model. Alternatively, different source and destination parameters can be set separately to simulate application scenarios where the source read capability and the destination write capability are asymmetrical, provided the simulation objectives are met. Regardless of the method used, when the simulation unit performs data processing for any combination of hardware parameters, it ensures that the structure of the source and destination descriptor tables matches that hardware parameter combination, thereby guaranteeing a correspondence between processing time and the current parameter configuration.

[0067] In one embodiment, before the simulated data processing, the source thread in the simulation core layer writes data information from the input data file into the source descriptor table in the circular buffer layer; and after the simulated data processing, the destination thread in the simulation core layer writes the destination data into the output data file based on the destination descriptor table. Therefore, the simulation process includes not only the process of the hardware simulation thread reading source data from the source descriptor table and performing compression or decompression, and then writing the processed destination data information into the destination descriptor table, but also the process of source data entering the descriptor resource and destination data being retrieved from the descriptor resource and written to disk.

[0068] Writing data from the input data file to the source descriptor table simulates the behavior of a software driver. It reads data from the input data file and fills the data buffer managed by the source descriptor table according to the current parameter configuration. This step simulates the process of a software driver submitting a compression or decompression task to the hardware in a real system, allowing the simulation to reflect the overhead of the software driver filling descriptors and its impact on overall performance. Writing destination data to the output data file based on the destination descriptor table means that after the data in the destination descriptor table is ready, the destination data is read from the data buffer managed by the destination descriptor table and written to the output data file. This step simulates the process of retrieving and writing processing results to disk in a real system, allowing the simulation to evaluate the impact of the result write-back stage on the overall processing time and ensuring that the performance evaluation covers the entire data processing chain.

[0069] Specifically, at the start of the simulation, the status flags of the first-level descriptors in the source and destination descriptor tables can be initialized to values ​​indicating availability, such as 0. The source thread, acting as the producer thread, fills the source descriptor table according to the number of first-level descriptors N, the number of second-level descriptors M pointed to by each first-level descriptor, and the data block size B in the current hardware parameter combination. The source thread can iteratively query the status flags of the source first-level descriptors. After finding an available source first-level descriptor, it reads the source data to be compressed or decompressed from the input data file and sequentially writes it into the source data blocks corresponding to the M source second-level descriptors pointed to by that source first-level descriptor. The address field in the source second-level descriptor can record or point to the storage address of the corresponding source data block, and the block size field can match B in the current parameter combination.

[0070] In one implementation, the source thread can iterate through the source descriptor table from 0 to N-1 according to the source first-level descriptor index i, and sequentially fill each source data block according to the source second-level descriptor index k from 0 to M-1. When all M source data blocks associated with the same source first-level descriptor have been filled, or when the filling of the committable data is completed at the end of the input data file, the source thread updates the status flag of the source first-level descriptor through an atomic write operation, switching it from an available state to an unavailable state, thereby simulating the process of the software driver submitting a descriptor task to the hardware acceleration engine. Using atomic operations can reduce state contention when the source thread and the hardware simulation thread concurrently access the same status flag, making the descriptor submission sequence closer to the actual software and hardware collaborative scenario.

[0071] In some embodiments, a source-side first-level descriptor is specifically disclosed to have a status flag "valid," which indicates whether the corresponding source-side first-level descriptor can currently be filled by a source thread. In this embodiment, the first value can be 0, indicating that the descriptor is available; the second value can be 1, indicating that the descriptor is unavailable. It is understood that in other implementations, the first and second values ​​can also be other distinct status values, as long as they can respectively represent the available and unavailable states.

[0072] At the start of the simulation, the storage unit can initialize the status flag bits of each source-side first-level descriptor in the source-side descriptor table to the first value, so that the source-side descriptor table is in an initial state that can be filled.

[0073] When writing data from the input data file into the source descriptor table, the source thread iterates through the source primary descriptors in a loop. The index i of the source primary descriptor can vary from 0 to N-1. When the source thread finds that src_primary_desc[i].valid (the status flag of the i-th source primary descriptor) equals the first value, it indicates that the descriptor slot corresponding to that source primary descriptor has not yet been occupied by the hardware simulation thread. The source thread can then read source data from the input data file and sequentially fill the read data into the source data blocks corresponding to each source secondary descriptor pointed to by that source primary descriptor.

[0074] Specifically, for the selected source-side first-level descriptor, the source-side thread can fill it in order from 0 to M-1 according to the source-side second-level descriptor index k. Each source-side second-level descriptor can contain an address field addr and a data block size field B. The address field addr is used to point to the corresponding source-side data block, and the data block size field B is used to limit the amount of data that can be filled in the source-side data block. The source-side thread determines the source-side data block to be written according to src_secondary_desc[k].addr (the data block pointed to by the kth source-side second-level descriptor), and writes the data from the input data file into the source-side data block according to B in the current hardware parameter combination. If the remaining data in the input data file is less than the size of a complete data block, the corresponding source-side data block can be filled according to the remaining data, and the effective data length of the data block is recorded in the descriptor information so that the subsequent hardware simulation thread can perform compression or decompression simulation according to the effective data length.

[0075] After all the source data blocks pointed to by the M source-side secondary descriptors associated with a source-side primary descriptor have been filled, the source-side thread updates the status flag of the source-side primary descriptor from the first value to the second value through an atomic write operation. For example, the source-side thread can set src_primary_desc[i].valid to 1 after looping k to M-1 and all corresponding source data blocks have been filled. This update action indicates that the source-side primary descriptor and its associated data block have formed a task unit that can be read and processed by the hardware simulation thread, and also indicates that the source-side primary descriptor is temporarily no longer available for repeated filling by the source-side thread.

[0076] The querying and updating of the aforementioned status flags can be completed atomically. When querying the status flags, the source thread can use methods such as polling, blocking wait, or event notification to find the source-level descriptor with the status flag set to the first value. When updating the status flags, atomic writes are used to prevent the source thread and the hardware simulation thread from accessing the same status flag simultaneously, which could lead to inconsistencies in status. Therefore, the source thread only writes data when the source-level descriptor is available, and only submits the source-level descriptor after all associated source data blocks have been filled. This allows the writing process from the input data file to the source descriptor table to simulate the timing of software-driven task submission at the descriptor granularity.

[0077] In this way, the status flag of the source-side first-level descriptor cycles between a first value and a second value, allowing the source-side descriptor table to be used cyclically. When the hardware simulation thread subsequently reads a source-side first-level descriptor with the status flag at the second value and completes the descriptor acquisition, it can restore the status flag to the first value, thus enabling the source-side thread to continue filling the descriptor slot with new input data. This cyclical mechanism establishes a data submission relationship between the source-side thread, the hardware simulation thread, and the storage unit that corresponds to the real software driver, descriptor table, and hardware acceleration engine, thereby improving the simulation accuracy of source-side descriptor occupancy, release, and task submission timing.

[0078] In another embodiment, it is disclosed that after the hardware simulation thread finds the submitted source first-level descriptor in the source descriptor table, it can read source data according to the source second-level descriptor and source data block pointed to by the source first-level descriptor, and simulate the hardware acceleration engine to perform data compression or decompression processing.

[0079] Specifically, the hardware simulation thread iteratively queries the source-level descriptors in the source-level descriptor table. For example, the source-level descriptor index i cycles between 0 and N-1, and the hardware simulation thread reads src_primary_desc[i].valid sequentially or according to a preset polling strategy. When the value of src_primary_desc[i].valid is found to be 1, it indicates that the M source-level descriptors pointed to by this source-level descriptor have been filled with source-level data blocks, and the hardware simulation thread can assume that the hardware acceleration engine has detected a task to be processed. At this time, the hardware simulation thread does not immediately release the source-level descriptor synchronously, but instead creates a delay function and passes the processed source-level descriptor index i to the delay function.

[0080] The delay function can be implemented using an asynchronous timer callback. After the delay function is created, the hardware simulation thread continues to execute the subsequent computational delay simulation process without waiting for the delay function to complete. The delay function is triggered after a first delay duration T_delay and updates src_primary_desc[i].valid from 1 to 0 through an atomic write operation. The first duration T_delay is used to simulate the transmission delay introduced by the hardware acceleration engine in obtaining the source descriptor, performing bus read / write, or status write-back. It can be determined based on the transmission delay characteristics of the data bus. For example, in one configuration, T_delay can be set to 160ns to simulate the bus delay associated with a single descriptor read / write; in other configurations, T_delay can also be adjusted based on the target bus width, bus frequency, access arbitration delay, or system simulation calibration results.

[0081] After creating the delay function, the hardware simulation thread enters a sleep state to simulate the processing time of the compression or decompression computing core. The sleep duration is a second duration, T_compute. The second duration T_compute can be configured by the test control layer based on the data block size B corresponding to the current hardware parameter combination and the preset data compression ratio, or it can be calculated by the simulation core layer based on B and the data compression ratio. Generally, the larger B is, the larger the amount of data processed in a single operation, and T_compute increases accordingly. Different compression ratios affect the amount of data or computational load of the simulated target data, thus affecting T_compute. Therefore, T_compute reflects the processing latency of the compression or decompression computing core under the current hardware parameter combination.

[0082] While the hardware simulation thread is in a sleep state, the delay function can be triggered independently to release the corresponding source-side primary descriptor, restoring src_primary_desc[i].valid to 0. The source-side thread can then find the source-side primary descriptor is available again in subsequent polls and fill the source-side data block pointed to by its corresponding source-side secondary descriptor with new input data. Through this processing method, the descriptor release process and the computation delay simulation process overlap in time, simulating the pipeline behavior of the hardware acceleration engine, which, after acquiring a descriptor, simultaneously performs compression or decompression computations and releases the descriptor for the software to continue submitting tasks.

[0083] When the hardware simulation thread exits from sleep mode, it can confirm that the data compression or decompression processing corresponding to the current source-side first-level descriptor has been completed and generate simulated destination data. Simulated destination data may include the processed data content, data length, destination write address information, or result data information for subsequent writing to the destination descriptor table. In decompression scenarios, the amount of simulated destination data can be determined based on the input data volume and a preset compression ratio; in compression scenarios, the amount of simulated destination data can also be determined based on the input data volume and compression ratio. This simulated destination data can then be filled into the destination descriptor table for the destination thread to write to the output data file.

[0084] This implementation, by simultaneously setting an asynchronous delay function and calculating the sleep duration after querying the source-side first-level descriptor with the status flag bit set to the second value, prevents the source-side descriptor release timing from being simplified to a serial relationship with the hardware computation timing. Thus, under different combinations of parameters—the number of first-level descriptors N, the number of second-level descriptors M, and the data block size B—the simulated processing time can more closely approximate the actual overlap between descriptor acquisition, bus access, resource release, and computation processing in the hardware acceleration engine, thereby improving the accuracy of parameter performance evaluation.

[0085] In some embodiments, after completing the compression or decompression simulation of the source data, the hardware simulation thread writes the generated simulated destination data into the destination descriptor table in the circular buffer layer. The destination descriptor table may include multiple first-level destination descriptors, each pointing to M second-level destination descriptors, and each second-level destination descriptor further pointing to a destination data block. The number of first-level destination descriptors is N, the number of second-level destination descriptors pointed to by each first-level destination descriptor is M, and the size of the destination data block is B, the size of the data block in the current hardware parameter combination.

[0086] Specifically, after exiting the sleep state used to simulate computational latency, the hardware simulation thread confirms that the compression or decompression processing corresponding to the current source data has been completed and obtains the simulated destination data. Subsequently, the hardware simulation thread loops through the destination descriptor table, querying destination-level descriptors with a status flag of the first value. In one implementation, the status flag can be a valid field, with a first value of 0 indicating that the destination-level descriptor is currently available and not yet occupied by the hardware simulation thread; and a second value of 1 indicating that the destination-level descriptor is currently unavailable and the associated destination data is awaiting reclamation by the destination thread. The first and second values ​​can also use other binary status representations, as long as they can distinguish between the available and unavailable states of the descriptor.

[0087] When the hardware simulation thread finds a primary destination descriptor with its status flag set to the first value, it uses that primary destination descriptor as the current destination descriptor slot. For example, the current primary destination descriptor can be dst_primary_desc[j], where j cycles from 0 to N-1. The address field in this primary destination descriptor points to a set of secondary destination descriptors, which can be represented as dst_secondary_desc[l], where l ranges from 0 to M-1. The address field addr of each secondary destination descriptor points to a destination data block, and the hardware simulation thread writes the simulated destination data into the corresponding destination data block according to the order of the secondary destination descriptors.

[0088] During the writing process, the hardware simulation thread can divide the simulated target data into blocks based on the current B, so that each segment of simulated target data corresponds to a target data block pointed to by a target-side secondary descriptor. For compression processing, the size of the simulated target data can be derived from the source data size based on the preset compression ratio; for decompression processing, the size of the simulated target data can be derived based on the decompression ratio or the data characteristics set in the test case. Therefore, what is written to the target-side descriptor table is not just an abstract completion marker, but target data information that matches B, M, and the data compression ratio in the current parameter combination, so that the target-side buffer occupancy can participate in the formation of simulation time.

[0089] In some embodiments, the hardware simulation thread sequentially fills the target data blocks pointed to by dst_secondary_desc[0].addr to dst_secondary_desc[M-1].addr with simulated target data. Once all target data blocks pointed to by the M target secondary descriptors corresponding to the target primary descriptor have been filled, the hardware simulation thread updates the status flag of the target primary descriptor from a first value to a second value through an atomic write operation. For example, setting dst_primary_desc[j].valid from 0 to 1 indicates that the target primary descriptor has been written with valid target data, and the target thread can read the target primary descriptor and write its associated target data to the output data file.

[0090] If the hardware simulation thread does not find a first-level destination descriptor with its status flag set to the first value in the destination descriptor table, it can continue polling the destination descriptor table until the destination thread releases at least one first-level destination descriptor. In this way, the availability status of the destination descriptor table can exert a counter-pressure constraint on the hardware simulation thread, ensuring that the simulation process reflects not only the computation time for compression or decompression but also the potential waiting time when destination buffer resources are insufficient.

[0091] Updates to the status flags of the destination-level descriptor can be performed atomically to avoid inconsistencies when the hardware simulation thread and the destination thread concurrently access the same destination-level descriptor. For example, the hardware simulation thread writes destination data only after confirming that the destination-level descriptor is available, and sets it to an unavailable state only after all corresponding destination data blocks have been filled; the destination thread, on the other hand, reads data only after detecting that the destination-level descriptor is unavailable, and restores it to an available state only after the associated data has been written. Thus, the destination descriptor table can be reused cyclically during the simulation.

[0092] Through the above implementation, after completing the compression or decompression simulation, the hardware simulation thread does not directly write the processing result to the output data file. Instead, it first writes the corresponding destination data block according to the available state of the destination descriptor table, and then changes the state of the destination first-level descriptor after filling. This can more accurately reproduce the process by which the hardware acceleration engine occupies destination descriptor resources, writes back the destination data, and waits for the software to reclaim the results after processing, thus incorporating the occupation, release, and cyclic reuse of destination descriptors into the simulation timing. This process, combined with source descriptor reading, asynchronous release, and computational delay simulation, can improve the ability of parameter combination simulation time to represent real hardware behavior.

[0093] In other embodiments, writing destination data to an output data file based on a destination descriptor table is disclosed, specifically including: The destination thread cyclically scans the destination-level descriptors in the destination descriptor table. For example, the index j of a destination-level descriptor can increment from 0 to N-1, and then return to 0 after reaching N-1, forming a circular buffer access method. When the destination thread finds that the status flag of a destination-level descriptor is at the second value, it indicates that the destination-level descriptor is currently not available for the hardware simulation thread to continue writing new destination data, but is in a state of waiting for result recycling. The destination thread thus determines that the data block corresponding to this destination-level descriptor is the object to be written this time.

[0094] After finding a destination-level descriptor with a status flag of the second value, the destination thread can sequentially access the destination-level descriptors it points to based on the address information recorded in that descriptor. A destination-level descriptor can include an address field `addr` and a data block size field `B`. The address field `addr` points to the corresponding data block in the destination data buffer, and the data block size field `B` indicates the data length or buffer granularity of that data block. The destination thread can increment the index `l` of the destination-level descriptors from 0 to `M-1`, read the destination data from the corresponding data block according to the address field `addr` of each destination-level descriptor, and write the read destination data to the output data file.

[0095] The output data file can be a file used to store compression or decompression results during the simulation. For compression scenarios, the output data file can be used to save the data obtained after simulation compression; for decompression scenarios, it can be used to save the data obtained after simulation decompression. Since the size of the destination data after compression or decompression may differ from the source data size, the destination thread can determine the write range based on the effective data length, data block size field B recorded in the destination's secondary descriptor, or the result data information generated during the simulation. This avoids writing out buffer content not occupied by the current processing result as valid results.

[0096] In one specific implementation, the destination thread can read data from the `dst_data_buffer` corresponding to the primary destination descriptor after discovering that `dst_primary_desc[j].valid` equals 1. This `dst_data_buffer` can consist of M data blocks pointed to by secondary destination descriptors `dst_secondary_desc[l]`, where l cycles from 0 to M-1. After the destination thread sequentially writes the valid data from the above M data blocks to the output data file, it can update `dst_primary_desc[j].valid` to 0 through an atomic write operation. Thus, the primary destination descriptor is restored from an unavailable state to an available state, and subsequent hardware simulation threads can select this primary destination descriptor again to fill new simulated destination data.

[0097] In another implementation, the destination thread can also use a batch write approach. For example, when multiple consecutive destination-level descriptors are in the second value state, the destination thread can sequentially read the data blocks corresponding to these destination-level descriptors and write them to the output data file according to the descriptor index order or the processing completion order. After writing all the data blocks corresponding to a destination-level descriptor, the status flag of that destination-level descriptor is updated to the first value. This method can reduce the overhead of frequent file write operations without changing the descriptor state transition logic.

[0098] Through the above processing, the destination thread does not simply read result data from shared memory in an unordered manner. Instead, it uses the status flag of the destination's first-level descriptor as a synchronization basis. Only after confirming that the destination's first-level descriptor is unavailable does it read the data blocks corresponding to the various destination's second-level descriptors. After all the data corresponding to the data blocks under the destination's first-level descriptor has been written to the output data file, the status flag is restored to its first value. This simulates the process of software reclaiming hardware processing results and releasing destination descriptor resources, allowing the destination descriptor table to be reused cyclically.

[0099] The aforementioned process of writing out the target data works in conjunction with the process of filling in the target data in the hardware simulation thread: the hardware simulation thread submits the result data by setting the target-side first-level descriptor to the second value, and the target-side thread releases the result buffer resources by restoring the target-side first-level descriptor to the first value. The two processes coordinate asynchronously based on status flags, enabling the simulation process to cover the path of the target data from shared memory to the output data file. Therefore, the processing time obtained for different combinations of hardware parameters—N (number of first-level descriptors), M (number of second-level descriptors), and B (data block size)—not only reflects the compression or decompression calculation process but also the impact of target-side result retrieval and descriptor reuse on end-to-end performance.

[0100] In some embodiments, based on the time taken to simulate the data processing for each set of hardware parameter combinations, the hardware parameter combination that makes the data compression or decompression processing most efficient is determined. After the simulation unit completes the end-to-end data processing simulation of multiple sets of hardware parameter combinations, the control unit can perform a hierarchical analysis of the processing time of each set of hardware parameter combinations to determine the hardware design parameters used for data compression or decompression processing.

[0101] Each hardware parameter combination can be denoted as P_r = (N_r, M_r, B_r), where N_r represents the number of first-level descriptors, M_r represents the number of second-level descriptors pointed to by each first-level descriptor, B_r represents the size of the data block pointed to by the second-level descriptor, and r is the sequence number of the hardware parameter combination. Referring to the description in the above embodiment, the simulation unit runs a source thread, a hardware simulation thread, and a destination thread for each P_r combination to simulate the data processing process for each P_r combination and returns the total processing time T_total(r) corresponding to that set of parameters to the control unit.

[0102] When selecting parameters, the control unit can first determine the number M of target secondary descriptors. Specifically, the control unit can classify multiple sets of simulation results according to the number M of secondary descriptors. For example, simulation results with M of 1, 2, 4, and 8 can be formed into corresponding data sets, and the processing time of each data set can be compared under the same or similar hardware resource constraints. The hardware resource constraints may include fixing the total capacity C_total of the descriptor-related buffers, for example, satisfying C_total=N×M×B, so that different parameter combinations can be compared under similar hardware cost conditions, thereby reducing the impact of simply increasing buffer resources on processing time.

[0103] When determining the number M of secondary descriptor targets, the control unit can not only compare the shortest processing time corresponding to different values ​​of M, but also compare the relationship between the decrease in processing time as M increases and the increase in hardware scheduling complexity. For example, based on the time taken to simulate the data processing process for each combination of hardware parameters, the number M of secondary descriptor targets that maximizes the cost-effectiveness of data compression or decompression can be determined.

[0104] The aforementioned cost-effectiveness refers to the ratio between the increase in processing performance and the increase in hardware scheduling complexity when the number of secondary descriptors increases.

[0105] For example, when both the source and destination descriptor tables employ a multi-level descriptor structure, as M increases from 1 to 2, each first-level descriptor can associate more data blocks pointed to by second-level descriptors. This increases the data flow that the hardware simulation thread can process after a single descriptor fetch, and T_total typically decreases. However, when M continues to increase to 4 or 8, the deepening of the second-level links increases the complexity of descriptor resolution and scheduling, potentially reducing the rate of decrease in processing time, or even causing a rebound under partial load. Therefore, the control unit can determine the target number of second-level descriptors M as a value with lower processing time and higher unit complexity benefit, for example, setting M to 1 or 2.

[0106] After determining M, the control unit can further determine the number of primary descriptor targets N and the data block size B that maximize the efficiency of data compression or decompression based on the number of secondary descriptor targets M and the time taken to simulate the data processing for each combination of hardware parameters.

[0107] Specifically, the control unit can select candidate combinations where M_r = M from multiple sets of hardware parameter combinations, or compare T_total(r) corresponding to different N_r and B_r among candidate combinations where M_r is close to M and meets preset error conditions. In this process, N_r is used to characterize the depth of the first-level descriptor ring structure, and B_r is used to characterize the granularity of the data block pointed to by each second-level descriptor. The two are mutually constrained when C_total is fixed. Increasing N_r can usually provide more reusable first-level descriptor slots so that the input / output latency between the source thread and the hardware simulation thread can be better hidden, while increasing B_r can usually reduce the descriptor switching frequency in large-block sequential access scenarios.

[0108] For example, with C_total fixed at 8MB and M already determined, the control unit can compare candidate combinations such as (N=16, B=512KB) and (N=8, B=1024KB). The former combination, due to the larger number of primary descriptors, can provide deeper buffering and more stable pipeline connections when there are fluctuations in input file reading, hardware processing, and output file writing; the latter combination, due to the larger data blocks, may reduce descriptor management overhead and achieve shorter processing times in large-block sequential access scenarios. The control unit can determine the target number N of primary descriptors and the data block size B that maximizes compression or decompression efficiency based on T_total, throughput, and processing stability under typical workloads. For example, N can be set between 8 and 16, and B between 512KB and 1024KB, and the appropriate pairing can be selected according to the specific load.

[0109] In one implementation, the control unit can select the combination according to the following rules: if the total T_total of a candidate combination is the shortest, then N_r and B_r in that candidate combination are determined as N and B; if the difference in total T_total among multiple candidate combinations is less than a preset threshold, then the combination with lower descriptor control logic complexity, higher resource utilization, or more stable processing time under fluctuating loads is preferentially selected. The preset threshold can be set according to test accuracy, target throughput, or engineering tolerance, for example, it can be determined based on the time fluctuation range of multiple repeated simulations.

[0110] In another implementation, the control unit can also combine throughput metrics for judgment. If the amount of data in the input data file is D, and the total processing time for a certain combination of parameters is T_total(r), then the throughput corresponding to that combination of parameters can be characterized by the ratio of D to T_total(r). The control unit can first determine M based on T_total(r) or throughput, and then select N and B with higher throughput from the candidate combinations corresponding to M. When the simulation system also collects auxiliary data such as CPU utilization, source thread active time, hardware simulation thread active time, and destination thread active time, the control unit can also use this auxiliary data to determine the source of processing bottlenecks, thereby avoiding misjudging the quality of parameters based solely on a single processing time.

[0111] By first determining the target number M of secondary descriptors, and then the target number N of primary descriptors and the data block size B, the control unit can analyze the performance impact of secondary descriptor depth separately from the performance impact of primary descriptor ring depth and data block granularity. This reduces the mutual masking caused by simultaneous changes in multiple parameters, making it easier to pinpoint the source of performance improvement during parameter selection. For example, when M continues to increase but T_total shows limited improvement, it can be determined that the performance bottleneck is no longer primarily due to the number of secondary descriptors; subsequently, by adjusting N and B while keeping M* fixed, the trade-off between descriptor depth and data block size can be observed more directly.

[0112] The M, N, and B obtained in the above embodiments can serve as design inputs for compression or decompression hardware acceleration engines. For example, the descriptor acquisition and parsing unit can configure the first-level descriptor ring control depth according to N, and configure the number of second-level descriptor items associated with each first-level descriptor according to M; the data transfer channel can configure the single data block transmission granularity according to B; the compression or decompression calculation core can estimate the processing latency based on B and a preset compression ratio. Thus, a correspondence is formed between the simulation time consumption data and the hardware microarchitecture parameters, enabling the hardware design to obtain a parameter combination that has been systematically verified through simulation before physical implementation.

[0113] Corresponding to the above method embodiments, this application also provides a parameter performance simulation system, see [link to relevant documentation]. Figure 3As shown, the system includes: Storage unit 100 is used to simulate and maintain a descriptor table, the descriptor table including a first-level descriptor, a second-level descriptor pointed to by the first-level descriptor, and a data block pointed to by the second-level descriptor; the descriptor table is applied to the hardware acceleration engine to store data information, and the hardware acceleration engine is used to perform data compression and / or decompression processing; The control unit 110 is used to generate multiple different combinations of hardware parameters, the hardware parameter combinations including the number of first-level descriptors in the descriptor table, the number of second-level descriptors pointed to by the first-level descriptors, and the size of the data block pointed to by the second-level descriptors; The simulation unit 120 is used to simulate a data processing process for each set of hardware parameter combinations generated by the control unit 110. The data processing process includes reading source data from the descriptor table of the storage unit and performing compression or decompression processing, and writing the processed destination data into the descriptor table of the storage unit 100. When the simulation unit 120 simulates the data processing process for any hardware parameter combination, the structure of the descriptor table in the storage unit 100 matches the hardware parameter combination. The control unit 110 is also used to determine the hardware parameter combination that maximizes the efficiency of data compression or decompression based on the time consumed by the simulation unit 120 in simulating the data processing process for each set of hardware parameter combinations.

[0114] In some embodiments, the descriptor table includes a source descriptor table for storing source data information and a destination descriptor table for storing destination data information. The simulation unit 120 reads source data based on the descriptor table and performs compression or decompression processing, and writes the processed destination data to the target address, including: The source data is read from the source descriptor table and compressed or decompressed, and the processed destination data information is written into the destination descriptor table.

[0115] In some embodiments, the simulation unit 120 is further configured to: Write the data information from the input data file into the source descriptor table; as well as, Based on the destination descriptor table, the destination data is written to the output data file.

[0116] In some embodiments, the simulation unit 120 writes data information from the input data file into the source descriptor table, including: The query status flag value is the first value for the source-level descriptor, where the first value indicates that the descriptor is available; If a source-end level-one descriptor with a status flag value of the first value is found, the data from the input data file is filled into the data block pointed to by the level-two descriptor pointed to by that source-end level-one descriptor; When all data blocks pointed to by the secondary descriptor are filled, the value of the status flag bit of the source primary descriptor is updated to a second value, which indicates that the descriptor is unavailable.

[0117] In some embodiments, the simulation unit 120 reads source data based on the source descriptor table and performs compression or decompression processing, including: Retrieve from the source descriptor table the source-level descriptor whose status flag value is the second value; If a source-side primary descriptor with a status flag value of the second value is found, a delay function is created and the system enters a sleep state. The delay function is used to update the status flag value of the source-side primary descriptor to the first value after a first delay. The sleep duration of the sleep state is the second duration. The first duration is determined based on the transmission delay characteristics of the data bus, and the second duration is determined based on the data block size and data compression ratio corresponding to the current hardware parameter combination. Upon exiting the sleep state, confirm the completion of data compression or decompression and generate the simulated target data.

[0118] In some embodiments, the simulation unit 120 writes the processed destination data information into the destination descriptor table, including: The destination first-level descriptor with the first value as the status flag bit is retrieved from the destination descriptor table; If a destination first-level descriptor with a status flag value of the first value is found, the simulated destination data is filled into the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor; If all data blocks pointed to by the secondary descriptors of the destination primary descriptor are filled, the value of the status flag bit of the destination primary descriptor is updated to the second value.

[0119] In some embodiments, the simulation unit 120 writes the destination data into the output data file based on the destination descriptor table, including: The destination level descriptor is retrieved from the destination descriptor table with the second value for the status flag bit. The second value indicates that the descriptor is unavailable. If a destination first-level descriptor with a status flag value of the second value is found, data is read from the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor and written to the output data file. When all the data corresponding to the data blocks pointed to by the secondary descriptors of the destination first-level descriptor have been written to the output data file, the value of the status flag bit of the destination first-level descriptor is updated to a first value, which indicates that the descriptor is available.

[0120] In some embodiments, the control unit 110 determines the hardware parameter combination that maximizes the efficiency of data compression or decompression based on the time consumed by simulating the data processing for each set of said hardware parameter combinations, including: Based on the time consumed by simulating the data processing process for each set of hardware parameter combinations, determine the number of secondary descriptor targets that maximize the cost-effectiveness of data compression or decompression processing; Based on the number of secondary descriptor targets and the time consumed in simulating the data processing for each set of hardware parameter combinations, determine the number of primary descriptor targets and the data block size that maximizes the efficiency of data compression or decompression.

[0121] The parameter performance simulation system provided in this embodiment belongs to the same application concept as the method for determining hardware design parameters provided in the above embodiments of this application. It can execute the method for determining hardware design parameters provided in any of the above embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the above-described method for determining hardware design parameters. Technical details not described in detail in this embodiment, as well as the specific functions and working processes of each unit, can be found in the specific processing content of the method for determining hardware design parameters provided in the above embodiments of this application, and will not be repeated here.

[0122] The functions implemented by each of the above units can be implemented by the same or different processors, and this application embodiment does not limit this.

[0123] It should be understood that the units in the above system can be implemented by a processor calling software. For example, the system includes a processor connected to memory, which stores instructions. The processor calls the instructions stored in memory to implement any of the above methods or to implement the functions of each unit in the system. The processor can be a general-purpose processor, such as a CPU or microprocessor, and the memory can be internal or external to the system. Alternatively, the units in the system can be implemented as hardware circuits. By designing the hardware circuits, some or all of the unit functions can be implemented. The hardware circuit can be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, which implements some or all of the unit functions by designing the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a PLD, such as an FPGA, which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files to implement some or all of the unit functions. All units in the above system can be implemented entirely by a processor calling software, entirely by hardware circuits, or partially by a processor calling software with the remaining parts implemented by hardware circuits.

[0124] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0125] As can be seen, each unit in the above system can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor types.

[0126] Furthermore, the units in the above systems can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together and implemented in the form of a System-on-Chip (SoC). This SoC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the system. The at least one processor can be of different types, such as CPU and FPGA, CPU and AI processor, CPU and GPU, etc.

[0127] Another embodiment of this application also provides an electronic device, see [link to relevant documentation] Figure 4 As shown, the device includes: Memory 200 and processor 210; The memory 200 is connected to the processor 210 and is used to store programs; The processor 210 is configured to implement the method for determining hardware design parameters disclosed in any of the above embodiments by running a program stored in the memory 200.

[0128] Specifically, the aforementioned electronic device may also include: a bus, a communication interface 220, an input device 230, and an output device 240.

[0129] The processor 210, memory 200, communication interface 220, input device 230, and output device 240 are interconnected via a bus. Among them: A bus can include a pathway for transmitting information between various components of a computer system.

[0130] Processor 210 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0131] Processor 210 may include a main processor, as well as a baseband chip, modem, etc.

[0132] The memory 200 stores a program that executes the technical solution of this invention, and may also store an operating system and other key business functions. Specifically, the program may include program code, which includes computer operation instructions. More specifically, the memory 200 may include read-only memory (ROM), other types of static storage devices capable of storing static information and instructions, random access memory (RAM), other types of dynamic storage devices capable of storing information and instructions, disk storage, flash memory, etc.

[0133] Input device 230 may include a device for receiving user input data and information, such as a keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer, or gravity sensor.

[0134] Output device 240 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0135] The communication interface 220 may include a device that uses any transceiver to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0136] The processor 210 executes the program stored in the memory 200 and calls other devices, which can be used to implement the various steps of any of the methods for determining hardware design parameters provided in the above embodiments of this application.

[0137] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the method for determining hardware design parameters described in any of the above embodiments of this specification.

[0138] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0139] Furthermore, embodiments of this application may also be storage media storing a computer program, which is executed by a processor through steps in the method for determining hardware design parameters described in any of the above embodiments of this specification.

[0140] For the foregoing method embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0141] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For apparatus embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0142] The steps in the methods of the various embodiments of this application can be adjusted, merged, or deleted in order according to actual needs, and the technical features described in each embodiment can be replaced or combined.

[0143] The modules and sub-modules in the apparatus and terminal in the various embodiments of this application can be merged, divided, and deleted according to actual needs.

[0144] It should be understood that the disclosed terminals, devices, and methods can be implemented in other ways, given the several embodiments provided in this application. For example, the terminal embodiments described above are merely illustrative. For instance, the division of modules or sub-modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple sub-modules or modules may be combined or integrated into another module, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0145] The modules or submodules described as separate components may or may not be physically separate. The components that constitute a module or submodule may or may not be physical modules or submodules; that is, they may be located in one place or distributed across multiple network modules or submodules. Some or all of the modules or submodules can be selected to achieve the purpose of this embodiment's solution, depending on actual needs.

[0146] Furthermore, the functional modules or sub-modules in the various embodiments of this application can be integrated into one processing module, or each module or sub-module can exist physically separately, or two or more modules or sub-modules can be integrated into one module. The integrated modules or sub-modules described above can be implemented in hardware or in the form of software functional modules or sub-modules.

[0147] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0148] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software unit executed by a processor, or a combination of both. The software unit can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0149] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0150] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for determining hardware design parameters, characterized in that, include: Multiple different combinations of hardware parameters are generated. The hardware parameter combinations include the number of first-level descriptors in the descriptor table, the number of second-level descriptors pointed to by the first-level descriptors, and the size of the data blocks pointed to by the second-level descriptors. The descriptor table is applied to the hardware acceleration engine to store data information, and the hardware acceleration engine is used to perform data compression and / or decompression processing. For each set of hardware parameter combinations, a data processing process is simulated. The data processing process includes reading source data based on a descriptor table and performing compression or decompression, and writing the processed destination data to a target address. When simulating the data processing process for any hardware parameter combination, the structure of the descriptor table matches that hardware parameter combination. Based on the time consumed by simulating the data processing for each set of hardware parameter combinations, the hardware parameter combinations that maximize the efficiency of data compression or decompression are determined.

2. The method according to claim 1, characterized in that, The descriptor table includes a source descriptor table for storing source data information and a destination descriptor table for storing destination data information. The process of reading source data based on the descriptor table and performing compression or decompression, and writing the processed destination data to the target address, includes: The source data is read from the source descriptor table and compressed or decompressed, and the processed destination data information is written into the destination descriptor table.

3. The method according to claim 2, characterized in that, The method further includes: Write the data information from the input data file into the source descriptor table; as well as, Based on the destination descriptor table, the destination data is written to the output data file.

4. The method according to claim 3, characterized in that, The step of writing data information from the input data file into the source descriptor table includes: The query status flag value is the first value for the source-level descriptor, where the first value indicates that the descriptor is available; If a source-end level-one descriptor with a status flag value of the first value is found, the data from the input data file is filled into the data block pointed to by the level-two descriptor pointed to by that source-end level-one descriptor; When all data blocks pointed to by the secondary descriptor are filled, the value of the status flag bit of the source primary descriptor is updated to a second value, which indicates that the descriptor is unavailable.

5. The method according to claim 4, characterized in that, Reading source data based on the source descriptor table and performing compression or decompression processing includes: Retrieve from the source descriptor table the source-level descriptor whose status flag value is the second value; If a source-side primary descriptor with a status flag value of the second value is found, a delay function is created and the system enters a sleep state. The delay function is used to update the status flag value of the source-side primary descriptor to the first value after a first delay. The sleep duration of the sleep state is the second duration. The first duration is determined based on the transmission delay characteristics of the data bus, and the second duration is determined based on the data block size and data compression ratio corresponding to the current hardware parameter combination. Upon exiting the sleep state, confirm the completion of data compression or decompression and generate the simulated target data.

6. The method according to claim 5, characterized in that, The processed destination data information is written into the destination descriptor table, including: The destination first-level descriptor with the first value as the status flag bit is retrieved from the destination descriptor table; If a destination first-level descriptor with a status flag value of the first value is found, the simulated destination data is filled into the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor; If all data blocks pointed to by the secondary descriptors of the destination primary descriptor are filled, the value of the status flag bit of the destination primary descriptor is updated to the second value.

7. The method according to claim 3, characterized in that, Based on the destination descriptor table, the destination data is written to the output data file, including: The destination level descriptor is retrieved from the destination descriptor table with the second value for the status flag bit. The second value indicates that the descriptor is unavailable. If a destination first-level descriptor with a status flag value of the second value is found, data is read from the data block pointed to by the second-level descriptor pointed to by the destination first-level descriptor and written to the output data file. When all the data corresponding to the data blocks pointed to by the secondary descriptors of the destination first-level descriptor have been written to the output data file, the value of the status flag bit of the destination first-level descriptor is updated to a first value, which indicates that the descriptor is available.

8. The method according to any one of claims 1 to 7, characterized in that, Based on the time consumed in simulating the data processing for each set of hardware parameter combinations, the hardware parameter combinations that maximize the efficiency of data compression or decompression are determined, including: Based on the time consumed by simulating the data processing process for each set of hardware parameter combinations, determine the number of secondary descriptor targets that maximize the cost-effectiveness of data compression or decompression processing; Based on the number of secondary descriptor targets and the time consumed in simulating the data processing for each set of hardware parameter combinations, determine the number of primary descriptor targets and the data block size that maximizes the efficiency of data compression or decompression.

9. A parametric performance simulation system, characterized in that, include: A storage unit is used to simulate and maintain a descriptor table, the descriptor table including a first-level descriptor, a second-level descriptor pointed to by the first-level descriptor, and a data block pointed to by the second-level descriptor; The descriptor table is applied to the hardware acceleration engine to store data information, and the hardware acceleration engine is used to perform data compression and / or decompression processing. The control unit is used to generate multiple different combinations of hardware parameters, the hardware parameter combinations including the number of first-level descriptors in the descriptor table, the number of second-level descriptors pointed to by the first-level descriptors, and the size of the data blocks pointed to by the second-level descriptors; The simulation unit is used to simulate a data processing process for each set of hardware parameter combinations generated by the control unit. The data processing process includes reading source data from the descriptor table of the storage unit and performing compression or decompression processing, and writing the processed destination data into the descriptor table of the storage unit. When the simulation unit simulates the data processing process for any hardware parameter combination, the structure of the descriptor table in the storage unit matches the hardware parameter combination. The control unit is also used to determine the hardware parameter combination that maximizes the efficiency of data compression or decompression based on the time consumed by the simulation unit to simulate the data processing process for each set of hardware parameter combinations.

10. An electronic device, characterized in that, include: Memory and processor; The memory is connected to the processor and is used to store programs; The processor is configured to implement the method for determining hardware design parameters as described in any one of claims 1 to 8 by running a program in the memory.

11. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, cause the processor to perform the method for determining hardware design parameters as described in any one of claims 1 to 8.

Images