A method and system for maintaining consistency between a floating point operation algorithm verification prototype and hardware engineering

Abstract

A method and system for ensuring consistency between a floating-point arithmetic algorithm verification prototype and hardware engineering, relating to the field of floating-point arithmetic, are disclosed. The method includes: obtaining the HDL source code of a hardware floating-point IP core; converting the sequential logic describing floating-point operations in the HDL source code into a behavioral-level combinational logic expression, which retains the computational logic of floating-point operations; compiling the converted HDL source code using an HDL compilation tool to generate a library file executable on a processor; calling function interfaces in the library file to perform floating-point operations in a prototype verification program running on the processor; and integrating a hardware floating-point IP core into the hardware system to implement floating-point operations, wherein the library file and the hardware floating-point IP core are based on the same HDL source code. Implementing this method can reduce the cost of ensuring consistency between the floating-point arithmetic algorithm verification prototype and hardware engineering.

Description

Technical Field

[0001] This application relates to the field of floating-point arithmetic, and in particular to a method and system for verifying the consistency between a floating-point arithmetic algorithm prototype and hardware engineering. Background Technology

[0002] In fields of precision computing such as scientific computing, astronomy, and meteorology, 128-bit floating-point numbers are typically required to meet accuracy requirements. The development of such systems follows a process of first prototyping the algorithm and then implementing the hardware engineering.

[0003] To ensure consistency between prototype verification and hardware implementation, existing technologies employ a self-developed C language floating-point library. Specifically, a 128-bit floating-point arithmetic library is developed in C according to the IEEE 754 standard. During the prototype verification phase, this C library is called to verify the algorithms. In the hardware implementation phase, the floating-point module is reimplemented in Verilog based on the logic of this C library. Since both the software and hardware originate from the same C library design, consistent computational behavior is guaranteed.

[0004] However, developing a 128-bit floating-point C library that conforms to the IEEE 754 standard is a huge undertaking, requiring the implementation of complex rounding logic, denormalized number processing, exception flag generation, and other mechanisms. The development cycle usually takes several months and the development cost is high. Summary of the Invention

[0005] This application provides a method and system for ensuring consistency between floating-point arithmetic algorithm verification prototypes and hardware engineering, thereby reducing the cost of maintaining consistency between floating-point arithmetic algorithm verification prototypes and hardware engineering.

[0006] Firstly, this application provides a method for ensuring consistency between a floating-point arithmetic algorithm verification prototype and hardware engineering, applied to a computer. The method includes: obtaining the HDL source code of a hardware floating-point IP core, which is used to implement floating-point arithmetic. The HDL source code is written in a hardware description language and contains circuit logic descriptions for floating-point arithmetic; extracting the behavioral-level combinational logic expression of floating-point arithmetic from the HDL source code, whereby the combinational logic expression retains the computational logic of floating-point arithmetic; compiling the converted HDL source code using an HDL compilation tool to generate a library file executable on a processor. This library file contains function interfaces corresponding to the computational logic of floating-point arithmetic, and these function interfaces use multi-word data types to represent high-precision floating-point numbers; calling the function interfaces in the library file to perform floating-point arithmetic operations in a prototype verification program, which runs on a processor; and integrating the hardware floating-point IP core into the hardware system to implement floating-point arithmetic operations, wherein the library file and the hardware floating-point IP core are based on the same HDL source code.

[0007] In the above embodiments, automatic conversion from HDL source code to software library is achieved, ensuring consistency of computational logic and avoiding redundant development. The use of multi-word data types ensures the accuracy of high-precision floating-point operations, reduces development costs, and improves verification efficiency. The hardware and software implementations are based on the same source code, effectively eliminating implementation differences and ensuring functional equivalence.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the step of converting the timing logic describing floating-point operations in the HDL source code into a behavioral-level combinational logic expression specifically includes: identifying the module structure implementing floating-point operations in the HDL source code; when the HDL source code is implemented using timing logic, removing the timing control code related to the clock cycle in the HDL source code; when the HDL source code is implemented using combinational logic, extracting the core calculation code, retaining the core calculation code that executes the floating-point operation, encapsulating the core calculation code into an HDL function, the HDL function receiving floating-point operands as input parameters, and the HDL function outputting the floating-point operation result as a return value; retaining the rounding processing logic and exception handling logic in the core calculation code, and ensuring that the calculation logic of the HDL function maintains numerical calculation consistency with the timing logic of the hardware floating-point IP core.

[0009] In the above embodiments, complex sequential logic is simplified into pure combinational logic, and the core calculation code is extracted and standardized and encapsulated. Key rounding and exception handling logic is retained to ensure the consistency of numerical calculations. Modular function encapsulation facilitates code reuse and maintenance, improving development efficiency.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, the step of compiling the converted HDL source code using an HDL compilation tool to generate a library file executable on a processor specifically includes: using an HDL compilation tool to translate the converted HDL source code into processor-executable program code; calling a compiler to compile the translated program code into a library file, which contains multiple floating-point arithmetic functions, each implementing a floating-point arithmetic operation; defining a unified calling interface for the floating-point arithmetic functions in the library file, which specifies the data format of the input operands and the data format of the output result, and the data format of the calling interface corresponds to the port signal definition of the hardware floating-point IP core; and generating a header file for the library file, which declares the name, input parameter type, and return value type of each floating-point arithmetic function.

[0011] In the above embodiments, an automated toolchain is used to complete the conversion and compilation from HDL to C++, generating a standardized function library. A unified calling interface specification simplifies application development, and the correspondence between data formats ensures interface compatibility. The automated generation process reduces human coding errors and improves code quality.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of integrating a hardware floating-point IP core into a hardware system to implement floating-point operations, the method further includes: extracting pipeline stage information from the HDL source code of the hardware floating-point IP core, determining the number of clock cycles required for each floating-point operation based on the pipeline stage information, and storing the number of clock cycles as a performance parameter in the library file.

