Method and system for simulating a simd-optimized dsp core

CN122470240BActive Publication Date: 2026-10-09VISION MICROSYST (SHANGHAI) CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202610953859.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2026-06-30
Publication Date
2026-10-09
Estimated Expiration
2046-06-30

AI Technical Summary

Technical Problem

该专利聚焦编译阶段指令生成,未考虑DSP仿真场景,也未针对高频瓶颈指令做定向优化,适用范围较窄,未解决指令执行耗时过高的问题

Benefits of technology

1、本发明将DSP的VLIW并行指令映射至宿主处理器硬件SIMD指令,以硬件并行运算替代原有软件串行模拟方式,减少指令执行所需时钟周期,降低仿真过程的运算耗时,提升DSP内核仿真的运行速率。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122470240B_ABST
    Figure CN122470240B_ABST
Patent Text Reader

Abstract

The application provides a method and system for optimizing a DSP core simulation based on a SIMD instruction, wherein the method comprises the following steps: firstly, obtaining a DSP simulation project file, and identifying target instructions with CPU occupation time reaching a preset threshold by combining a performance profiling tool; secondly, analyzing the semantics of the target instructions and extracting parallel operations, and matching a host processor SIMD instruction set to determine a corresponding execution function; thirdly, writing a processing function for calling the execution function; fourthly, replacing original simulation logic of the target instructions in the source code with a processing function call, and supplementing a file reference declaration; and finally, recompiling through a compiler adapted to the SIMD instruction set to generate an optimized executable file, namely a target executable file. The application can effectively improve the simulation running speed of a VLIW type DSP core, has strong optimization targeting, and guarantees accurate simulation calculation results.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of computer simulation technology, and more specifically, to a method and system for optimizing digital signal processor (DSP) kernel simulation based on Single Instruction Multiple Data Stream (SIMD) instruction set. Background Technology

[0002] Digital signal processors (DSPs) possess powerful computing capabilities and are widely used in fields such as communication, audio, and image processing. During the development and verification phases of DSP applications, engineers often deploy DSP software simulators on general-purpose computing platforms such as x86 architecture computers and servers to complete code development, debugging, and testing without physical hardware.

[0003] Current mainstream DSP emulators generally employ an instruction-by-instruction translation mechanism to convert DSP target code into executable instructions for the host processor. Some high-performance DSPs use a Very Long Instruction Word (VLIW) architecture, where a single VLIW instruction integrates multiple parallel-executable arithmetic units. When traditional instruction translation techniques process such instructions, they break down the parallel operations within the VLIW into multiple serial instructions, failing to reuse the inherent parallelism of the VLIW instructions. This increases simulation computation time and directly reduces the efficiency of DSP development and testing.

[0004] Currently, some solutions use binary translation technology to parse instruction dependencies and convert VLIW programs into a general intermediate format to generate new executable programs. However, this type of translation process is complex and difficult to implement; moreover, the general intermediate format does not take into account the hardware characteristics of modern general-purpose processors, and cannot map DSP parallel operations to the host processor's single instruction multiple data (SIMD) unit for execution, thus failing to fully utilize hardware acceleration capabilities. Neither of these existing technologies can solve the problem of the mismatch between DSP hardware and software parallelism, resulting in limited improvements in simulation performance.

[0005] A patent search revealed invention patent CN112230995A, which discloses a method, apparatus, and electronic device for generating instructions. This method is applied to a compiler connected to a DSP processing system. The method includes: upon receiving source code, determining a vectorizable loop body from the source code and vectorizing the instructions in the loop body to generate SIMD instructions; concatenating the SIMD instructions into an execution instruction set according to a very long instruction set architecture; and sending the execution instruction set to the DSP processing system so that the DSP processing system can perform test processing on the data. This patent focuses on instruction generation during the compilation stage, without considering DSP simulation scenarios or performing targeted optimizations for high-frequency bottleneck instructions. Its applicability is narrow, and it does not solve the problem of excessively long instruction execution time.

[0006] In summary, given the problems of the existing technologies, researching a method and system for optimizing DSP kernel simulation based on SIMD has become a critical task that urgently needs to be addressed. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the purpose of this invention is to provide a method and system for optimizing DSP kernel simulation based on SIMD.

[0008] A method for optimizing DSP kernel emulation based on SIMD instructions according to the present invention includes the following steps: Step S1: Obtain the executable file and source code of the DSP simulation project to be optimized. Use a performance profiling tool to collect the CPU time of each DSP instruction in the executable file and identify the DSP instructions whose CPU time meets the preset threshold as the target instructions to be optimized. Step S2: parse the instruction semantics of the target instruction, identify parallel operations from the instruction semantics, select one or more SIMD instructions that can implement parallel operations from the host processor's SIMD instruction set according to the data type and data width of the parallel operations, and determine the intrinsic function corresponding to one or more SIMD instructions as the execution function. Step S3: Write a processing function, which calls the execution function to complete the parallel operations in the target instruction; Step S4: In the source code, replace the original simulation logic corresponding to the target instruction with a call to the processing function, and add an include declaration for the file containing the processing function to obtain the modified source code; Step S5: Recompile the modified source code using a compiler that supports the SIMD instruction set to generate the target executable file.

[0009] Preferably, in step S1, the target instruction is a Very Long Instruction Word (VLIW) instruction.

