FPGA code function verification acceleration method

Abstract

Currently, complex FPGA designs typically contain multiple sub-modules below the top-level module. These modules ensure correct functional implementation, but because they are integral parts of the design, they are also subjected to gate-level behavioral simulation during simulation. If a module under test has one top-level module and nine sub-modules, seven of which are library or mature modules, and only two are newly designed modules, then only 30% of the gate-level behavioral simulation computation performed by EDA tools is truly for the part we want to verify. However, due to the existence of the top-level code and the need to verify the interface relationships between modules, the verification of sub-modules cannot replace the verification of the top-level module. If we could allow gate-level behavioral simulation to skip library and mature modules, it would significantly reduce the computational load of gate-level behavioral simulation and improve the speed of FPGA code functional simulation. This invention, for functional verification of FPGA code containing multiple sub-modules, uses a C model to replace the library IP modules or mature modules, preventing these modules from participating in the gate-level behavioral simulation during functional simulation execution, thereby significantly shortening the functional simulation execution time and accelerating the functional verification speed of FPGA code.

Description

Technical Field

[0001] This invention belongs to the field of FPGA functional verification, specifically involving a method for accelerating FPGA code functional verification based on a C language model. Background Technology

[0002] FPGA (Field Programmable Gate Array) code verification includes functional simulation before placement and routing, timing simulation after placement and routing, and hardware-software integrated testing after generating download files. Functional simulation, as the first step in FPGA code verification, needs to ensure the correct implementation of the FPGA code's functions. Its test cases need to cover all functional points and all operating scenarios. The test object can be a single FPGA module or a higher-level module containing multiple FPGA sub-modules. FPGA functional simulation generally uses EDA (Electronic Design Automation) simulation tools such as Modelsim and VCS for software simulation, executing simulation projects, and inputting test data and obtaining test results for the FPGA code under test. Since the principle of EDA simulation tools is to simulate the gate-level behavior of the FPGA code under test using software, the computational load is large. Especially when the FPGA code under test contains high-complexity calculations such as floating-point calculations, or when the FPGA code under test contains many sub-modules, its simulation speed will decrease significantly, making FPGA code functional simulation very time-consuming. Currently, complex FPGA designs typically contain multiple sub-modules below the top-level module. These include newly designed modules, various library IP (Intellectual Property) modules provided by FPGA vendors, and mature modules that have been thoroughly validated in previous development work. These modules ensure correct functional implementation, but because they are integral parts of the design, they are also subjected to gate-level behavioral simulation during simulation. If a module under test has one top-level module and nine sub-modules, seven of which are library or mature modules, and only two are newly designed modules, then only 30% of the gate-level behavioral simulation calculations performed by EDA tools are truly for the part we want to verify. However, due to the existence of the top-level code and the need to verify the interface relationships between modules, the verification of sub-modules cannot replace the verification of the top-level module. If we could allow gate-level behavioral simulation to skip library and mature modules, it would significantly reduce the computational load of gate-level behavioral simulation and improve the speed of FPGA code functional simulation. Summary of the Invention

[0003] To overcome the shortcomings of existing technologies, this invention proposes an accelerated method for FPGA code functional verification. When performing functional simulation of FPGA code with multiple sub-modules, the FPGA library IP modules and mature modules are replaced with functional models written in C language. These modules no longer participate in the gate-level behavior simulation during functional simulation, thereby effectively accelerating the software simulation speed and shortening the FPGA code functional simulation cycle. The method includes the following steps:

[0004] Step 1: Identify the FPGA submodule that needs to be replaced.

[0005] In simulation engineering, from the sub-modules below the top-level module of the FPGA under test, we select library IP modules provided by the FPGA manufacturer or mature modules that have been fully verified as the target modules to be replaced by the C language model.

[0006] Step 2: Create or obtain a C language model.

[0007] For the target module, create or obtain matching C language model code.

[0008] Step 3: Encapsulate the C language model into a DPI function and compile it into a DLL library.