[0013] In the above embodiments, accurate acquisition of timing path information and quantification of critical path latency provide precise performance references for the software. The extraction and storage of timing parameters support runtime performance estimation, helping to identify and resolve performance bottlenecks early.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after the step of integrating a hardware floating-point IP core into the hardware system to implement floating-point operations, the method further includes: embedding a statistics module in the function interface of the library file, the statistics module being used to record the number of calls and call intervals of the function interface; obtaining the number of calls and call interval data during the execution of the prototype verification program through the statistics module, and calculating the total number of execution cycles based on the number of calls and the corresponding number of clock cycles; calculating the total number of execution cycles with the clock frequency of the hardware system to obtain the estimated execution time of the algorithm in the hardware; comparing the estimated execution time with a preset time indicator, and outputting optimization suggestions when the estimated execution time exceeds the preset time indicator.

[0015] In the above embodiments, the embedded statistics module collects runtime data in real time and accurately estimates execution time by combining it with hardware parameters. The automatic generation of performance analysis and optimization suggestions simplifies the tuning process and improves the overall system efficiency.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, the library file preserves the hardware floating-point IP core's processing logic for special floating-point values, including denominated numbers, infinity, not-numerical numbers, and signed zero.

[0017] In the above embodiments, the hardware IP core's processing logic for special floating-point values ​​is fully preserved, ensuring the consistency of software and hardware behavior under boundary conditions. By implementing key logic such as asymptotic underflow of non-standard numbers, propagation rules for infinity, silent propagation of non-numerical values, and sign preservation for signed zeros, differences in results between software and hardware in special scenarios are avoided, improving the robustness and reliability of the system.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after integrating a hardware floating-point IP core into the hardware system to implement floating-point operations, the method further includes: parsing parameterized configuration statements in the HDL source code to obtain configurable floating-point format parameters, which include exponent width and mantissa width; generating multiple function interface versions in a library file based on the floating-point format parameters, each function interface version corresponding to a different floating-point format configuration; selecting the function interface version to use in the prototype verification program through compilation options or configuration files; selecting the corresponding function interface version for prototype verification based on the parameterized configuration adopted by the hardware floating-point IP core, and comparing the verification results with the running results of the hardware floating-point IP core to verify that the library file's support for different floating-point format parameter configurations is consistent with that of the hardware floating-point IP core.

[0019] In the above embodiments, parameterized configuration of floating-point format is implemented, supporting flexible adaptation to different precision requirements. Automatic generation and verification of multiple version interfaces ensure configuration consistency and improve code reusability.

[0020] In a second aspect, embodiments of this application provide a floating-point arithmetic algorithm verification system. The computer includes one or more processors and a memory. The memory is coupled to the one or more processors and is used to store computer program code, which includes computer instructions. The one or more processors call the computer instructions to cause the floating-point arithmetic algorithm verification system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a computer, cause the floating-point arithmetic algorithm verification system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the floating-point arithmetic algorithm verification system to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the floating-point arithmetic algorithm verification system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0025] 1. By employing a method for generating software libraries from HDL source code, the design-to-implementation process is automated, avoiding inconsistencies inherent in manual development. Unified source code management ensures hardware and software functional equivalence, improving development efficiency and reducing maintenance costs. The multi-word data type design of library functions guarantees the accuracy of high-precision calculations, meeting the needs of precision computing. The application of automated toolchains simplifies the development process, reduces human error, and improves code quality and reliability.

[0026] 2. By employing a conversion technique from sequential logic to combinational logic, the complexity of hardware design is simplified while retaining core functionality. Standardized interface encapsulation and modular design improve code maintainability and reusability. Fully preserved exception handling and rounding logic ensure the accuracy of calculation results and reduce problems caused by implementation differences. The automated conversion process significantly improves development efficiency and reduces labor costs.

[0027] 3. By employing an HDL compilation toolchain to automatically generate library files, the software and hardware interface definitions are standardized, ensuring data format consistency. A unified function call interface simplifies application development and improves code readability. The accompanying header file generation mechanism guarantees the integrity of the interface specifications, facilitating program maintenance and upgrades. The automated compilation process reduces manual coding errors, improving code quality and reliability. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a method for verifying the consistency between the floating-point arithmetic algorithm prototype and the hardware engineering in an embodiment of this application.

[0029] Figure 2 This is another flowchart illustrating the method for verifying the consistency between the floating-point arithmetic algorithm prototype and the hardware engineering in the embodiments of this application;

[0030] Figure 3 This is a schematic diagram of the physical device structure of a computer in an embodiment of this application. Detailed Implementation

[0031] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification of this application, the singular expressions “a,” “an,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0032] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0033] To facilitate understanding, the application scenarios of the embodiments of this application are described below.

[0034] In current digital signal processing systems, floating-point arithmetic is a fundamental and crucial function. Floating-point arithmetic can typically be implemented in either software or hardware. Software implementation offers advantages such as high flexibility and low development cost, but its computational performance is lower; hardware implementation offers advantages such as high processing speed and high throughput, but it is more difficult to develop and has a longer verification cycle. To quickly verify the correctness of floating-point arithmetic algorithms in the early stages of development, it is usually necessary to first develop a software prototype program for functional verification, and then develop a hardware implementation based on the verified algorithm.

[0035] However, currently, software and hardware implementations are often completed independently by different development teams, which can lead to inconsistencies during the implementation process. For example, software and hardware implementations may differ in details such as numerical rounding and handling of special values, affecting the correctness of the system. Furthermore, the conversion from software prototype to hardware implementation requires rewriting code, which is labor-intensive and prone to introducing errors. In addition, hardware implementations typically employ parametric design to support different precision requirements, while software prototype programs often lack corresponding parametric support capabilities.