[0010] Preferably, step S1 further includes: Step S1.1: On a computer equipped with an x86 architecture processor, deploy a DSP simulation project. The DSP simulation project includes source code, compilation scripts, executable files, one or more DSP target applications, performance profiling tools, and a register file for simulating DSP register states. The register file is used to store source operands and calculation results. Step S1.2: Start the executable file to load the DSP target application, and at the same time start the performance profiling tool to collect the number of instructions executed and the CPU time occupied during the execution of the executable file, and obtain a performance report; Step S1.3: Extract the instruction list sorted by CPU time usage from the performance report, and identify the top N DSP instructions with a cumulative CPU time usage exceeding 80% as the target instructions to be optimized, where N is a positive integer greater than or equal to 1.

[0011] Preferably, step S2 further includes: Step S2.1: Parse the instruction semantics of the target instruction to identify the parallel operations contained in the instruction semantics. The parallel operations include a first computational stream and a second computational stream. The first computational stream is R1=R1+(S1×S2), and the second computational stream is R3=R3+(S3×S4). R1 ​​and R3 are both accumulator registers, and S1, S2, S3, and S4 are all source operands. Step S2.2: Based on the data type and data width of the parallel operation, select one or more SIMD instructions that can implement the parallel operation from the host processor's SIMD instruction set, and determine the intrinsic function corresponding to one or more SIMD instructions as the execution function.

[0012] Preferably, in step S2, the SIMD instruction set includes at least one of the AVX, AVX2, or SSE instruction sets.

[0013] Preferably, step S3 further includes: Step S3.1: Create a source file corresponding to the target instruction. The source file name includes the mnemonic of the target instruction and the SIMD instruction set name. Step S3.2: Define a processing function in the source file. The input parameter of the processing function is a pointer to the DSP register file. Step S3.3: Inside the processing function, the source operands and accumulator register of the target instruction are obtained from the DSP register file and loaded into the SIMD register; Step S3.4: Call the execution function to perform parallel operations and obtain the computation result vector; Step S3.5: Extract the calculation result vector from the SIMD register and write it back to the accumulator register in the DSP register file.

[0014] Preferably, step S4 further includes: Step S4.1: In the source code, locate the instruction decoding and execution module used for instruction decoding and execution; Step S4.2: In the instruction decoding and execution module, locate the original simulation logic code block corresponding to the target instruction and delete the original simulation logic code block from the source code; Step S4.3: Write a call statement for the processing function in the location left after the original simulation logic code block is deleted; the call statement takes the DSP register file pointer as the actual parameter to obtain the source code after the call statement is written. Step S4.4: Add the include declaration of the source file to the source code after writing the call statement to obtain the modified source code.

[0015] Preferably, step S5 further includes: Step S5.1: Configure the compiler's compilation options and enable the compilation switch corresponding to the SIMD instruction set; Step S5.2: Use the configured compiler to compile and link the modified source code to generate the target executable file.

[0016] Preferably, the method further includes a runtime processor characteristic detection step before performing step S4: Step A: Detect the SIMD instruction set supported by the host processor; Step B: Based on the detection results, select the processing function corresponding to the highest level of SIMD instruction set supported by the host processor; the processing function includes: The first processing function is used by the host processor that supports the AVX2 instruction set; The second processing function is used for host processors that support the SSE4.1 instruction set; The third processing function is used by the host processor to support the baseline instruction set.

[0017] This invention also provides a system for optimizing DSP kernel simulation based on SIMD instructions, employing the aforementioned method for optimizing DSP kernel simulation based on SIMD instructions, comprising: Module M1 acquires the executable file and source code of the DSP simulation project to be optimized, collects the CPU time of each DSP instruction in the executable file through the performance profiling tool, and identifies the DSP instructions whose CPU time meets the preset threshold conditions as the target instructions to be optimized. Module M2 parses the instruction semantics of the target instruction, identifies parallel operations from the instruction semantics, selects one or more SIMD instructions that can implement parallel operations from the host processor's SIMD instruction set based on the data type and data width of the parallel operations, and determines the intrinsic function corresponding to one or more SIMD instructions as the execution function. Module M3 contains a processing function that calls the execution function to complete the parallel operations in the target instruction. In module M4, the original simulation logic corresponding to the target instruction is replaced with a call to the processing function in the source code, and the include declaration of the file where the processing function is located is added to obtain the modified source code; Module M5 uses a compiler that supports the SIMD instruction set to recompile the modified source code and generate the target executable file.

[0018] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention maps the VLIW parallel instructions of the DSP to the host processor hardware SIMD instructions, replacing the original software serial simulation method with hardware parallel computing, reducing the clock cycles required for instruction execution, reducing the computation time of the simulation process, and improving the running speed of DSP kernel simulation.

[0019] 2. This invention uses performance profiling to select high-frequency instructions with high CPU usage as optimization targets. It only optimizes the logic of performance bottleneck instructions, without having to reconstruct the entire simulator architecture, thus reducing code changes and development workload and improving the efficiency of optimization.

[0020] 3. This invention only replaces the logic at the function level within the existing simulator, while keeping the overall simulator architecture and external calling interfaces unchanged; at the same time, the newly written processing functions are completely equivalent to the original simulation logic, and the calculation results of the optimized simulation program are consistent with those before optimization, ensuring the simulator's compatibility and calculation accuracy. Attached Figure Description

[0021] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is the SIMD instruction processing flow in the embodiments of the present invention; Figure 2 This is the DSP6713 very long instruction word processing flow in an embodiment of the present invention. Detailed Implementation

[0022] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the scope of protection of the present invention.