[0009] The C language model is encapsulated as a DPI function and compiled into a DLL library, which can be directly called by the FPGA simulation project. The input and output interfaces adopt the DPI interface data type specified by the SV language. The DLL library is attached to the simulation project so that the C language model can be imported into the module written in the SV language.

[0010] Step 4: Import the DPI function and encapsulate it as an SV module.

[0011] Write an SV module with the same name as the target module, import the DPI function, and perform input / output interface matching, timing matching, and DPI function calls.

[0012] Step 5: Replace the target module in the simulation project with the SV module for simulation.

[0013] Remove the target module from the simulation project, add the corresponding SV module to the simulation project, link the DLL library in the simulation project, complete the modification of the simulation project, execute the simulation, and verify the functionality of the remaining parts that were not replaced.

[0014] The beneficial effects of this invention are as follows:

[0015] For functional verification of FPGA code containing multiple sub-modules, this invention uses a C language model to replace the library IP modules or mature modules, so that these modules do not participate in the gate-level behavior simulation during the functional simulation execution process, thereby significantly shortening the functional simulation execution time and accelerating the functional verification speed of FPGA code. Attached Figure Description

[0016] Figure 1 A diagram illustrating the implementation steps of a method to accelerate FPGA code functional verification.

[0017] Figure 2 FPGA code functional simulation engineering structure diagram for a 16K-point arithmetic module

[0018] Figure 3 FPGA code functional simulation engineering structure diagram of the modified 16K-point arithmetic module Detailed Implementation

[0019] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings.

[0020] This embodiment uses the Modelsim simulation tool to perform FPGA functional simulation, but it can also be applied to FPGA functional simulation under any EDA simulation tool.

[0021] Figure 2 A typical FPGA functional simulation project is shown, including:

[0022] Simulation project file 100 is used to set the index of the simulation code file and the FPGA code file under test, and to set simulation options.

[0023] The top-level module 101 of the simulation project is used to call the simulation sub-modules (source data generation module 102, source data driving module 103, result data acquisition module 104) and the module under test.

[0024] The source data generation module 102 is used to generate the source data required for simulation.

[0025] The source data driver module 103 is used to drive the source data to the module under test.

[0026] The result data acquisition module 104 is used to acquire the result data generated after the module under test runs.

[0027] The 16K-point arithmetic module 105, the module under test in this embodiment, comprises three sub-modules: a 16K-point FFT (Fast Fourier Transform) module 106, a 16K-point multiplication coefficient module 107, and a 16K-point IFFT (Inverse Fast Fourier Transform) module 108. The 16K-point FFT module 106 is a library IP module provided by Xilinx, and the 16K-point IFFT module 108 is a proven and mature module; both modules ensure correct functionality. The 16K-point multiplication coefficient module 107 is a newly designed module. The 16K-point arithmetic module 105 and the 16K-point multiplication coefficient module 107 are the modules of primary focus in this functional verification.

[0028] The following is the operation process:

[0029] Step 1: Identify the FPGA submodule to be replaced. In the simulation project, select from the submodules below the top-level module of the FPGA under test, either library IP modules provided by the FPGA manufacturer or mature modules that have been fully verified, as the target modules to be replaced using the C language model.

[0030] In this embodiment, it is confirmed that the 16K-point FFT module 106 is a library IP module provided by Xilinx, and the 16K-point IFFT module 108 is a mature module that has been verified. These two modules are selected as the target modules to be replaced by the C language model.

[0031] Step Two: Create or Obtain a C Language Model. For the target module, obtain the matching C language model code. For some library IPs, the FPGA vendor provides the corresponding C language model; for other modules, a matching C language model needs to be developed, or obtained from the internet or other channels.

[0032] The 16K-point FFT module 106 is a library IP module provided by Xilinx, which also provides a corresponding C language model. The 16K-point IFFT module is a proven and mature module, and its corresponding C language model was developed in-house.