[0036] To address the aforementioned issues, a method for generating floating-point arithmetic libraries that guarantees consistency between hardware and software implementations is needed. This method should be able to automatically generate the corresponding software library from the HDL source code of the hardware implementation, ensuring that the software library and hardware implementation have identical computational behavior. Simultaneously, the software library should support the same parameterized configuration capabilities as the hardware, facilitating algorithm verification and optimization in the early stages of system development.

[0037] This embodiment proposes a method for generating a floating-point arithmetic library based on a hardware description language (HDL). This method extracts the core computational logic by analyzing HDL source code and converts it into a software implementation. By maintaining consistency in the computational flow, it ensures that the software library and the hardware implementation produce identical computational results. It also supports parameterized configuration, enabling the generation of floating-point arithmetic functions with different precisions according to actual needs. This method can significantly improve the development efficiency of floating-point arithmetic systems and reduce problems caused by inconsistencies in implementation.

[0038] To facilitate understanding, the method provided in this embodiment will be described in detail below, taking into account the above scenario. Please refer to [link / reference]. Figure 1This is a flowchart illustrating a method for verifying the consistency between the floating-point arithmetic algorithm prototype and the hardware engineering in an embodiment of this application.

[0039] S101. Obtain the HDL source code of the hardware floating-point IP core. The hardware floating-point IP core is used to implement floating-point operations. The HDL source code is written in a hardware description language and contains the circuit logic description of floating-point operations.

[0040] Hardware floating-point IP cores refer to dedicated hardware circuit modules used to perform floating-point mathematical operations, enabling efficient implementation of floating-point arithmetic operations such as addition, subtraction, multiplication, and division. HDL source code represents circuit design code written in a hardware description language (such as Verilog, VHDL, etc.), used to describe the structure and behavior of the hardware circuit. The circuit logic description for floating-point operations refers to the digital circuit structure implementing the IEEE 754 floating-point standard, described using HDL languages.

[0041] Specifically, obtaining the HDL source code for a hardware floating-point IP core includes: obtaining the HDL source code files of a commercial floating-point IP core from an IP vendor, or obtaining the source code of an open-source floating-point IP core from an open-source HDL code repository. This source code must contain a complete floating-point unit design, including input / output interface definitions, internal data path design, control logic design, etc., and must conform to the IEEE 754 floating-point standard specification.

[0042] In some embodiments, the HDL source code of the hardware floating-point IP core can be obtained in a variety of ways: Optionally, it can be obtained from a commercial IP vendor through the following steps: First, establish a cooperative relationship with the IP vendor and sign a usage license agreement; then obtain an evaluation version of the floating-point IP core that meets the project requirements; after the evaluation is passed, obtain the complete HDL source code package, which includes all design files, test files and documentation.

[0043] Alternatively, it can be obtained from the open-source community through the following steps: First, search for mature floating-point arithmetic IP core projects on open-source platforms such as GitHub; then download the open-source code and verify its functional completeness and standard compliance; finally, complete the licensing process according to the open-source license requirements to obtain usage rights. It is understood that other methods can also be used to obtain HDL source code, such as independent development or collaborative development with other organizations, etc., which are not limited here.

[0044] S102. Extract the behavioral combinational logic expression of floating-point operations from the HDL source code. This combinational logic expression retains the calculation logic of floating-point operations.

[0045] Sequential logic refers to logic circuits that transition between states according to a specific timing sequence under the control of a clock signal. Behavioral combinational logic refers to a logic expression that only describes the input-output relationship without involving timing control. Computational logic refers to logic circuit structures that implement specific mathematical operations.

[0046] Specifically, converting HDL source code into behavioral combinational logic requires removing all clock-related timing control code and retaining only pure data processing logic. This includes removing clock signal definitions, timing constraint settings, timing control logic, etc., transforming the multi-cycle pipeline structure into a single combinational logic structure. The converted code should maintain the original accuracy of numerical calculations, including key logic such as rounding and overflow detection.

[0047] In some embodiments, the conversion of HDL code from sequential to combinational logic can be achieved in a variety of ways:

[0048] Alternatively, manual code refactoring can be used: first, analyze the timing control structure in the source code; then, merge multi-cycle operations into a single cycle; finally, reorganize the data path to ensure that the functionality remains unchanged.

[0049] Alternatively, the transformation can be automated: first, use HDL analysis tools to extract key computational paths; then, automatically remove timing-dependent code using the tool; finally, generate an equivalent combinational logic description. It is understood that other transformation methods can also be used, such as a combination of manual and automated approaches, which are not limited here.

[0050] S103. The converted HDL source code is compiled using an HDL compilation tool to generate a library file that can be executed on the processor. This library file contains function interfaces corresponding to the calculation logic of floating-point operations. These function interfaces use multi-word data types to represent high-precision floating-point numbers.

[0051] HDL compilation tools are software tools that can convert HDL source code into other forms, such as Verilator. Library files are program code files containing reusable functions. Function interfaces are program interface specifications that define how functions are called. Multi-word data types are extended-precision data types represented by a combination of multiple basic data types.

[0052] Specifically, compiling source code using HDL compilation tools requires converting HDL to C++ and generating library functions that can be called by software. The compilation process includes steps such as code parsing, intermediate representation generation, code optimization, and target code generation. The generated library files should provide standard function call interfaces, support common floating-point operations, and ensure functional consistency with the original HDL code.

[0053] In some embodiments, HDL code compilation can be achieved in several ways: Optionally, an open-source toolchain approach can be used: first, tools such as Verilator are used to convert HDL to C++; then, the GCC compiler is used to generate a dynamic link library; finally, header files are generated to define the calling interface.

[0054] Alternatively, commercial tools can be used: first, commercial HDL compilers are used to perform code transformation; then, code optimization is performed to improve performance; finally, standard library files are packaged. It is understood that other compilation methods can also be used, such as self-developed compilers, etc., which are not limited here.