[0023] To address the technical problem of low simulation efficiency caused by the inability of traditional instruction translation methods to utilize the host processor's hardware parallelism when simulating DSP cores with Very Long Instruction Word (VLIW) architectures, this invention discloses a method and system for optimizing DSP core simulation based on SIMD instructions. The method includes: first, acquiring the DSP simulation project file and identifying target instructions whose CPU usage time reaches a preset threshold using performance profiling tools; second, parsing the semantics of the target instructions and extracting parallel operations, matching them with the host processor's SIMD instruction set to determine the corresponding execution function; third, writing a processing function to call the execution function; fourth, replacing the original simulation logic of the target instructions in the source code with the processing function call and supplementing file reference declarations; and finally, recompiling using a compiler adapted to the SIMD instruction set to generate the optimized executable file, i.e., the target executable file. This invention can effectively improve the simulation speed of VLIW DSP cores, with strong optimization targeting, while ensuring the accuracy of simulation results.

[0024] Example 1: This embodiment provides a method for optimizing DSP kernel emulation based on SIMD instructions. The method is executed on a host processor equipped with a SIMD instruction set and includes the following steps: Step S1: Obtain the executable file and source code of the DSP simulation project to be optimized. Use a performance profiling tool to collect the CPU time of each DSP instruction in the executable file, and identify the DSP instructions whose CPU time meets the preset threshold as the target instructions to be optimized.

[0025] The target instruction is the Very Long Instruction Word (VLIW) instruction.

[0026] Specifically, step S1 further includes: Step S1.1: On a computer or server equipped with an x86 architecture processor (e.g., an Intel Core i7 series processor supporting Advanced Vector Extensions instruction set), deploy a DSP simulation project. The DSP simulation project includes complete source code, compilation scripts, an executable file (an unoptimized, executable version of the DSP emulator), one or more DSP target applications, performance profiling tools, and a register file for simulating DSP register states, storing source operands and computation results. The DSP simulation project is used to simulate the Texas Instruments TMS320C6713 series DSP, which has a typical Very Long Instruction Word (VLIW) architecture. The DSP target applications serve as test cases, compiled into executable binaries for the simulated DSP (i.e., the TMS320C6713).

[0027] To comprehensively evaluate performance bottlenecks, test cases should cover different application scenarios, such as an audio processing program that implements a finite impulse response filter, a radar signal processing program that performs a fast Fourier transform, and a basic mathematical library that performs matrix multiplication.

[0028] Step S1.2: Start the executable file to load the DSP target application, and at the same time start the performance profiling tool to collect the number of instructions executed and the CPU time occupied during the execution of the executable file, and generate a performance report.

[0029] Specifically, in a Linux environment, the perf performance profiling tool can be used, while in a Windows environment, professional tools such as Visual Studio Profiler or Intel VTune Profiler can be used. Performance profiling tools record key performance indicators such as the number of times each function and instruction is executed and the CPU time consumed during emulator execution.

[0030] Step S1.3: Extract the instruction list sorted by CPU time usage from the performance report, and identify the top N DSP instructions with a cumulative CPU time usage exceeding 80% as the target instructions to be optimized, where N is a positive integer greater than or equal to 1.

[0031] In a DSP simulator, there exists an instruction dispatch function (such as `execute_instruction`). Internally, this function uses a switch-case structure or a function pointer table to call the specific processing logic for different DSP instructions. Performance reports show which branches (i.e., the processing logic for which DSP instructions) are executed most frequently and consume the most CPU time within this instruction dispatch function.

[0032] In this embodiment, by analyzing a test case of an audio codec algorithm, it was found that a specific VLIW instruction (denoted as DADDMPY) had the highest execution frequency and longest execution time. This DADDMPY instruction bundles two parallel multiplication operations and two parallel addition operations within one instruction cycle. Its instruction semantics are: simultaneously execute R1 = R1 + (S1 × S2) and R3 = R3 + (S3 × S4), where R1 and R3 are both 32-bit accumulator registers, and S1, S2, S3, and S4 are all 32-bit source operands. Because this instruction was inefficient in the original serial simulation implementation, it was identified as the target instruction for optimization.

[0033] Step S2: Parse the instruction semantics of the target instruction, identify parallel operations from the instruction semantics, select one or more SIMD instructions that can implement parallel operations from the host processor's SIMD instruction set according to the data type and data width of the parallel operations, and determine the intrinsic function corresponding to one or more SIMD instructions as the execution function.

[0034] Specifically, step S2 further includes: Step S2.1: Parse the instruction semantics of the target instruction to be optimized to identify the parallel operations contained in the instruction semantics, including data type and data width.

[0035] In this embodiment, the target instruction is a DADDMPY instruction, whose instruction semantics are: to execute two independent multiply-accumulate computation streams in parallel within one instruction cycle, including: The first computational flow is R1 = R1 + (S1 × S2), The second computational flow is R3 = R3 + (S3 × S4), S1, S2, S3, and S4 are the source operands, and R1 and R3 are the accumulator registers. All operands and registers are 32-bit signed integers with a data width of 32 bits.

[0036] Therefore, the parallel operation units contained in this DADDMPY instruction are: two parallel 32-bit integer multiplication operations and two parallel 32-bit integer addition operations. There is no data dependency between the two computational streams, making it suitable for parallel acceleration using SIMD instructions.

[0037] This embodiment only uses a VLIW instruction containing two parallel computation streams as an example for illustration. For VLIW instructions containing four, eight or more parallel computation streams, the semantic analysis method is the same as in this case, only the number of recognized parallel operation units needs to be expanded accordingly.

[0038] Step S2.2: Based on the data type and data width of the parallel operation (data type: 32-bit integer; data width: 32 bits; parallelism: 2 multiplications + 2 additions), select one or more SIMD instructions that can implement parallel operations from the host processor's SIMD instruction set, and determine the intrinsic function corresponding to one or more SIMD instructions as the execution function.