[0033] Step 3: Encapsulate the C language model into DPI functions and compile it into a DLL library. The C language model cannot be directly called by the FPGA simulation project. Therefore, the C language model is encapsulated into DPI functions and compiled into a DLL, whose input / output interfaces use the DPI interface data types specified by SystemVerilog (SV language). The DLL library is then attached to the simulation project so that the C language model can be imported into the module written in SystemVerilog.

[0034] In this embodiment, the C language model function for FFT provided by Xilinx is encapsulated into the DPI function FFT_model. The self-developed C language model function for IFFT is also encapsulated into the DPI function IFFT_model. The DPI functions FFT_model and IFFT_model are compiled into two DLL libraries: FFT_model.dll and IFFT_model.dll.

[0035] Step 4: Import the DPI function and encapsulate it as an SV module. Write an SV module with the same name as the target module, import the DPI function, and perform input / output interface matching, timing matching, and DPI function calls.

[0036] In this embodiment, the DPI functions FFT_model and IFFT_model are encapsulated into SV modules xfft_v9_16k_sim_netlist.sv and ifft16k.sv, and it is ensured that the SV module name, interface form and timing are consistent with the target module being replaced.

[0037] Step 5: Replace the target module in the simulation project with the SV module, link the DLL library, and perform the simulation. Remove the target module from the simulation project and add the corresponding SV module to it. Link the DLL library in the simulation project to complete the modification. Then, you can start the simulation to verify the functionality of the remaining parts that were not replaced.

[0038] In this embodiment, the 16K-point FFT module 106 and 16K-point IFFT module 108 in the simulation project are replaced with 16K-point FFT SV modules and 16K-point IFFT SV modules, respectively. The Modelsim simulation project properties are set to link FFT_model.dll and IFFT_model.dll to the simulation project, allowing the SV code within the simulation project to access the two DPI functions, FFT_model and IFFT_model.

[0039] This completes the modification of the simulation project. The modified simulation project structure is as follows: Figure 3As shown, since C code calculations are used instead of HDL code gate-level simulations during simulation, the simulation speed is accelerated. In the actual simulation implementation of this embodiment, the Modelsim simulation project for functional simulation of the 16K-point arithmetic module 105 originally took 82 minutes to execute. After replacing the 16K-point FFT module 106 and the 16K-point IFFT module 108 with the 16K-point FFT SV module 109 and the 16K-point IFFTSV module 110, the execution time of the Modelsim simulation project was reduced to 3 minutes. It is evident that this invention has a significant effect on accelerating FPGA code functional simulation.

[0040] This invention is not limited to the specific embodiments described above, and various modifications and variations are possible. Any modifications, equivalent substitutions, or improvements made to the above embodiments based on the technical essence of this invention should be included within the scope of protection of this invention.

Claims

1. A method for accelerating FPGA code functional verification, characterized in that: Includes the following steps: Step 1: Identify the FPGA submodule that needs to be replaced. In simulation engineering, from the sub-modules below the top-level module of the FPGA under test, we select library IP modules provided by the FPGA manufacturer or mature modules that have been fully verified as the target modules to be replaced by the C language model. Step 2: Create or obtain a C language model For the target module, create or obtain matching C language model code; Step 3: Encapsulate the C language model into a DPI function and compile it into a DLL library. The C language model is encapsulated as a DPI function and compiled into a DLL library so that the FPGA simulation project can call it directly. The input and output interfaces adopt the DPI interface data type specified by the SV language. The DLL library is attached to the simulation project so that the C language model can be imported into the module written in the SV language. Step 4: Import the DPI function and encapsulate it as an SV module Write an SV module with the same name as the target module, import the DPI function, and perform input / output interface matching, timing matching, and DPI function calls; Step 5: Replace the target module in the simulation project with the SV module for simulation. Remove the target module from the simulation project, add the corresponding SV module to the simulation project, link the DLL library in the simulation project, complete the modification of the simulation project, execute the simulation, and verify the functionality of the remaining parts that were not replaced.

Images