[0055] S104. In the prototype verification program, the function interface in the library file is called to perform floating-point operations. This prototype verification program runs on the processor.

[0056] Among these, a prototype verification program refers to an initial test program used to verify the correctness of an algorithm. Function interface calls refer to accessing functions in a library file through a predefined program interface. Floating-point operations include basic operations such as addition, subtraction, multiplication, division, comparison, and conversion. A processor refers to the central processing unit capable of executing instructions.

[0057] Specifically, calling library function interfaces in the prototype verification program requires first configuring the program environment, including adding header file references and linking library files. Then, the original floating-point arithmetic code is replaced with the corresponding library function calls, ensuring data type matching and correct handling of function return values. The verification program should cover various computational scenarios, including normal values, special values, and boundary values, and record the computation results for subsequent analysis.

[0058] In some embodiments, function interface calls can be implemented in several ways: Optionally, a direct replacement method can be used: First, identify the floating-point arithmetic statements in the original code; then replace each operation with the corresponding library function call; finally, adjust the data type to ensure compatibility; then perform functional verification on the replaced code; finally, generate a test report to record the verification results. This method is simple and intuitive, and facilitates problem localization.

[0059] Alternatively, an encapsulation and adaptation approach can be adopted: First, design a unified floating-point arithmetic interface class; then, encapsulate library function calls within the interface class; next, implement data type conversion and exception handling logic; then, modify the original code to call the interface class; finally, perform system testing to verify the correctness of the functionality. It is understood that other calling methods, such as mixed calling modes, can also be used, but this is not limited here.

[0060] S105. Integrate a hardware floating-point IP core into the hardware system to implement floating-point operations. This library file and the hardware floating-point IP core are based on the same HDL source code.

[0061] In this context, "hardware system" refers to a complete system including hardware components such as processors and memory. "Integration" refers to connecting the IP core to the system bus and configuring the relevant interfaces. "Based on the same HDL source code" means that the software library files and hardware IP cores originate from the same design code.

[0062] Specifically, integrating an IP core into a hardware system requires tasks such as bus interface design, clock configuration, and reset circuitry. It's crucial to ensure the IP core's interface signals match the system bus protocol and correctly handle data transmission timing. Simultaneously, IP core parameter options, such as precision bits and pipeline depth, need to be configured to meet system performance requirements. After integration, hardware functional verification is necessary to ensure the IP core functions correctly.

[0063] In some embodiments, hardware IP core integration can be achieved in several ways: Optionally, a standard bus interface approach can be used: First, the interface circuit is designed according to the system bus specification; then, clock tree synthesis and placement and routing are completed; next, formal verification is performed to ensure timing convergence; then, functional simulation is performed to verify the correctness of the interface; finally, a bitstream file is generated for system configuration. This approach facilitates system maintenance and upgrades.

[0064] Alternatively, a custom interface approach can be used: first, analyze the system data flow requirements; then design a dedicated data path and control logic; next, optimize the interface circuit to reduce latency; then complete the physical implementation and timing convergence; finally, perform system-level testing to verify functionality. It is understood that other integration methods, such as hybrid interface modes, can also be used, but this is not limited here.

[0065] The following provides a more detailed description of the process of the method provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the method for verifying the consistency between the floating-point arithmetic algorithm prototype and the hardware engineering in the embodiments of this application.

[0066] S201. Obtain the HDL source code of the hardware floating-point IP core. The hardware floating-point IP core is used to implement floating-point operations. The HDL source code is written in a hardware description language and contains the circuit logic description of floating-point operations.

[0067] In some embodiments, this step is similar to step S101, and will not be described again here.

[0068] S202. Identify the module structure that implements floating-point operations in the HDL source code, and extract the calculation process of floating-point operations from the HDL source code.

[0069] In this context, "module structure" refers to the functional unit defined using the `module` keyword in HDL code, encompassing input / output port definitions and internal logic implementation. The floating-point arithmetic process refers to the complete processing from input data to output result, including data format conversion, alignment, mantissa operations, and normalization. Extraction refers to identifying and acquiring the processing logic for specific functions through code analysis.

[0070] Identifying the module structure implementing floating-point arithmetic in HDL source code and extracting the computational flow is a crucial step in transforming complex hardware designs into clear algorithmic descriptions. First, it's necessary to analyze the hierarchical structure of the HDL source code to locate the core modules implementing floating-point arithmetic. These modules typically include input formatting units, preprocessing units, arithmetic units, and post-processing units. For the addition module, key sub-modules such as the alignment circuit, mantissa adder, and normalization circuit need to be identified. For the multiplication module, parts such as the exponent adder, mantissa multiplier, and rounding circuit need to be identified. By analyzing the port connections and internal data flows of these modules, a complete computational flowchart is established. In the specific implementation, by parsing the syntax tree of the HDL source code, key structures such as module definitions, always blocks, and assign statements are extracted, and the processing flow is reconstructed based on signal dependencies. For example, in the floating-point addition module, the extracted flow includes: comparing the exponents of two operands, right-shifting the smaller exponent operand to align its exponents, performing mantissa addition, determining whether the result needs normalization, and performing rounding. Simultaneously, the input-output relationship and control conditions of each processing step are recorded to form a complete algorithm description.

[0071] S203. When the HDL source code is implemented using sequential logic, remove the timing control code related to the clock cycle from the HDL source code.

[0072] Timing control code refers to the description of sequential circuits implemented using clock-triggered statements such as always@(posedge clk). Clock cycle dependent refers to operations that need to be triggered at a specific clock edge.