[0039] Reference Figure 1 This demonstrates the basic principle of SIMD instruction processing: multiple source operands are packed into a large SIMD register, and a single parallel operation instruction simultaneously performs operations on multiple data components in the register to obtain the final output result. The SIMD instruction set includes at least one of the AVX, AVX2, or SSE instruction sets.

[0040] In this embodiment, the host processor (x86 architecture, supporting AVX2 instruction set) has the following features: the AVX2 instruction set provides a 256-bit SIMD register, and a 256-bit register can hold eight 32-bit integers at the same time, that is, a single SIMD instruction can perform operations on a maximum of eight groups of 32-bit integers at the same time.

[0041] Based on the requirements extracted in step S2.1 (two parallel 32-bit integer multiplications and two parallel 32-bit integer additions), and after consulting the Intel Intrinsic Functions Guide, the following intrinsic functions were selected as the execution functions: Intrinsic functions of arithmetic operations: _mm256_mullo_epi32: This instruction performs parallel multiplication of corresponding 32-bit integers in two 256-bit registers. It completes eight 32×32-bit multiplication operations in one instruction cycle and returns the lower 32 bits of the eight 32-bit products. The 8-way parallel capability of this instruction completely covers the two parallel multiplication requirements of the DADDMPY instruction. The remaining six channels can be used to fill other irrelevant data or left blank.

[0042] `_mm256_add_epi32`: This instruction performs parallel addition of corresponding 32-bit integers in two 256-bit SIMD registers, completing eight 32+32-bit addition operations in one instruction cycle. This instruction also covers the two parallel addition requirements of the `DADDMPY` instruction.

[0043] Data loading and storage class intrinsic functions: _mm256_set_epi32: Used to assemble eight independent 32-bit integer values ​​into a single 256-bit SIMD register variable.

[0044] _mm256_loadu_si256: Used to load unaligned 256-bit data from memory into a SIMD register.

[0045] _mm256_storeu_si256: Used to write 256 bits of data in the SIMD register back to memory.

[0046] Based on the above analysis, it is confirmed that using the intrinsic functions of the AVX2 instruction set can efficiently and in parallel complete all computational tasks of the DADDMPY instruction. Even if the parallel width of the SIMD instruction (8 channels) is greater than that of the DSP instruction (2 channels), this method can still work correctly, and it reserves expansion space for processing DSP VLIW instructions with higher parallelism (such as 4-channel or 8-channel).

[0047] Step S3: Write a processing function, which calls the execution function to complete the parallel operations in the target instruction.

[0048] Specifically, step S3 further includes: Step S3.1: Create a source file corresponding to the target instruction. The source file name includes the mnemonic of the target instruction to be optimized and the name of the SIMD instruction set. Preferably, to facilitate code management and maintenance, a separate source file is created for each target instruction to be optimized. In this embodiment, a C++ source file named handle_DADDMPY_avx2.cpp is created.

[0049] Step S3.2: Define a processing function in the source file. The input parameter of the processing function is a pointer to the DSP register file. Specifically, the function signature of the first processing function is void process_DADDMPY_avx2(int32_t*dsp_regs); this function accepts a pointer to the analog DSP register file as a parameter.

[0050] Step S3.3: Inside the processing function, the source operands S1, S2, S3, and S4 required by the DADDMPY instruction, as well as the initial values ​​of the accumulator registers R1 and R3, are retrieved from the simulated DSP register file dsp_regs (assuming these values ​​have already been extracted during the instruction decoding stage). To utilize the SIMD instruction, this discrete data is loaded into 256-bit SIMD registers. Specifically, two vectors of type __m256i are defined: one vector stores the multiplier, and the other stores the augend (i.e., the initial value of the accumulator). The data positions within the 256-bit vectors are arranged using the _mm256_set_epi32 intrinsic function to ensure correct matching for subsequent parallel computation. For example, S1 and S2 are placed in the same channel of the two vectors, and S3 and S4 are placed in another channel.

[0051] Step S3.4: Call the execution function to perform parallel operations and obtain the calculation result vector.

[0052] Specifically, two SIMD instructions are used to complete calculations that previously required multiple serial instructions. The first instruction is a parallel multiplication, which calls the intrinsic function _mm256_mullo_epi32 and stores the result in the vector v_mul_results, which contains the results of S1×S2 and S3×S4. The second instruction is a parallel addition, which calls the intrinsic function _mm256_add_epi32 and adds v_mul_results to the vector containing the initial value of the accumulator register. The result is stored in the vector v_final_results, which contains the final results of R1+(S1×S2) and R3+(S3×S4).

[0053] Step S3.5: Extract the calculated result vector from the SIMD registers and write it back to the accumulator register in the DSP register file. Specifically, define a temporary array of type int32_t with a length of 8, and call the intrinsic function _mm256_storeu_si256 to store the final result vector (v_final_results vector) into the temporary array; then, according to the data layout of _mm256_set_epi32 mentioned above, write the value at the position corresponding to R1 in the temporary array to the storage location R1 pointed to by the dsp_regs pointer, and write the value at the position corresponding to R3 in the temporary array to the storage location R3 pointed to by the dsp_regs pointer. (For example, R3 is based on the layout of set).

[0054] At this point, the first processing function (process_DADDMPY_avx2 function) has achieved a function that is completely equivalent to the target instruction to be optimized (DADDMPY instruction), but its execution method is based on the parallel execution of the host processor's SIMD hardware.

[0055] Step S4: In the source code, replace the original simulation logic corresponding to the target instruction with a call to the processing function, and add an include declaration for the file containing the processing function to obtain the modified source code.

