Methods for compiling DPI functions into synthesizable languages, simulation methods, and systems.
By compiling the DPI function into a synthesizable language and converting it into a netlist, the problem that FPGA synthesis tools cannot synthesize DPI functions is solved, enabling effective communication between hardware and software co-simulation and improving the efficiency of chip development and simulation verification.
Patent Information
- Application Number
- CN202111250171.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-10-26
- Publication Date
- 2025-12-02
- Estimated Expiration
- 2041-10-26
AI Technical Summary
Existing FPGA synthesis tools cannot synthesize System Verilog's DPI function into hardware circuits, resulting in ineffective communication during software-hardware co-simulation.
The DPI function is compiled into a synthesizable language and then converted into a netlist by an FPGA synthesizer to enable communication between the hardware and software.
It enables effective communication between hardware and software, improving the speed of chip development and simulation verification.
Smart Images
Figure CN114036877B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of hardware-software co-simulation, and in particular to a method for compiling DPI functions into a synthesizable language, and a method and system for implementing hardware-software co-simulation using the method of compiling DPI functions into a synthesizable language. Background Technology
[0002] When chips are small, comprehensive simulation of chip functions is performed using chip software simulation, followed by verification of specific functions using chip prototypes, which can meet the development needs of some chips. However, as chip sizes increase, the time consumed by traditional chip simulation and verification methods accounts for an increasingly larger proportion of chip development time. To address this issue, a more suitable approach is to use simulation accelerators (Emulation). There are two main implementation methods for simulation accelerators: one is based on a dedicated processor, and the other is implemented using an FPGA. The FPGA-based method involves hardware and software co-simulation technology.
[0003] One challenge in chip hardware-software co-simulation is the communication between the hardware and software. The SCE-MI 2 protocol proposes a simple communication method using SystemVerilog's DPI (Direct Program Interface) functions, which allow SystemVerilog and C languages to directly call each other. This works well in software simulation because it doesn't require actual circuits but rather simulates them. However, in a hardware-software co-simulation environment, the hardware needs to be implemented as hardware circuits. Existing FPGA synthesis tools for implementing hardware circuits can only synthesize synthesizable description languages; they cannot synthesize behavioral description languages like DPI functions into netlists, preventing the hardware and software sides from communicating using DPI functions. Summary of the Invention
[0004] To address the technical problem of existing technologies where hardware and software cannot communicate using DPI functions, this invention proposes a method, simulation method, and system for compiling DPI functions into a synthesizable language. The method for compiling DPI functions into a synthesizable language is applied to a hardware-software co-simulation system. The synthesizable language corresponding to the compiled DPI function is then synthesized and analyzed into a netlist using FPGA synthesis tools. After the netlist is implemented on the FPGA, hardware and software can communicate and be simulated using DPI functions.
[0005] The method for compiling DPI functions into a synthesizable language proposed in this invention includes:
[0006] Based on the type of the DPI function on the software side, the DPI function on the software side is compiled into a low-level communication function that can be called by the software side to communicate with the hardware side, so as to realize the software side sending and / or receiving data to the hardware side.
[0007] Modify the hardware-side code according to the type of the DPI function on the hardware side, so that the DPI function becomes a channel that can send and / or receive data.
[0008] Furthermore, when the hardware-side DPI function includes a one-way import DPI function, the import DPI function is compiled into a data trigger signal, or a data trigger signal and a data signal statement.
[0009] Furthermore, when the hardware-side DPI function is a bidirectional import DPI function, the always statement block containing the import DPI function is copied to obtain two always statement blocks.
[0010] Remove the timing clock and assignment statement from one of the always statements, and add the data statement to be sent to the software and the trigger signal statement to send the data;
[0011] Replace the timing clock of another always block with a controllable clock, and compile the statements reserved in the always block into data trigger signals, or data trigger signals and data signal statements, and wait for the data returned by the receiving software.
[0012] Furthermore, when the hardware-side DPI function is the export DPI function, the export DPI function is directly replaced with an always statement block for compilation. Then, the always statement block is driven by an uncontrollable clock to receive data from the software side, or the received data is processed by the entity of the hardware-side export DPI function before the calculation result is sent to the software side.
[0013] Furthermore, when the DPI function on the software side includes an import function, a thread is created on the software side for the function entity corresponding to each DPI function. The thread is used to call the underlying communication function between the software side and the hardware side, so that the DPI function on the hardware side and the function entity on the software side can communicate with each other.
[0014] Furthermore, the calls to the underlying communication functions between the software and hardware sides using the aforementioned thread include:
[0015] Create the input parameter variables for the corresponding function entity within the thread;
[0016] The thread assigns a value to the input parameter variable of the input function in the underlying communication function that receives data from the hardware side;
[0017] And / or the thread uses the output of the function entity as the input parameter variable of the output function in the underlying communication function that sends data to the hardware side.
[0018] The hardware-software co-simulation method proposed in this invention includes:
[0019] Add a DPI function on the hardware side and add a corresponding DPI function on the software side.
[0020] The method described above for compiling DPI functions into a synthesizable language is used to compile both the software and hardware sides, thereby converting the hardware-side DPI functions into a synthesizable language.
[0021] Use an FPGA synthesizer to convert the synthesizable language corresponding to the DPI function on the hardware side into a netlist;
[0022] Then, the netlist corresponding to the DPI function on the hardware side is implemented in the circuit, so that the software side and the hardware side can communicate through the corresponding DPI function to achieve joint simulation.
[0023] The system proposed in this invention, which employs the aforementioned hardware and software co-simulation method, includes:
[0024] Located on the software side are test scripts written in software, DPI functions, and low-level communication functions that communicate with the hardware side;
[0025] The circuit under test is located on the hardware side, the interface circuit is formed by the DPI function, the data transmission module communicates with the software side, and the controllable clock generation circuit is used to generate the clock.
[0026] Furthermore, the underlying communication functions include at least one of a send API function and a receive API function.
[0027] Furthermore, the data transmission module includes at least one of a data receiving control circuit and a data sending control circuit.
[0028] Furthermore, the underlying communication functions and data transmission module communicate via any one of the following methods: PCIe, Ethernet, USB, CXL, parallel port, and PCI.
[0029] This invention converts DPI functions into a synthesizable language, enabling communication between hardware and software via DPI functions. The implementation is very simple: the non-synthesizable behavioral description language System Verilog's DPI interface functions are compiled into synthesizable HDL. This invention allows simulation code to be programmed into FPGAs, accelerating simulation. Furthermore, simulation code can be written using the behavioral description language of System Verilog, eliminating the need for the strictly formatted synthesizable HDL, significantly speeding up chip development and simulation verification. Attached Figure Description
[0030] The present invention will now be described in detail with reference to the embodiments and accompanying drawings, wherein:
[0031] Figure 1 This is a partial code diagram of an embodiment of the present invention before compilation.
[0032] Figure 2 yes Figure 1 A partial diagram of the compiled code.
[0033] Figure 3 This is a schematic diagram of the clock control of the present invention.
[0034] Figure 4 This is a schematic diagram of the simulation system framework of the present invention.
[0035] Figure 5 This is a partial code diagram of another embodiment of the present invention before compilation.
[0036] Figure 6 yes Figure 5 A partial diagram of the compiled code. Detailed Implementation
[0037] To make the technical problems to be solved, the technical solutions, and the beneficial effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.
[0038] Therefore, a feature pointed out in this specification is used to describe one feature of one embodiment of the invention, and does not imply that every embodiment of the invention must have the described feature. Furthermore, it should be noted that this specification describes many features. Although certain features may be combined to illustrate possible system designs, these features may also be used in other combinations not explicitly stated. Therefore, unless otherwise stated, the described combinations are not intended to be limiting.
[0039] The principles of the present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0040] This invention provides a method for compiling DPI functions into a synthesizable language, including both hardware-side and software-side compilation, with a focus on hardware-side compilation. System Verilog defines two types of DPI functions: one where System Verilog calls a C / C++ function (i.e., the `import DPI` function); and another where System Verilog implements a function and C / C++ calls it (i.e., the `export DPI` function). By using DPI functions, System Verilog and C / C++ can communicate directly. Most current software simulators support mutual calls between these two languages. This invention implements a method for using DPI functions in hardware-software co-simulators, which greatly facilitates the development of hardware-software communication code, allowing software and hardware to communicate by calling DPI functions.
[0041] To enable communication between hardware and software using DPI functions, the hardware-side DPI functions need to be converted into hardware circuits, and the software-side DPI functions need to be converted into driver functions for communication with the hardware. The difficulty lies in converting the hardware-side DPI functions into hardware circuits because DPI functions cannot be converted into hardware circuits using FPGA synthesis software. FPGA synthesis software can only convert synthesizable code into netlists, not behavioral description language (DPI) functions. This invention, however, can convert DPI functions into a synthesizable language, allowing the synthesizable DPI functions to be further converted into netlists using an FPGA synthesizer. Finally, the netlist can be implemented into circuits using FPGA place-and-route software, thus converting DPI functions into circuits.
[0042] This invention compiles the software-side DPI function into a low-level communication function that can be called by the software to communicate with the hardware, based on the type of the software-side DPI function, enabling the software to send and / or receive data to the hardware. Simultaneously, the hardware-side code is modified according to the type of the hardware-side DPI function, making the DPI function a channel for sending and / or receiving data.
[0043] The aforementioned DPI functions include one-way import DPI functions, two-way import DPI functions, one-way export DPI functions, and two-way export functions. When the hardware side contains an import DPI function, it means that the corresponding function entity is on the software side and is called by the hardware side. When the hardware side contains an export DPI function, the corresponding function entity is on the hardware side, and the software side needs to call the function entity on the hardware side.
[0044] The following describes how to compile the import DPI function into a synthesizable language.
[0045] When the hardware side contains a one-way DPI import function (meaning the hardware side only sends data to the software side), the one-way DPI import function should be compiled into a data trigger signal, or a data trigger signal and data signal statement. When the hardware side's DPI import function has no input or output, such as `void DPI Function(void)`, meaning the hardware side simply calls the software side's DPI function entity, the DPI import function should be directly replaced with a data trigger signal. When the hardware side's DPI import function has output, meaning it needs to send data to the software side, the hardware side needs to send data to the software side only when the condition in its corresponding `always` block is met (i.e., when the hardware side's DPI import function is called). Therefore, the hardware side's DPI import function needs to be replaced with a data trigger signal and data signal statement. This compilation method does not change other logic code designed by the user; it only modifies the DPI function. The following is a simple example to illustrate this. Figure 1 The design code on the hardware side before compilation is compiled into... Figure 2 The compiled code ensures consistency of logical functionality before and after compilation. This type of code typically translates software transactions into clock-precise logical functions, hence the name "transaction handler." When the compiler detects an import of a DPI function (i.e., a software function imported into the hardware), it directly replaces the DPI function with a data trigger signal (i_receive_trigger = ~i_receive_trigger) and a data statement (destAddr = o_receive_data). The purpose of the trigger is to ensure that the trigger inverts once each time the DPI function is triggered. Figure 2 In this configuration, `i_receive_trigger = ~ i_receive_trigger`. This allows subsequent circuitry to retrieve data from the software side and store it in the `data` block when the trigger signal inverts. The `data` block then transmits the data to the hardware side as user data signals. This is implemented using data signal statements. Figure 2 In this context, `destAddr = o_receive_data` is used. The function of `Data` is to transfer the data sent from the software (the output data of the `import DPI` function) to the user's logic signal (`destAddr`).
[0046] When the hardware contains a bidirectional `import DPI` function, meaning that the `import DPI` function needs to send data to the software first, and this data is processed on the software side before being passed to the hardware side, the compiler copies the `always` block containing the `import DPI` function, resulting in two `always` blocks. The timing clock and assignment statements in one of the `always` blocks are removed, and statements for sending data to the software and trigger signals for sending data are added to ensure data is sent to the software in advance. The timing clock in the other `always` block is replaced with a controllable clock, and the statements retained in the `always` block are compiled into data trigger signals, or data trigger signals and data signal statements, waiting to receive data returned from the software side.
[0047] The always block above, with the clock removed, will change from sequential logic to combinational logic. The characteristic of combinational logic is that it can complete the data calculation one cycle earlier than sequential logic. Therefore, the always block without the clock can send the data from the hardware side to the software side in advance. Figure 2 In this approach, the condition of the sequential logic always block containing the imported DPI function is retained, but the clock is removed, transforming it into combinational logic. This allows data to be sent one clock cycle earlier without altering the user logic functionality. However, this is far from sufficient because the time required for the hardware to send data to the software is relatively long. Replacing sequential logic with combinational logic, which is only one clock cycle faster, may result in the clock cycle ending before data transmission is complete, preventing the hardware from receiving the data processed by the software. Furthermore, the hardware receiving data from the software also consumes considerable time. However, the definition of the DPI function in Sistem Verilog does not consume any simulation time.
[0048] To solve this problem, pause the controllable clock in another always block. For example... Figure 3 As shown, after using a controllable clock to control the clock of the always block, by pausing the controllable clock, from the perspective of the controllable clock (cclock), the cycle of the controllable clock can be ignored because the controllable clock is paused during hardware-software communication. At this point, in order to control the controllable clock on or off, and to drive data communication between the hardware and software, another uncontrolled clock (uclock) is needed for transmission.
[0049] When the software side contains import DPI functions (one-way and / or two-way import DPI functions), a thread is created for each import DPI function. Within each thread, corresponding parameter variables for the import DPI function are created. Using the thread's calls to the underlying communication functions between the software and hardware sides, data received from the hardware side via PCIe is transferred to the input variables of the import DPI function within the thread (one-way import DPI function), or vice versa. The result of the import DPI function's operation is then sent back to PCIe, which in turn transmits it to the hardware side (two-way import DPI function). On the software side, DPI functions also need to be compiled. Since the hardware side cannot call the software-implemented import DPI functions, this invention addresses this by creating threads to call these DPI functions, transferring data from the hardware side to the software-side DPI function, and then transmitting the data from the software-side DPI function back to the hardware side. Therefore, the software-side compilation method involves retaining the original software-side DPI functions and creating a thread for each import DPI function. This thread enables communication between the software-side import DPI function entity and the hardware-side DPI function call circuitry, specifically through the PCIe send function (pcie_send_data) and the PCIe receive function (pcie_receive_data) to exchange data with the hardware. Figure 2 In the code, a parameter variable for the `import DPI` function is created in the thread. The data received from the PCIe is transferred to the input variable (destAddr) of the `DPI` function, and the result of the `DPI` function (`PortID(&destAddr)`) is sent to the PCIe. The code is as follows:
[0050] svBitVecVal32 destAddr;
[0051] destAddr = pcie_receive_data();
[0052] pcie_send_data(PortID(&destAddr )).
[0053] When the hardware contains an `export DPI` function, it is directly replaced with an `always` block during compilation. The `export DPI` function is implemented on the hardware side and called by the software side.
[0054] When the software side contains an export DPI function, since the function entity resides on the hardware side, the software side only needs to call the underlying communication function to receive data sent by the hardware side. Software-side export DPI functions can also be bidirectional or unidirectional. When a software-side export DPI function is unidirectional, it only sends data to the hardware side. When a software-side export DPI function is bidirectional, the data sent from the software side to the hardware side is processed by the hardware-side DPI function entity before the corresponding calculation result data is received.
[0055] The following explanation uses a simple example to illustrate this. Figure 5 The code is compiled before the hardware side is compiled into Figure 6 The compiled code ensures consistency of logical functionality before and after compilation. This type of code typically translates software transactions into clock-precise logical functions, hence the name "transactional code." When the compiler detects the hardware-side `export DPI` function, it directly replaces the `export DPI` function with an `always` block for compilation. Then, it uses a non-controllable clock to drive the `always` block to receive data from the software side, or it receives data, performs calculations on the hardware-side `export DPI` function, and then sends the result to the software side.
[0056] like Figure 6 As shown, the clock is triggered by the rising edge of the uclk clock, which is an uncontrollable clock. The always block sets the input variables of the exported DPI function from the uclk clock. Figure 4 The data transfer module in the middle retrieves data ({enableParity} = data_in, where data_in is driven by the data transfer module), and drives all the output data of the export function to... Figure 4 The data transmission module (data_out = {configParity}) drives the data transmission module. All content within the function body is placed between the two statements above to maintain the format.
[0057] The `export` DPI function does not require clock control and uses uclk as the driving function. Therefore, it does not need a trigger signal like the `import` function. When the software calls the `export` function, PCIe transmits the input parameter data to the hardware-side `data_in` after a certain period of time. The input signal of the `export` function can acquire data on the rising edge of uclk. At this time, the software-side `pci_send_data()` function exits, and the `pcie_receive_data()` function is executed sequentially. Since the hardware may not have acquired the data yet, the function will block. The hardware acquires the data on the same rising edge of uclk and transmits it to `data_out`. The data transmission module sends `data_out` to PCIe. The software-side `pcie_receive_data()` function receives the data and returns it to the user program, and the entire process ends.
[0058] Since the underlying communication functions and data transmission modules of this invention can communicate with each other through any of the following methods, such as PCI, Ethernet, USB, CXL, parallel port, PCI, etc., and are not limited to the above methods, as long as it is an interface that enables communication between the FPGA and the software side, the underlying communication functions are not limited to the pcie_receive_data() and pci_send_data() functions listed above. The specific function selected will vary depending on the communication method.
[0059] The hardware-software co-simulation method of this invention requires first adding DPI functions on both the software and hardware sides. Then, using the method described above, the hardware-side DPI functions are compiled into a synthesizable language. This converts the hardware-side DPI functions into a synthesizable language, which is then converted into a netlist using an FPGA synthesizer. Finally, the netlist corresponding to the hardware-side DPI functions is implemented in the circuit, enabling the software and hardware sides to communicate and achieve co-simulation through the corresponding DPI functions. The following example illustrates adding DPI functions on both the software and hardware sides. When the hardware side adds an `importDPI` function, the software side must add the corresponding DPI function entity. When the hardware side uses an `exportDPI` function, it indicates that the DPI function entity is on the hardware side, and the software-side `exportDPI` function will call the hardware-side DPI function entity.
[0060] like Figure 4As shown, the hardware-software co-simulation system of the present invention uses the aforementioned hardware-software co-simulation method for simulation. The system includes software-written test scripts, DPI functions, and low-level communication functions that communicate with the hardware side via PCIe, located on the software side. These low-level functions include at least one of a send API function and a receive API function.
[0061] The system also includes a design-under-test (DUT) circuit on the hardware side, an interface circuit formed by the DPI function, a data transmission module that communicates with the software side via PCIe, a controllable clock generation circuit for generating a clock, and a clock control circuit. The data transmission module includes at least one of a data receiving control circuit and a data sending control circuit. The controllable clock generation circuit generates a controllable clock; both the DUT and the interface circuit formed by the import DPI function use controllable clocks. Since the data transmission module uses a controllable clock on its right side, and its left side needs to communicate with the software side using an uncontrolled clock, the clock control circuit controls the switching of the clock generation circuit. It itself uses an uncontrolled clock and generates signals to supply the clock generation circuit with the clock signal. The control of the clock control circuit is determined by the data transmission status. When data transmission is required but cannot be performed, the clock must be turned off; otherwise, the clock must be turned on. If there are multiple channels, all clock control circuits must be turned on for the clock generation circuit to generate a clock, ensuring synchronization of all modules.
[0062] When the data transmission module calls the DPI function (i.e., uses the interface circuit formed by the DPI function), if the data transmission control circuit receives a reversed Trigger signal from the interface circuit (the interface circuit formed by the DPI function) generated after the compiler compiles the code, it considers the data valid. If PCIe can transmit data, the data is forwarded to the software side. If no data is needed, the process ends. If data needs to be returned, the data reception control circuit waits for the data to be returned and then forwards the data to the compiled interface circuit. During the transmission process, the clock control circuit needs to turn off the controllable clock.
[0063] After the compiler converts the hardware-side DPI function, the compiled code has two sets of interfaces: one is the data channel from the hardware side to the software side (such as a trigger signal and a set of data signals), and the other is the data channel from the hardware side to the software side (such as a trigger signal and a set of data signals). Since the conversion rules of this invention are relatively simple, the compiler can easily automate the compilation. The compiled code of the hardware-side DPI function is then synthesized to generate two sets of interfaces for the circuit. These interfaces are then connected to the data transmission module of the already developed system through the compilation tool. The underlying communication function on the software side passes the data sent by the hardware side to the corresponding DPI function. TestBench can communicate with the hardware-side DPI-converted circuit by calling the software-side DPI function.
[0064] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for compiling DPI functions into a synthesizable language, characterized in that, include: Based on the type of the DPI function on the software side, the DPI function on the software side is compiled into a low-level communication function that can be called by the software side to communicate with the hardware side, so as to realize the software side sending and / or receiving data to the hardware side. Modify the hardware-side code according to the type of the DPI function on the hardware side, so that the DPI function becomes a channel that can send and / or receive data. When the hardware-side DPI function includes a one-way import DPI function, the one-way import DPI function will be compiled into a data trigger signal, or a data trigger signal and a data signal statement. When the hardware-side DPI function includes a bidirectional import DPI function, the always statement block containing the bidirectional import DPI function is copied to obtain two always statement blocks. Remove the timing clock and assignment statement from one of the always statements, and add the data statement to be sent to the software and the trigger signal statement to send the data; Replace the timing clock of another always block with a controllable clock, and compile the statements reserved in the always block into data trigger signals, or data trigger signals and data signal statements, and wait for the data returned by the receiving software. When the hardware-side DPI function includes the export DPI function, the export DPI function is directly replaced with an always statement block for compilation. Then, the always statement block is driven by an uncontrollable clock to receive data from the software side, or the data is received and processed by the hardware-side export DPI function before the result is sent to the software side. When the DPI function on the software side includes an import function, a thread is created on the software side for the function entity corresponding to each DPI function. The thread is used to call the underlying communication function between the software side and the hardware side, so that the DPI function on the hardware side and the function entity on the software side can communicate with each other. The calls to the underlying communication functions between the software and hardware sides using the aforementioned thread include: Create the input parameter variables for the corresponding function entity within the thread; The thread assigns a value to the input parameter variable of the input function in the underlying communication function that receives data from the hardware side; And / or the thread uses the output of the function entity as the input parameter variable of the output function in the underlying communication function that sends data to the hardware side.
2. A method for hardware and software co-simulation, characterized in that, include: Add a DPI function on the hardware side and add a corresponding DPI function on the software side. The method described in claim 1 for compiling DPI functions into synthesizable languages is used to compile both the software and hardware sides, thereby converting the hardware-side DPI functions into synthesizable languages. Use an FPGA synthesizer to convert the synthesizable language corresponding to the DPI function on the hardware side into a netlist; Then, the netlist corresponding to the DPI function on the hardware side is implemented in the circuit, so that the software side and the hardware side can communicate through the corresponding DPI function to achieve joint simulation.
3. A system for simulation using the hardware-software co-simulation method described in claim 2, characterized in that, include: Located on the software side are test scripts written in software, DPI functions, and low-level communication functions that communicate with the hardware side; The circuit under test is located on the hardware side, the interface circuit is formed by the DPI function, the data transmission module communicates with the software side, and the controllable clock generation circuit is used to generate the clock.
4. The system as described in claim 3, characterized in that, The underlying communication functions include at least one of the send API function and the receive API function.
5. The system as described in claim 3, characterized in that, The data transmission module includes at least one of a data receiving control circuit and a data sending control circuit.
6. The system as described in claim 3, characterized in that, The underlying communication functions and data transmission module communicate with each other via any one of the following methods: PCIe, Ethernet, USB, CXL, parallel port, and PCI.