[0073] Removing timing control from HDL source code requires converting sequential logic into pure combinational logic. First, identify the timing control structures in the code, including clock signal definitions, clock-triggered always blocks, pipelined registers, etc. Then, merge multi-cycle operations into single-cycle combinational logic. In specific implementations, remove clock signal definitions, rewrite always@(posedgeclk) blocks as always@(*) blocks, and replace pipelined registers with direct connections. For example, directly cascade the computational logic of a 3-stage pipelined multiplier to form a single combinational logic multiplier. This conversion preserves complete computational functionality, facilitating subsequent compilation.

[0074] S204. When the HDL source code is implemented using combinational logic, extract the core calculation code and retain the core calculation code that performs the floating-point operation.

[0075] Among them, the core computing code refers to the combinational logic circuit description that implements numerical calculation functions.

[0076] Extracting the core computational code requires separating the key logic for floating-point arithmetic from the HDL source code. First, identify the input / output interfaces and data path structure. Then, extract the data processing logic, including modules for sign processing, exponentiation, and mantissa operations. Remove auxiliary logic unrelated to computation, such as debugging signals and performance counters. Retain the complete computation flow, ensuring that critical functions such as rounding, overflow detection, and special value judgment are not removed. The extracted code forms pure combinational logic units, providing a foundation for subsequent function encapsulation.

[0077] S205. Encapsulate the core calculation code into an HDL function. This HDL function receives floating-point operands as input parameters and outputs the floating-point operation result as the return value.

[0078] In HDL, a function is a reusable block of code defined using the `function` keyword. Input parameters are the input ports declared in the function definition. The return value is the output result produced after the function is executed. Encapsulation refers to organizing related code into independent functional units.

[0079] Encapsulating core computational code into HDL functions involves code refactoring and interface design. First, the function's input / output interfaces need to be determined, including operand bit width and data format. Then, the extracted core computational logic is reorganized into a function body. The function implements the complete floating-point arithmetic process but does not contain any timing control code. Specifically, the `function` keyword is used to define the function, declaring the type and bit width of the input parameters. For example, `[63:0]a, b` represents double-precision floating-point input. The function body implements the complete floating-point arithmetic process according to the IEEE 754 standard, including sign processing, exponent calculation, and mantissa operation. Finally, the result is output through the function's return value. For example, a floating-point addition function is defined as: `function[63:0]fadd(input[63:0]a, b)`, which returns a 64-bit floating-point number conforming to the IEEE 754 format. This function encapsulation method facilitates code reuse and maintenance while ensuring interface standardization.

[0080] S206. The rounding logic and exception handling logic in the core calculation code are retained, and the calculation logic of the HDL function maintains numerical calculation consistency with the timing logic of the hardware floating-point IP core.

[0081] The rounding logic refers to the numerical rounding rules implemented according to the IEEE 754 standard. The exception handling logic refers to the code that detects and handles special cases such as overflow, underflow, and denormalization. Numerical computation consistency means that the software implementation and hardware implementation produce completely identical computational results.

[0082] Retaining key processing logic in the core calculation code ensures consistency between software and hardware implementations. During the conversion process, the rounding modes specified by the IEEE 754 standard must be fully preserved, including rounding to nearest, rounding towards zero, rounding towards positive infinity, and rounding towards negative infinity. Simultaneously, the logic for handling special values ​​must be retained, including the judgment and handling of denormalized numbers, infinity, and NaN cases. In specific implementations, functions need to implement complete rounding logic; for example, after normalizing the calculation result, whether to carry over depends on the discarded bits and the current rounding mode. For abnormal cases, a complete detection and handling process must be implemented, such as checking whether the exponent overflows or underflows, and whether the result is a denormalized number. By maintaining the consistency of these processing logics, it is ensured that under any input conditions, the software library functions and the hardware IP core produce exactly the same calculation results.

[0083] S207. Use HDL compilation tools to translate the converted HDL source code into processor-executable program code.

[0084] HDL compilers are software tools that can translate HDL code into other languages, such as Verilator. Processor-executable program code refers to program code that conforms to the C++ language specification and can run on the target processor. Translation is the process of converting a description in one language into a description in another language.

[0085] Code transformation using HDL compilation tools is a crucial step in achieving hardware-software functional consistency. First, the transformation parameters of the HDL compilation tool are configured, including the target language version, optimization level, and data type mapping rules. Then, the HDL source code is input into the compilation tool for processing. The tool first performs syntax analysis and semantic checking on the HDL code, constructing an abstract syntax tree. Next, code transformation is performed, mapping the HDL hardware description structure to an equivalent C++ code structure. For example, HDL bitwise operations are converted to C++ bitwise operators, and HDL parallel blocks are converted to C++ sequential statements. For complex combinational logic, corresponding C++ function implementations are generated. The transformation process ensures that the functional semantics of the original code are preserved while leveraging C++ language features to improve code execution efficiency. Finally, C++ code conforming to the target processor architecture is generated, including necessary data type definitions and operation function implementations.

[0086] S208. Call the compiler to compile the translated program code into a library file. The library file contains multiple floating-point operation functions, each of which implements a floating-point operation.

[0087] In this context, a compiler is a program that converts C++ source code into machine code, such as GCC or MSVC. A library file is a program module containing reusable functionality. Floating-point arithmetic functions are program functions that implement specific floating-point operations. Floating-point operations include basic operations such as addition, subtraction, multiplication, and division.

[0088] Generating library files using a C++ compiler requires both code compilation and library packaging. First, compiler optimization options are set, including optimization level, target processor architecture, and vectorized instructions. Then, all C++ source files are compiled, including implementations of various arithmetic functions such as addition, subtraction, multiplication, and division. The compilation process includes preprocessing, compilation, optimization, and code generation. For each arithmetic function, the compiler generates efficient machine code implementations. For example, for the floating-point addition function, it generates machine code that includes sign handling, alignment, and mantissa operations. Finally, all compiled object files are packaged into a dynamic link library or static library, providing a unified function call interface. The generated library files contain complete floating-point arithmetic functionality and support linking and calling by applications.