[0056] Specifically, step S4 further includes: Step S4.1: In the source code, locate the instruction decoding and execution module used for instruction decoding and execution. The instruction decoding and execution module contains a switch-case branch structure, and each case branch corresponds to the opcode of a DSP instruction. Step S4.2: In the instruction decoding and execution module, locate the case branch corresponding to the opcode of the target instruction (DADDMPY instruction), and delete all the original simulation logic code blocks within the case branch; Step S4.3: Within the case branch, write a call statement to the processing function. The call statement takes the DSP register file pointer as the actual parameter and obtains the source code after writing the call statement. Step S4.4: Add the include declaration of the source file to the source code after writing the call statement to obtain the modified source code.

[0057] Reference Figure 2This is a schematic diagram of the Very Long Instruction Word (VLIW) processing flow. Previously, the DADDMPY instruction, like other instructions, followed the normal instruction processing path, using software-simulated registers for inefficient serial computation. After the replacement, when the emulator encounters a DADDMPY instruction, the program flow enters a dedicated VLIW processing path. Through the parallel sub-operation processing core (i.e., the first processing function `process_DADDMPY_avx2`), this core performs x86 SIMD register calls, efficiently completing the computation and ultimately achieving instruction completion.

[0058] Step S5: Recompile the modified source code using a compiler that supports the SIMD instruction set to generate the target executable file.

[0059] Specifically, step S5 further includes: Step S5.1: Configure the compiler's compilation options and enable the compilation switch corresponding to the SIMD instruction set.

[0060] Specifically, on x86 architecture processors that support the AVX2 instruction set, enable the -mavx2 compilation option (e.g., using GCC 9.0 or later). Step S5.2: Use the configured compiler to compile and link the modified source code to generate the target executable file.

[0061] The optimized DSP emulator was tested.

[0062] By testing the target executable file (the optimized DSP simulator executable file) and loading the same test cases as in step S1.3 (such as audio codec algorithms), it was observed that the time taken for the entire simulation process was significantly reduced compared to before optimization, thereby effectively improving the development and verification efficiency of DSP kernel simulation.

[0063] Example 2: The difference between this embodiment and Embodiment 1 is that the host processor does not support the AVX2 instruction set but supports the SSE4.1 instruction set.

[0064] The method also includes a runtime processor characteristic detection step before executing step S4: Step A: Call the CPUID instruction to read the host processor's SIMD instruction set support information and output a flag that identifies the type of SIMD instruction set supported by the host processor. The flag indicates that the current processor does not support the AVX2 instruction set but supports the SSE4.1 instruction set.

[0065] Step B: Based on the output of Step A, point the function pointer to the second processing function corresponding to the SSE4.1 instruction set.

[0066] Step C: In the call statement of step S4, the second processing function is called through the function pointer.

[0067] The second processing function is generated as follows: In step S2, based on the instruction semantics of the target instruction DADDMPY to be optimized, the following intrinsic functions are selected as execution functions from the SSE4.1 instruction set: _mm_mullo_epi32, _mm_add_epi32, _mm_set_epi32, _mm_loadu_si128, and _mm_storeu_si128.

[0068] In step S3, a separate instruction processing file handle_DADDMPY_sse.cpp is written, in which a second processing function is defined with the function signature void process_DADDMPY_sse(int32_t*dsp_regs), which internally calls the aforementioned SSE4.1 intrinsic function to complete the calculation.

[0069] In step S4, the original simulation logic code block corresponding to the DADDMPY instruction in the DSP simulation project source code is replaced with a call statement to the second processing function process_DADDMPY_sse.

[0070] In step S5, the target executable file is generated by recompiling using a compiler that supports the SSE4.1 instruction set.

[0071] Example 3: The present invention also provides a system for optimizing DSP kernel simulation based on SIMD instructions. The system for optimizing DSP kernel simulation based on SIMD instructions can be implemented by executing the process steps of the method for optimizing DSP kernel simulation based on SIMD instructions. That is, those skilled in the art can understand the method for optimizing DSP kernel simulation based on SIMD instructions as a preferred embodiment of the system for optimizing DSP kernel simulation based on SIMD instructions.

[0072] Specifically, the system for optimizing DSP kernel emulation based on SIMD instructions includes: Module M1 acquires the executable file and source code of the DSP simulation project to be optimized, collects the CPU time of each DSP instruction in the executable file through the performance profiling tool, and identifies the DSP instructions whose CPU time meets the preset threshold conditions as the target instructions to be optimized. Module M2 parses the instruction semantics of the target instruction, identifies parallel operations from the instruction semantics, selects one or more SIMD instructions that can implement parallel operations from the host processor's SIMD instruction set based on the data type and data width of the parallel operations, and determines the intrinsic function corresponding to one or more SIMD instructions as the execution function. Module M3 contains a processing function that calls the execution function to complete the parallel operations in the target instruction. In module M4, the original simulation logic corresponding to the target instruction is replaced with a call to the processing function in the source code, and the include declaration of the file where the processing function is located is added to obtain the modified source code; Module M5 uses a compiler that supports the SIMD instruction set to recompile the modified source code and generate the target executable file.

[0073] Specifically, module M1 further includes: Module M1.1: Deploy a DSP simulation project on a computer or server equipped with an x86 architecture processor (e.g., an Intel Core i7 series processor supporting Advanced Vector Extensions instruction set). The DSP simulation project includes complete source code, compilation scripts, an executable file (an unoptimized, executable version of the DSP emulator), one or more DSP target applications, performance profiling tools, and a register file for simulating DSP register states, storing source operands and computation results. The DSP simulation project is used to simulate the Texas Instruments TMS320C6713 series DSP, which has a typical Very Long Instruction Word (VLIW) architecture. The DSP target applications serve as test cases, compiled into executable binaries for the simulated DSP (i.e., the TMS320C6713).