[0089] S209. Define a unified calling interface for the floating-point arithmetic functions in the library file. This calling interface specifies the data format of the input operands and the data format of the output results. The data format of this calling interface corresponds to the port signal definition of the hardware floating-point IP core.

[0090] Here, the calling interface refers to the standardized definition of function calls between programs. Data format refers to the way data is stored in memory and its bit pattern. Hardware IP core port signals refer to the interface definition for data interaction between the IP core and external systems. The correspondence refers to the mapping relationship between the software interface and the hardware interface in terms of function and data representation.

[0091] Defining a unified calling interface for library files requires designing standardized function declarations and data type definitions. First, design data type mapping rules to map the bit width and data format of the hardware IP core to C++ data types. For example, map a 128-bit floating-point number to a structure consisting of four 32-bit integers. Then, define the function interface prototype, including the function name, parameter list, and return value type. The function interface needs to be consistent with the port definition of the hardware IP core to ensure correct data exchange. For example, if the IP core's input port is 128 bits wide, the corresponding function parameters should also use 128-bit data types. Simultaneously, implement necessary data format conversion functions to handle the conversion between software data types and hardware signal formats. Finally, define error handling and status return mechanisms to be consistent with the exception handling of the hardware IP core.

[0092] S210. Generate the header file that accompanies the library file. This header file declares the name, input parameter type, and return value type of each floating-point operation function. This library file contains the function interface corresponding to the calculation logic of floating-point operations. This function interface uses a multi-word data type to represent high-precision floating-point numbers.

[0093] In this context, the accompanying header file refers to the C++ header file that contains the interface declarations. The function name is the symbol used to identify a specific function. The input parameter type refers to the data type definition of the function parameters. The return value type refers to the data type of the function's execution result. Multi-word data types refer to extended-precision types represented by a combination of multiple basic types.

[0094] Generating a header file provides standard program interface declarations. First, a header file framework is created, containing necessary macro definitions and namespace declarations. Then, data types are defined, including basic type aliases and composite type structures. For example, `uint128_t` is defined to represent a 128-bit unsigned integer, and `float128_t` is defined to represent a 128-bit floating-point number. Next, the prototypes of all floating-point arithmetic functions are declared, including addition, subtraction, multiplication, division, comparison, and conversion operations. Each function declaration includes a complete parameter list and return type. For example, `float128_tfadd(float128_ta, float128_tb)` represents a 128-bit floating-point addition function. Necessary documentation comments are added, explaining the function's functionality, parameter requirements, and usage. Finally, the header file structure definition is generated to ensure that multiple inclusions do not lead to duplicate definition errors.

[0095] S211. In the prototype verification program, the function interface in the library file is called to perform floating-point operations. The prototype verification program runs on the processor.

[0096] In some embodiments, this step is similar to step S104, and will not be described again here.

[0097] S212. Integrate a hardware floating-point IP core into the hardware system to implement floating-point operations. This library file and the hardware floating-point IP core are based on the same HDL source code.

[0098] In some embodiments, this step is similar to step S105, and will not be described again here.

[0099] In some embodiments, the method further includes:

[0100] Extract pipeline stage information from the HDL source code of the hardware floating-point IP core, determine the number of clock cycles required for each floating-point operation based on the pipeline stage information, and store the number of clock cycles as a performance parameter in the library file.

[0101] In this context, pipeline stages refer to the number of sequential execution stages in a hardware circuit that break down a complete operation into multiple stages. Clock cycles refer to the total number of clock cycles required to complete one complete operation from input to output. Performance parameters are quantitative indicators that describe the performance characteristics of hardware operations.

[0102] Extracting pipeline stage information requires analyzing register insertion locations in the HDL source code. First, identify the pipeline register declarations in the code and count the number of register stages from input to output. For floating-point addition, a typical pipeline includes: input stage registers, parallel stage registers, mantissa stage registers, normalization stage registers, and output stage registers, a total of 5 pipeline stages, requiring 5 clock cycles to complete the operation. For floating-point multiplication, the pipeline may include 7-10 stages, with the number of clock cycles increasing accordingly. The extracted pipeline stage information is stored in a library file in the form of a data structure, for example, defining a structure: `struct PipelineInfo { int stages; int latency_cycles;}`, configuring corresponding parameters for each operation type. These performance parameters are used by upper-layer applications to evaluate hardware execution time during algorithm design, predict system performance bottlenecks, and guide algorithm optimization.

[0103] Extract timing path information from the HDL source code of the hardware floating-point IP core. This timing path information includes the logic gate latency and interconnect latency of each calculation stage of floating-point operation. Calculate the critical path latency of floating-point operation based on the timing path information. This critical path latency represents the minimum number of clock cycles required to complete one floating-point operation. Store the critical path latency as a timing parameter in a library file.

[0104] Timing path information refers to the time characteristics of signal propagation in digital circuits, including delays at each stage from input to output. Logic gate delay refers to the time required for an electronic signal to pass through basic logic gates (such as AND gates and OR gates). Interconnect delay refers to the time required for a signal to travel along a wire. The critical path is the signal propagation path in the circuit with the greatest delay. Clock cycle count refers to the number of clock signal cycles required to complete a specific operation.

[0105] Extracting and analyzing timing path information is a crucial step in optimizing system performance. First, static timing analysis tools (such as Synopsys' PrimeTime) are used to analyze the HDL source code to obtain detailed timing data of the circuit. The analysis tool builds a complete timing model by calculating the propagation delay of each logic gate and the RC delay of interconnects. For floating-point addition, a typical critical path includes: input data decoding (2ns) -> alignment comparison and shift (5ns) -> mantissa addition (4ns) -> normalization and rounding (3ns) -> result encoding (1ns), with a total delay of 15ns. Based on this delay value and the target clock frequency (e.g., 200MHz, 5ns cycle), the pipeline delay required to complete one addition operation is calculated to be 3 clock cycles. For multiplication, the critical path is typically longer: input processing (2ns) -> partial product generation (6ns) -> partial product compression (8ns) -> final addition (4ns) -> post-processing (3ns), with a total delay of 23ns, requiring a pipeline delay of 5 clock cycles at the same clock frequency.

[0106] It's important to note that these cycle counts represent the pipeline latency of a single operation. In ideal conditions where the pipeline is fully filled and there is no data dependency, the hardware can achieve a throughput of completing one operation per cycle. In practical applications, due to data dependency and pipeline cavitation, actual performance falls between the ideal throughput and the worst-case latency. These timing parameters are recorded in specific data structures within the library file, containing the pipeline latency value and theoretical throughput for each operation, providing performance estimation for upper-layer applications. For example, the library file defines the structure: `struct TimingInfo { float delay_ns; int pipeline_latency; int throughput_cycles;}`, and configures the corresponding timing parameters for each operation function.

[0107] A statistics module is embedded in the function interface of the library file. This module records the number of function calls and the call interval. The statistics module obtains the number of calls and call interval data during the execution of the prototype verification program. The total number of execution cycles is calculated based on the number of calls and the corresponding clock cycles. The total number of execution cycles is then calculated with the clock frequency of the hardware system to obtain the estimated execution time of the algorithm in the hardware. The estimated execution time is compared with a preset time target. When the estimated execution time exceeds the preset time target, optimization suggestions are output.

[0108] The statistics module refers to the functional unit used to collect and record program execution data. The number of calls represents the total number of times a specific function is executed. The call interval is the time difference between two consecutive function calls. The total number of execution cycles is the sum of clock cycles required to complete all computational operations. The clock frequency refers to the operating frequency of the hardware system. The estimated execution time is the program execution time calculated based on statistical data. The preset time target is the maximum allowable execution time specified by the system performance requirements.

[0109] Implementing statistical analysis requires adding a performance monitoring mechanism to the function interface. First, add counters and timestamp recording logic at the entry and exit points of each floating-point arithmetic function. The counters use 64-bit integers to avoid overflow, and the timestamps are obtained using a high-precision timer. For example, for the floating-point addition function, each call records: the current call count increments by 1, and the difference between the current timestamp and the previous call timestamp is used as the call interval. The total execution cycle is calculated based on the collected statistical data: **The first call is included in the complete pipeline latency cycle. For subsequent calls, if the call interval is greater than the pipeline latency, it is calculated based on the ideal throughput (one operation per cycle); if the call interval is less than the pipeline latency, it is included in the complete latency cycle.** For example, for a floating-point addition with a pipeline latency of 3 cycles, if the first 50 calls have sufficient intervals and the last 50 calls are close together, the total execution cycle count is approximately 3 + 49 × 1 + 50 × 3 = 202 cycles. Assuming a system clock frequency of 200MHz, the estimated execution time is: 202 × (1 / 200MHz) = 1.01 microseconds. The calculated estimated time is compared with a preset performance metric (e.g., 2 microseconds). If the time exceeds the threshold, optimization suggestions are generated, including specific measures such as reducing data dependency to improve pipeline efficiency, increasing parallel processing units, optimizing data access patterns, and adjusting the computation order. These statistical data and analysis results are stored in a dedicated performance analysis report to guide subsequent optimization efforts.

[0110] The process involves parsing parameterized configuration statements in the HDL source code to obtain configurable floating-point format parameters, including exponent and mantissa bit widths. Multiple function interface versions are generated in the library file based on these parameters, each corresponding to a different floating-point format configuration. In the prototype verification program, the appropriate function interface version is selected via compilation options or a configuration file. Based on the parameterized configuration used by the hardware floating-point IP core, the corresponding function interface version is selected for prototype verification. The verification results are then compared with the execution results of the hardware floating-point IP core to verify that the library file's support for different floating-point format parameter configurations is consistent with that of the hardware floating-point IP core.

[0111] In this context, parameterized configuration statements refer to statements in HDL code used to define configurable parameters, which are used to set variable parameters in the design. Exponent bit width refers to the number of binary digits representing the exponent in a floating-point number, determining the numerical range. Mantissa bit width refers to the number of binary digits representing the mantissa, determining the numerical precision. Function interface versions refer to a set of functions configured for different data formats. Compilation options refer to control parameters used during the program compilation phase. Configuration files are data files used to store and manage program configuration information.

[0112] Implementing parameterized floating-point format support involves several key steps. First, the source code is analyzed using an HDL code parsing tool to extract all parameterization configuration statements. The parsing tool identifies parameters defined by keywords such as `parameter` and `localparam`, obtaining parameter names, numerical ranges, and default values. The focus is on extracting parameters related to the floating-point format, including the configuration values ​​for the exponent width and mantissa width. Based on the extracted parameter information, the required floating-point format combinations are determined. For each format combination, a corresponding function interface implementation is generated in the library file. For example, when the exponent width is 8 bits and the mantissa width is 23 bits, a function interface supporting single-precision floating-point operations is generated; when the exponent width is 11 bits and the mantissa width is 52 bits, a function interface supporting double-precision floating-point operations is generated. Each function interface version includes a complete floating-point operation implementation, including data format conversion, operation processing, and result output. A configuration mechanism is designed in the prototype verification program to support selecting the function interface version to use through compilation options or configuration files. The compilation option method specifies the format parameters during program compilation, while the configuration file method loads the format parameters at runtime. Based on the actual parameter configuration of the hardware IP core, the corresponding function interface version is selected for verification testing. The verification process executes a complete test case set, including basic arithmetic tests, boundary value tests, and special value tests, and all test results are recorded. The software calculation results are compared bit by bit with the output of the hardware IP core to confirm complete consistency in numerical calculation, rounding, and exception handling. This method verifies that the library file correctly supports the same floating-point format configuration as the hardware IP core.

[0113] The floating-point arithmetic algorithm verification system in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference needed]. Figure 3 This is a schematic diagram of a physical device structure of a floating-point arithmetic algorithm verification system in this application embodiment.