[0074] To comprehensively evaluate performance bottlenecks, test cases should cover different application scenarios, such as an audio processing program that implements a finite impulse response filter, a radar signal processing program that performs a fast Fourier transform, and a basic mathematical library that performs matrix multiplication.

[0075] Module M1.2: Launches the executable file to load the DSP target application, and simultaneously launches the performance profiling tool to collect the number of instructions executed and the CPU time occupied during the execution of the executable file, and generates a performance report.

[0076] Specifically, in a Linux environment, the perf performance profiling tool can be used, while in a Windows environment, professional tools such as Visual Studio Profiler or Intel VTune Profiler can be used. Performance profiling tools record key performance indicators such as the number of times each function and instruction is executed and the CPU time consumed during emulator execution.

[0077] Module M1.3: Extracts a list of instructions sorted by CPU time usage from the performance report, and identifies the top N DSP instructions with a cumulative CPU time usage exceeding 80% as target instructions to be optimized, where N is a positive integer greater than or equal to 1.

[0078] In a DSP simulator, there exists an instruction dispatch function (such as `execute_instruction`). Internally, this function uses a switch-case structure or a function pointer table to call the specific processing logic for different DSP instructions. Performance reports show which branches (i.e., the processing logic for which DSP instructions) are executed most frequently and consume the most CPU time within this instruction dispatch function.

[0079] In this embodiment, by analyzing a test case of an audio codec algorithm, it was found that a specific VLIW instruction (denoted as DADDMPY) had the highest execution frequency and longest execution time. This DADDMPY instruction bundles two parallel multiplication operations and two parallel addition operations within one instruction cycle. Its instruction semantics are: simultaneously execute R1 = R1 + (S1 × S2) and R3 = R3 + (S3 × S4), where R1 and R3 are both 32-bit accumulator registers, and S1, S2, S3, and S4 are all 32-bit source operands. Because this instruction was inefficient in the original serial simulation implementation, it was identified as the target instruction for optimization.

[0080] Specifically, module M2 further includes: Module M2.1: Parses the instruction semantics of the target instruction to be optimized to identify parallel operations contained in the instruction semantics, including data types and data widths.

[0081] In this embodiment, the target instruction is a DADDMPY instruction, whose instruction semantics are: to execute two independent multiply-accumulate computation streams in parallel within one instruction cycle, including: The first computational flow is R1 = R1 + (S1 × S2), The second computational flow is R3 = R3 + (S3 × S4), S1, S2, S3, and S4 are the source operands, and R1 and R3 are the accumulator registers. All operands and registers are 32-bit signed integers with a data width of 32 bits.

[0082] Therefore, the parallel operation units contained in this DADDMPY instruction are: two parallel 32-bit integer multiplication operations and two parallel 32-bit integer addition operations. There is no data dependency between the two computational streams, making it suitable for parallel acceleration using SIMD instructions.

[0083] This embodiment only uses a VLIW instruction containing two parallel computation streams as an example for illustration. For VLIW instructions containing four, eight or more parallel computation streams, the semantic analysis method is the same as in this case, only the number of recognized parallel operation units needs to be expanded accordingly.

[0084] Module M2.2: Based on the data type and data width of the parallel operation (data type: 32-bit integer; data width: 32 bits; parallelism: 2 multiplications + 2 additions), select one or more SIMD instructions that can implement parallel operations from the host processor's SIMD instruction set, and determine the intrinsic function corresponding to one or more SIMD instructions as the execution function.

[0085] Reference Figure 1 This demonstrates the basic principle of SIMD instruction processing: multiple source operands are packed into a large SIMD register, and a single parallel operation instruction simultaneously performs operations on multiple data components in the register to obtain the final output result. The SIMD instruction set includes at least one of the AVX, AVX2, or SSE instruction sets.

[0086] In this embodiment, the host processor (x86 architecture, supporting AVX2 instruction set) has the following features: the AVX2 instruction set provides a 256-bit SIMD register, and a 256-bit register can hold eight 32-bit integers at the same time, that is, a single SIMD instruction can perform operations on a maximum of eight groups of 32-bit integers at the same time.

[0087] Based on the requirements extracted by module M2.1 (two parallel 32-bit integer multiplications and two parallel 32-bit integer additions), and after consulting the Intel Intrinsic Functions Guide, the following intrinsic functions were selected as the execution functions: Intrinsic functions of arithmetic operations: _mm256_mullo_epi32: This instruction performs parallel multiplication of corresponding 32-bit integers in two 256-bit registers. It completes eight 32×32-bit multiplication operations in one instruction cycle and returns the lower 32 bits of the eight 32-bit products. The 8-way parallel capability of this instruction completely covers the two parallel multiplication requirements of the DADDMPY instruction. The remaining six channels can be used to fill other irrelevant data or left blank.

[0088] `_mm256_add_epi32`: This instruction performs parallel addition of corresponding 32-bit integers in two 256-bit SIMD registers, completing eight 32+32-bit addition operations in one instruction cycle. This instruction also covers the two parallel addition requirements of the `DADDMPY` instruction.

[0089] Data loading and storage class intrinsic functions: _mm256_set_epi32: Used to assemble eight independent 32-bit integer values ​​into a single 256-bit SIMD register variable.

[0090] _mm256_loadu_si256: Used to load unaligned 256-bit data from memory into a SIMD register.

[0091] _mm256_storeu_si256: Used to write 256 bits of data in the SIMD register back to memory.