[0114] It should be noted that, Figure 3 The structure of the floating-point arithmetic algorithm verification system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0115] like Figure 3 As shown, the floating-point arithmetic algorithm verification system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303, such as executing the methods described in the above embodiments. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0116] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including hard disks, etc.; and communication section 309 including network interface cards such as LAN (Local Area Network) cards, modems, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as disks, optical disks, magneto-optical disks, semiconductor memories, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0117] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0118] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0119] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0120] Specifically, the computer in this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the method for verifying the consistency between the floating-point arithmetic algorithm verification prototype and the hardware engineering provided in the above embodiment.

[0121] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the computer described in the above embodiments; or it may exist independently and not assembled into the computer. The storage medium carries one or more computer programs that, when executed by a processor of the computer, cause the computer to implement the floating-point arithmetic algorithm verification prototype and hardware engineering consistency method provided in the above embodiments.

[0122] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0123] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for verifying the consistency between a floating-point arithmetic algorithm prototype and hardware engineering, characterized in that, The method, applied to a floating-point arithmetic algorithm verification system, includes: Obtain the HDL source code of the hardware floating-point IP core, which is used to implement floating-point operations. The HDL source code is written in a hardware description language and contains the circuit logic description of floating-point operations. Extract the behavioral-level combinational logic expression of floating-point operations from the HDL source code, and the combinational logic expression retains the computational logic of the floating-point operations; The converted HDL source code is compiled using an HDL compilation tool to generate a library file that can be executed on a processor. The library file contains function interfaces corresponding to the calculation logic of the floating-point operation. The function interfaces use a multi-word data type to represent high-precision floating-point numbers. The prototype verification program calls the function interface in the library file to perform floating-point operations, and the prototype verification program runs on the processor. The hardware floating-point IP core is integrated into the hardware system to implement the floating-point operation, and the library file and the hardware floating-point IP core are based on the same HDL source code.

2. The method according to claim 1, characterized in that, The step of extracting the behavioral-level combinational logic expression of floating-point operations from the HDL source code specifically includes: Identify the module structure that implements floating-point operations in the HDL source code, and extract the calculation process of the floating-point operations from the HDL source code; When the HDL source code is implemented using sequential logic, remove the timing control code related to the clock cycle from the HDL source code. When the HDL source code is implemented using combinational logic, the core calculation code is extracted, and the core calculation code that performs the floating-point operation is retained. The core calculation code is encapsulated into an HDL function, which receives floating-point operands as input parameters and outputs the floating-point operation result as a return value. The rounding logic and exception handling logic in the core calculation code are retained, and the calculation logic of the HDL function maintains numerical calculation consistency with the timing logic of the hardware floating-point IP core.

3. The method according to claim 1, characterized in that, The step of compiling the converted HDL source code using an HDL compilation tool to generate a library file executable on a processor specifically includes: The HDL compilation tool is used to translate the converted HDL source code into processor-executable program code. The compiler is invoked to compile the translated program code into a library file, which contains multiple floating-point arithmetic functions, each of which implements a floating-point arithmetic operation. Define a unified calling interface for the floating-point arithmetic functions in the library file. The calling interface specifies the data format of the input operands and the data format of the output results. The data format of the calling interface corresponds to the port signal definition of the hardware floating-point IP core. Generate the header file that accompanies the library file, and declare the name, input parameter type and return value type of each floating-point operation function in the header file.

4. The method according to claim 1, characterized in that, After the step of integrating the hardware floating-point IP core into the hardware system to implement the floating-point operation, the method further includes: Extract pipeline stage information from the HDL source code of the hardware floating-point IP core; The number of clock cycles required for each floating-point operation is determined based on the pipeline stage information. The number of clock cycles is stored as a performance parameter in the library file.

5. The method according to claim 4, characterized in that, After the step of integrating the hardware floating-point IP core into the hardware system to implement the floating-point operation, the method further includes: A statistics module is embedded in the function interface of the library file, and the statistics module is used to record the number of times the function interface is called; The statistics module obtains the number of calls during the execution of the prototype verification program, and calculates the total number of execution cycles based on the number of calls and the corresponding number of clock cycles. The total number of execution cycles is calculated with the clock frequency of the hardware system to obtain the estimated execution time of the algorithm in the hardware. The estimated execution time is compared with a preset time indicator, and optimization suggestions are output when the estimated execution time exceeds the preset time indicator.

6. The method according to claim 1, characterized in that, The library file preserves the hardware floating-point IP core's processing logic for special floating-point values, including denominated numbers, infinity, not-numerical numbers, and signed zero.

7. The method according to claim 1, characterized in that, After the step of integrating the hardware floating-point IP core into the hardware system to implement the floating-point operation, the method further includes: Parse the parameterized configuration statements in the HDL source code to obtain configurable floating-point format parameters, including exponent bit width and mantissa bit width; Based on the floating-point format parameters, multiple function interface versions are generated in the library file, and the multiple function interface versions correspond to different floating-point format configurations; In the prototype verification program, the version of the function interface to be used is selected through compilation options or configuration files; Based on the parameterized configuration adopted by the hardware floating-point IP core, the corresponding function interface version is selected for prototype verification, and the verification result is compared with the running result of the hardware floating-point IP core to verify that the library file's support for different floating-point format parameter configurations is consistent with that of the hardware floating-point IP core.

8. A floating-point arithmetic algorithm verification system, characterized in that, The computer includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the floating-point arithmetic algorithm verification system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on a computer, the floating-point arithmetic algorithm verification system performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on a computer, the floating-point arithmetic algorithm verification system performs the method as described in any one of claims 1-7.

Images