[0092] Based on the above analysis, it is confirmed that using the intrinsic functions of the AVX2 instruction set can efficiently and in parallel complete all computational tasks of the DADDMPY instruction. Even if the parallel width of the SIMD instruction (8 channels) is greater than that of the DSP instruction (2 channels), this method can still work correctly, and it reserves expansion space for processing DSP VLIW instructions with higher parallelism (such as 4-channel or 8-channel).

[0093] Specifically, module M3 further includes: Module M3.1: Creates a source file corresponding to the target instruction. The source file name includes the mnemonic of the target instruction to be optimized and the name of the SIMD instruction set. Preferably, to facilitate code management and maintenance, a separate source file is created for each target instruction to be optimized. In this embodiment, a C++ source file named handle_DADDMPY_avx2.cpp is created.

[0094] Module M3.2: Defines processing functions in the source file. The input parameter of the processing function is a pointer to the DSP register file. Specifically, the function signature of the first processing function is void process_DADDMPY_avx2(int32_t*dsp_regs); this function accepts a pointer to the analog DSP register file as a parameter.

[0095] Module M3.3: Inside the processing function, it retrieves the source operands S1, S2, S3, and S4, as well as the initial values ​​of the accumulator registers R1 and R3, required for the DADDMPY instruction from the simulated DSP register file dsp_regs (assuming these values ​​have already been extracted during the instruction decoding stage). To utilize the SIMD instruction, this discrete data is loaded into 256-bit SIMD registers. Specifically, two vectors of type __m256i are defined: one vector stores the multiplier, and the other stores the augend (i.e., the initial value of the accumulator). The data positions within the 256-bit vectors are arranged using the _mm256_set_epi32 intrinsic function to ensure correct matching for subsequent parallel computation. For example, S1 and S2 are placed in the same channel of the two vectors, and S3 and S4 are placed in another channel.

[0096] Module M3.4: Calls the execution function to perform parallel operations and obtains the computation result vector.

[0097] Specifically, two SIMD instructions are used to complete calculations that previously required multiple serial instructions. The first instruction is a parallel multiplication, which calls the intrinsic function _mm256_mullo_epi32 and stores the result in the vector v_mul_results, which contains the results of S1×S2 and S3×S4. The second instruction is a parallel addition, which calls the intrinsic function _mm256_add_epi32 and adds v_mul_results to the vector containing the initial value of the accumulator register. The result is stored in the vector v_final_results, which contains the final results of R1+(S1×S2) and R3+(S3×S4).

[0098] Module M3.5: Extracts the computation result vector from the SIMD registers and writes it back to the accumulator register in the DSP register file. Specifically, it defines a temporary array of type int32_t with a length of 8, calls the intrinsic function _mm256_storeu_si256 to store the final result vector (v_final_results vector) into the temporary array; then, according to the data layout of _mm256_set_epi32 mentioned above, it writes the value at the position corresponding to R1 in the temporary array to the storage location R1 pointed to by the dsp_regs pointer, and writes the value at the position corresponding to R3 in the temporary array to the storage location R3 pointed to by the dsp_regs pointer. (For example, R3 is based on the layout of set).

[0099] At this point, the first processing function (process_DADDMPY_avx2 function) has achieved a function that is completely equivalent to the target instruction to be optimized (DADDMPY instruction), but its execution method is based on the parallel execution of the host processor's SIMD hardware.

[0100] Specifically, module M4 further includes: Module M4.1: In the source code, the instruction decoding and execution module is located, which is used for instruction decoding and execution. The instruction decoding and execution module contains a switch-case branch structure, and each case branch corresponds to the opcode of a DSP instruction. Module M4.2: In the instruction decoding and execution module, locate the case branch corresponding to the opcode of the target instruction (DADDMPY instruction) and delete all original simulation logic code blocks within the case branch; Module M4.3: Within the case branch, write the call statement to the processing function. The call statement takes the DSP register file pointer as the actual parameter and obtains the source code after writing the call statement. Module M4.4: Adds include declarations of source files to the source code after the call statement is written, resulting in the modified source code.

[0101] Reference Figure 2 This is a schematic diagram of the Very Long Instruction Word (VLIW) processing flow. Previously, the DADDMPY instruction, like other instructions, followed the normal instruction processing path, using software-simulated registers for inefficient serial computation. After the replacement, when the emulator encounters a DADDMPY instruction, the program flow enters a dedicated VLIW processing path. Through the parallel sub-operation processing core (i.e., the first processing function `process_DADDMPY_avx2`), this core performs x86 SIMD register calls, efficiently completing the computation and ultimately achieving instruction completion.

[0102] Specifically, module M5 further includes: Module M5.1: Configures compiler options and enables compilation switches corresponding to the SIMD instruction set.

[0103] Specifically, on x86 architecture processors that support the AVX2 instruction set, enable the -mavx2 compilation option (e.g., using GCC 9.0 or later). Module M5.2: Uses the configured compiler to compile and link the modified source code to generate the target executable file.

[0104] The optimized DSP emulator was tested.

[0105] By testing the target executable file (the optimized DSP simulator executable file) and loading the same test cases as in module M1.3 (such as audio codec algorithms), it was observed that the time taken for the entire simulation process was significantly reduced compared to before optimization, thus effectively improving the development and verification efficiency of DSP kernel simulation.

[0106] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0107] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features of the present invention can be arbitrarily combined with each other.

Claims

1. A method for optimizing DSP kernel emulation based on SIMD instructions, the method being executed on a host processor equipped with a SIMD instruction set, characterized in that, Includes the following steps: Step S1: Obtain the executable file and source code of the DSP simulation project to be optimized. Use a performance profiling tool to collect the CPU time of each DSP instruction in the executable file and identify the DSP instructions whose CPU time meets the preset threshold as the target instructions to be optimized. Step S2: parse the instruction semantics of the target instruction, identify parallel operations from the instruction semantics, select one or more SIMD instructions that can implement the parallel operations from the SIMD instruction set of the host processor according to the data type and data width of the parallel operations, and determine the intrinsic function corresponding to the one or more SIMD instructions as the execution function. Step S3: Write a processing function, which calls the execution function to complete the parallel operations in the target instruction; Step S4: In the source code, replace the original simulation logic corresponding to the target instruction with a call to the processing function, and add an include declaration to the file where the processing function is located to obtain the modified source code; Step S5: Recompile the modified source code using a compiler that supports the SIMD instruction set to generate a target executable file.

2. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 1, characterized in that, In step S1, the target instruction is a Very Long Instruction Word (VLIW) instruction.

3. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 1, characterized in that, Step S1 further includes: Step S1.1: Deploy the DSP simulation project on a computer equipped with an x86 architecture processor. The DSP simulation project includes source code, compilation scripts, executable files, one or more DSP target applications, performance profiling tools, and a register file for simulating DSP register states. The register file is used to store source operands and calculation results. Step S1.2: Start the executable file to load the DSP target application, and at the same time start the performance profiling tool to collect the number of instruction executions and CPU time occupied by the executable file during execution, and obtain a performance report; Step S1.3: Extract the instruction list sorted by CPU time from the performance report, and determine the top N DSP instructions with a cumulative CPU time usage of more than 80% as the target instructions to be optimized, where N is a positive integer greater than or equal to 1.

4. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 3, characterized in that, Step S2 further includes: Step S2.1: Parse the instruction semantics of the target instruction to identify the parallel operations contained in the instruction semantics. The parallel operations include a first computational stream and a second computational stream. The first computational stream is R1 = R1 + (S1 × S2), and the second computational stream is R3 = R3 + (S3 × S4). R1 ​​and R3 are both accumulator registers, and S1, S2, S3, and S4 are all source operands. Step S2.2: Based on the data type and data width of the parallel operation, select one or more SIMD instructions from the host processor's SIMD instruction set that can implement the parallel operation, and determine the intrinsic function corresponding to the one or more SIMD instructions as the execution function.

5. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 4, characterized in that, In step S2, the SIMD instruction set includes at least one of the AVX, AVX2, or SSE instruction sets.

6. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 5, characterized in that, Step S3 further includes: Step S3.1: Create a source file corresponding to the target instruction. The name of the source file includes the mnemonic of the target instruction and the name of the SIMD instruction set. Step S3.2: Define a processing function in the source file, wherein the input parameter of the processing function is a pointer to the DSP register file; Step S3.3: Inside the processing function, the source operands and accumulator register of the target instruction are obtained from the DSP register file and loaded into the SIMD register; Step S3.4: Call the execution function to perform the parallel operation and obtain the calculation result vector; Step S3.5: Extract the calculation result vector from the SIMD register and write it back to the accumulator register in the DSP register file.

7. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 6, characterized in that, Step S4 further includes: Step S4.1: In the source code, locate the instruction decoding and execution module used for instruction decoding and execution; Step S4.2: In the instruction decoding and execution module, locate the original simulation logic code block corresponding to the target instruction, and delete the original simulation logic code block from the source code; Step S4.3: Write a call statement for the processing function at the location left after the original simulation logic code block is deleted; the call statement uses the DSP register file pointer as the actual parameter to obtain the source code after the call statement is written. Step S4.4: Add the include declaration of the source file to the source code after the written call statement to obtain the modified source code.

8. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 7, characterized in that, Step S5 further includes: Step S5.1: Configure the compiler's compilation options and enable the compilation switch corresponding to the SIMD instruction set; Step S5.2: Compile and link the modified source code using the configured compiler to generate the target executable file.

9. The method for optimizing DSP kernel simulation based on SIMD instructions according to claim 1, characterized in that, The method further includes a runtime processor characteristic detection step before performing step S4: Step A: Detect the SIMD instruction set supported by the host processor; Step B: Based on the detection results, select a processing function corresponding to the SIMD instruction set supported by the host processor; the processing function includes: The first processing function is used by the host processor that supports the AVX2 instruction set; The second processing function is used for host processors that support the SSE4.1 instruction set; The third processing function is used by the host processor to support the baseline instruction set.

10. A system for optimizing DSP kernel simulation based on SIMD instructions, employing the method for optimizing DSP kernel simulation based on SIMD instructions as described in any one of claims 1-9, characterized in that, include: Module M1 acquires the executable file and source code of the DSP simulation project to be optimized, collects the CPU time of each DSP instruction in the executable file through a performance profiling tool, and identifies the DSP instructions whose CPU time meets the preset threshold condition as the target instructions to be optimized. Module M2 parses the instruction semantics of the target instruction, identifies parallel operations from the instruction semantics, selects one or more SIMD instructions that can implement the parallel operations from the host processor's SIMD instruction set according to the data type and data width of the parallel operations, and determines the intrinsic function corresponding to the one or more SIMD instructions as the execution function. Module M3, writes a processing function, which calls the execution function to complete the parallel operations in the target instruction; In module M4, the original simulation logic corresponding to the target instruction is replaced with a call to the processing function in the source code, and an include declaration is added to the file where the processing function is located, resulting in the modified source code. Module M5 recompiles the modified source code using a compiler that supports the SIMD instruction set to generate a target executable file.

Citation Information

Patent Citations

  • Automatic vectorizing method for heterogeneous SIMD expansion components

    CN103279327A

  • Instruction generation method and device and electronic equipment

    CN112230995A