CN117910398A - Method for simulating logic system design, electronic device and storage medium - Google Patents

Abstract

The present application provides a method for simulating a logic system design on a hardware simulation tool, comprising: compiling the logic system design to generate a first configuration file and a second configuration file respectively; configuring a first hardware resource of the hardware simulation tool according to the first configuration file to simulate the logic system design; obtaining a first snapshot of the simulation of the logic system design in a first clock cycle; configuring a second hardware resource of the hardware simulation tool according to the second configuration file to debug the logic system design; and restoring the logic system design to the first clock cycle on the second hardware resource according to the first snapshot.

Description

Method, electronic device and storage medium for designing simulation logic system

Technical Field

The present application relates to the field of chip verification technology, and in particular to a method, electronic device and storage medium for emulating logic system design.

Background technique

A hardware simulation tool (e.g., a prototype verification board or a hardware emulator) can prototype and debug a logic system design including one or more modules. The logic system design can be, for example, a design for an integrated circuit (Application Specific Integrated Circuit, ASIC) or a system-on-chip (SOC) for a specific application. Therefore, the logic system design tested in the simulation tool can also be called a design under test (DUT). The simulation tool can simulate the design under test through one or more configurable components (e.g., a field programmable gate array (FPGA)), including executing various operations of the design under test, thereby testing and verifying the functions of each module of the design under test before manufacturing. By connecting a variety of peripheral daughter cards to the simulation tool, the effect of the design under test and various peripherals running as a complete system can also be tested.

Hardware simulation tools may include, for example, prototype boards and hardware simulators. Typically, prototype boards focus on the overall operation of electronic systems, emphasize operation speed, and generally do not have debugging capabilities. Hardware simulators focus on the simulation of the chip design itself, emphasize debugging capabilities, but have slow operation speeds.

Summary of the invention

A first aspect of the present application provides a method for simulating a logic system design on a hardware simulation tool, comprising: compiling the logic system design to generate a first configuration file and a second configuration file respectively; configuring a first hardware resource of the hardware simulation tool according to the first configuration file to simulate the logic system design; obtaining a first snapshot of the simulation of the logic system design in a first clock cycle; configuring a second hardware resource of the hardware simulation tool according to the second configuration file to debug the logic system design; and restoring the logic system design to the first clock cycle on the second hardware resource according to the first snapshot.

A second aspect of the present application provides an electronic device, comprising: a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions so that the electronic device executes the method described in the first aspect.

A third aspect of the present application provides a non-transitory computer-readable storage medium, which stores a set of instructions for a computer, and when the set of instructions is executed, causes the computer to perform the method as described in the first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

FIG1 shows a schematic diagram of the structure of an exemplary host according to an embodiment of the present application.

FIG. 2 shows a schematic diagram of a simulation system according to an embodiment of the present application.

FIG. 3 is a schematic diagram showing a process of generating a configuration file according to an embodiment of the present application.

FIG. 4 shows a schematic diagram of configuring hardware simulation resources according to an embodiment of the present application.

FIG. 5 is a schematic diagram showing a process of debugging a logic system design according to an embodiment of the present application.

FIG. 6 is a schematic diagram showing another process of designing a debugging logic system according to an embodiment of the present application.

FIG. 7 shows a flow chart of a method for simulating a logic system design on a hardware simulation tool according to an embodiment of the present application.

Detailed ways

In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

It should be noted that, unless otherwise defined, the technical terms or scientific terms used in this application should be understood by people with ordinary skills in the field to which this application belongs. The words "first", "second" and similar words used in this application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Including" and similar words mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

As mentioned above, prototype verification boards and hardware emulators are both hardware simulation tools. They are similar at the hardware level. However, in actual use, prototype verification boards can continuously provide prototype simulation at a high running speed, but errors that occur during prototype simulation cannot be recorded and restored, let alone debugged. Hardware emulators can use triggers and other means to record and restore simulation errors, but the running speed is very slow, and the hardware emulator itself is very expensive.

In view of the above problems, the inventor of the present application attempts to provide a hardware simulation tool with both prototype verification capability and debugging capability. Usually, prototype verification and debugging cannot be performed simultaneously on a hardware device. At the same time, the hardware resources required for the prototype verification function are relatively few, while the hardware resources required for the debugging function are relatively many. If the hardware simulation tool provided by the present application uses the same hardware resources in two modes, it will cause a waste of hardware resources and greatly reduce the efficiency of the prototype verification mode. Therefore, how to ensure the overall operating speed of the hardware simulation tool as much as possible while supporting the prototype verification capability and the hardware simulation capability is a technical problem to be solved urgently.

In view of this, an embodiment of the present application provides a method for simulating a logic system design on a hardware simulation tool, which effectively improves the overall efficiency of the hardware simulation tool by providing different hardware resources to different operating modes of the hardware simulation tool.

FIG. 1 shows a schematic diagram of the structure of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running a simulation system. As shown in FIG. 1 , the host 100 may include: a processor 102, a memory 104, a network interface 106, a peripheral interface 108, and a bus 110. The processor 102, the memory 104, the network interface 106, and the peripheral interface 108 are connected to each other in communication within the electronic device through the bus 110.

The processor 102 may be a central processing unit (CPU), an image processor, a neural network processor (NPU), a microcontroller (MCU), a programmable logic device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the technology described in this application. In some embodiments, the processor 102 may also include multiple processors integrated into a single logical component. As shown in FIG. 1 , the processor 102 may include multiple processors 102a, 102b, and 102c.

The memory 104 may be configured to store data (e.g., instruction sets, computer codes, intermediate data, etc.). In some embodiments, the simulation test system for simulation test design may be a computer program stored in the memory 104. As shown in FIG. 1 , the data stored in the memory may include program instructions (e.g., program instructions for implementing the method for locating errors of the present application) and data to be processed (e.g., the memory may store temporary codes generated during the compilation process). The processor 102 may also access the program instructions and data stored in the memory, and execute the program instructions to operate on the data to be processed. The memory 104 may include a volatile storage device or a non-volatile storage device. In some embodiments, the memory 104 may include a random access memory (RAM), a read-only memory (ROM), an optical disk, a magnetic disk, a hard disk, a solid-state drive (SSD), a flash memory, a memory stick, etc.

The network interface 106 can be configured to provide communication with other external devices to the host 100 via a network. The network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, near field communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the above specific examples. In some embodiments, the network interface 106 can include any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc., in any combination.

The peripheral interface 108 can be configured to connect the host 100 to one or more peripheral devices to achieve information input and output. For example, the peripheral devices can include input devices such as a keyboard, a mouse, a touch pad, a touch screen, a microphone, and various sensors, and output devices such as a display, a speaker, a vibrator, and an indicator light.

The bus 110 may be configured to transmit information between various components of the host 100 (e.g., the processor 102, the memory 104, the network interface 106, and the peripheral interface 108), such as an internal bus (e.g., a processor-memory bus), an external bus (USB port, PCI-E bus), etc.

It should be noted that, although the above electronic device architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108 and the bus 110, in the specific implementation process, the electronic device architecture may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above electronic device architecture may also only include the components necessary for implementing the embodiment of the present application, and does not necessarily include all the components shown in the figure.

FIG. 2 shows a schematic diagram of a simulation system 200 according to an embodiment of the present application.

As shown in FIG. 2 , the simulation system 200 may include a simulation tool 202 and a host 100 connected to the simulation tool 202 .

The simulation tool 202 is a hardware system for simulating a design under test (DUT). The simulation tool 202 may be a prototype verification board or a hardware simulator (emulator). A design under test may include multiple modules. The design under test may be a combinational logic circuit, a sequential logic circuit, or a combination of the two. The simulation tool 202 may include one or more configurable circuits (e.g., FPGA) for simulating the design under test. It is understood that, although in FIG. 2 , the simulation tool 202 is shown as only one circuit board, in fact, the simulation tool 202 may include multiple circuit boards (e.g., multiple prototype verification boards or dual-mode verification boards).

The simulation tool 202 may include an interface unit 2022 for communicatively coupling with the host 100 to perform communication between the host 100 and the simulation tool 202. In some embodiments, the interface unit 2022 may include one or more interfaces with electrical connection capability. For example, the interface unit 2022 may include an RS232 interface, a USB interface, a LAN port, an optical fiber interface, an IEEE1394 (FireWire interface), etc. In some embodiments, the interface unit 2022 may be a wireless network interface. For example, the interface unit 2022 may be a WIFI interface, a Bluetooth interface, etc.

The host 100 may transmit the compiled DUT, debugging instructions, etc. to the simulation tool 202 via the interface unit 2022. The simulation tool 202 may also transmit simulation data, etc. to the host 100 via the interface unit 2022.

The simulation tool 202 may also include a memory 2024 for storing simulation data (e.g., various signal values) generated by the design under test during the simulation process. In some embodiments, the signal values generated by the design under test during the simulation process may be directly read by the host 100. It is understood that the memory 2024 may also be independent of the simulation tool 202, for example, using an external memory.

The simulation tool 202 may also include an FPGA 2026 for implementing the logic system design in hardware on the FPGA. It is understandable that the simulation tool 202 may include multiple FPGAs, which are only examples in the figure.

In addition to being connected to the host 100 , the emulation tool 202 may also be connected to one or more daughter cards 204 via an interface unit 2022 .

The daughter card is used to provide peripherals to the DUT to form a complete electronic system when using the simulation tool 202 for prototype verification. Prototype verification refers to a verification method that restores the actual use scenario of the chip as much as possible before the chip is taped out to verify whether the chip function is accurate and complete. The daughter card 204 can include a memory daughter card (for example, providing a DDR memory interface), a communication daughter card (for example, providing a variety of network interfaces or a wireless network card interface), etc.

The host 100 can be used to configure the simulation tool 202 to simulate a design to be tested. The design to be tested can be a complete logic system design or one or more modules of a complete logic system design. In some embodiments, the host 100 can be a virtual host in a cloud computing system. The logic system design (e.g., ASIC or System-On-Chip) can be designed by a hardware description language (e.g., Verilog, VHDL, System C, or System Verilog). The host 100 configuration simulation tool 202 may include configuring the simulation environment (e.g., the connection relationship between multiple simulation tools 202 or the connection relationship between the simulation tool and the daughter card), etc.

The host 100 may compile the logic system design in the form of source code into an executable file. From a design perspective, the logic system design may include a design to be tested and a test bench (Testbench) corresponding to the design to be tested. At this time, the compilation may cover the entire process from source code to an executable file (e.g., a bit file).

From the perspective of synthesis, the logical system design may include a synthesizable part and a non-synthesizable part. The synthesizable part usually corresponds to the actual physical design (e.g., a chip), while the non-synthesizable part usually includes an initialization module, a test bench, etc. The executable file formed by the non-synthesizable part after compilation can usually be run by the host 100. The synthesizable part also needs to be synthesized after compilation to form a bit file. The bit file can be used to configure the FPGA 2026 to run according to the design requirements of the synthesizable part.

The host 100 may also receive a request from a user to debug the design to be tested. As described above, the design to be tested may include one or more modules. The description of the design to be tested may be completed in a hardware description language. The host 100 may perform synthesis based on the description of the design to be tested to generate, for example, a gate-level circuit netlist (not shown) of the design to be tested. The gate-level circuit netlist of the design to be tested may be loaded into the simulation tool 202 for operation, and then a circuit structure corresponding to the design to be tested may be formed in the simulation tool 202. Therefore, the circuit structure of the design to be tested may be obtained according to the description, and accordingly, the circuit structure of each block in the design to be tested may also be obtained similarly.

FIG. 3 is a schematic diagram showing a process of generating a configuration file according to an embodiment of the present application.

As shown in FIG. 3 , the host 100 may compile a logic system design 302 (hereinafter also referred to as design 302) into a configuration file to configure hardware simulation resources on the simulation tool 202. The simulation tool 202 may be a HuaPro P2E simulation tool produced by Xinhuazhang Co., Ltd. It is understood that in some embodiments, the hardware simulation resources of the simulation tool 202 may include one or more FPGAs, and each FPGA may only simulate at least a portion of the logic system design (e.g., one or more modules). The simulation tool 202 may implement prototype verification functions and debugging functions.

For the same logic system design 302, due to the difference in environment variables and whether there is a debugging function, the configuration file may include a configuration file 304 and a configuration file 306 that are compiled and generated respectively. In some embodiments, the configuration files 304 and 306 may be binary files of the bit file type. Generally, one FPGA may correspond to one bit file, that is, the configuration file 304 or 306 may include one or more bit files.

Configuration file 304 corresponds to the prototype verification function, and configuration file 306 corresponds to the debugging function.

The prototype verification function may generally refer to a simulation function without debugging capability. For example, a user may implement a logic system design (e.g., a chip design) on a programmable logic device (e.g., FPGA 2026) of a hardware simulation tool 202, and connect one or more daughter cards (providing different peripheral functions) to the hardware simulation tool 202, thereby realizing a prototype of an entire electronic system. On this basis, the simulation of various functions of the logic system design under the prototype of the electronic system is completed by continuously providing test cases (e.g., providing stimuli) to the prototype of the electronic system. During the simulation process, the values of the logic system design in multiple clock cycles may be saved. For example, the values of the key signals of the logic system design in multiple clock cycles may be saved. The key signals of the logic system design refer to a portion of the signals that can be sufficient to restore the logic system design in the target clock cycle. The key signals may generally include the main inputs of the logic system design and at least a portion of the outputs of the registers. According to the values of the key signals and the description of the logic system design, the values of each signal of the logic system design may be calculated, and thus the logic system design may be restored to a given target clock cycle accordingly. For example, for a logic system design of C=A and B, A and B are key signals. Once the values of A and B are obtained, the value of C can be directly calculated based on the description of the logic system design (ie, C=A and B).

However, the prototype verification function usually cannot stop at a specific clock cycle or roll back to a given clock cycle according to the user's wishes, nor can it view the waveform of a given signal within a given clock cycle range.

Compared with the prototype verification function, the debugging function can stop the simulation of the logic system design at a specific clock cycle or roll back to a given clock cycle according to the user's wishes, or view the waveform of a given signal within a given clock cycle range, etc., thereby allowing the user to find the root cause of the error in the logic system design.

The implementation of debugging functions often relies on simulation data. That is, the user needs to first complete a simulation of the logic system design and obtain simulation data (for example, the values of key signals of the logic system design in multiple given clock cycles), and then rely on these simulation data to perform debugging functions during the debugging process.

The user can reflect a specific function (prototype verification function or debug function) in the configuration file by selecting the prototype verification function or the debug function when compiling and synthesizing the logic system design.

Corresponding to the prototype verification function, the configuration file 304 usually only needs to configure the generated logic system design on the FPGA 2026 and configure the connection relationship of the physical pins.

In contrast, the configuration file 306 may also include information for configuring the debugging function. In some embodiments, during the process of implementing the debugging function by the simulation tool 202, the user needs to observe and record the values of one or more key signals during the simulation process of the logic system design. The values of these key signals can be led to the interface 2022 via one or more pins specified in the configuration file 306 and transmitted to the host 100. Therefore, compared with the configuration file 304, the configuration file 306 needs to additionally configure the pins for reading the values of the key signals and the connection of these pins to the interface 2022 on the FPGA 2026. In addition, in some embodiments, the configuration file 306 also needs to configure and generate a small CPU on the FPGA 2026 for processing debugging functions such as triggering.

It is understandable that the configuration file 306 may include more debugging functions and is not limited to the above examples.

It can be seen that compared with configuration file 304, configuration file 306 needs to configure more functions and modules on FPGA 2026, which will cause the running speed of the hardware simulation tool configured via configuration file 306 to be significantly lower than that of the hardware simulation tool configured via configuration file 304.

For common hardware emulators that focus on debugging, the speed of running logic system design is relatively slow (for example, several hundred kHz or about 1MHz) due to the drag of debugging functions. Although the prototype verification board that focuses on prototyping functions can run at a faster speed (for example, up to 10MHz), the prototype verification board cannot support debugging functions.

How to support both prototype verification and debugging functions on a hardware simulation tool and improve the operating frequency of simulation logic system design is a technical problem that needs to be solved urgently.

FIG. 4 shows a schematic diagram of configuring hardware simulation resources according to an embodiment of the present application.

The simulation tool 202 usually has enough hardware resources to complete the prototype verification function or the debugging function. The hardware resources usually include at least one of one or more programmable logic devices (e.g., FPGA), configurable interfaces, or one or more daughter cards. The amount of hardware resources can be measured by the number of programmable logic devices (e.g., the number of equivalent gate circuits), the number of configurable interfaces, and the number of daughter cards.

When the simulation tool 202 performs prototype verification on the design 302, the host 100 can call the configuration file 304 to configure the hardware simulation resource 410. As shown in FIG4, the hardware simulation resource 410 may include one or more programmable logic devices (e.g., FPGA 401-404). When the simulation tool performs debugging on the design 302, the host 100 can call the configuration file 306 to configure the hardware simulation resource 420. As shown in FIG4, the hardware simulation resource 420 may include one or more programmable logic devices (e.g., FPGA 401-408).

In some embodiments, the hardware simulation resources may also include hardware devices connected to the simulation tool 202, such as peripheral daughter cards.

Generally, since the debugging function needs to process and save more signals, the resource amount of the hardware emulation resource 420 is greater than or equal to the resource amount of the hardware emulation resource 410 .

FIG. 5 is a schematic diagram showing a process 500 of debugging a logic system design 302 according to an embodiment of the present application.

When prototyping the logic system design 302, the host 100 can set a restore point at a specific clock cycle. The restore point can include a given clock cycle or an erroneous clock cycle. In some embodiments, the user can set certain clock cycles as restore points. In other embodiments, the host 100 can save the clock cycle in which the error message appears during the prototype verification process as a restore point. The restore point includes the simulation clock cycle that requires the simulation tool 202 to perform subsequent debugging. Examples of restore points are not shown in this application. The following description assumes the same restore point a, that is, clock cycle a.

As shown in FIG. 5 , the design 302 may include multiple modules, for example, module A. A signal 502 at an output port of module A may be a key signal of the logic system design 302 .

As shown in FIG5 , when the simulation tool 202 performs prototype verification on the logic system design 302, the host 100 may call the configuration file 302 to configure the hardware simulation resource 410. In clock cycle a, the simulation tool 202 and the host 100 may obtain the signal value of the first physical signal (e.g., physical signal 501) corresponding to the critical signal on the hardware simulation resource 410 in clock cycle a. According to the configuration file 304 and the logic system design 302, the host 100 may determine the first mapping 510 from the design 302 to the hardware simulation resource 410. The first mapping 510 includes at least a mapping relationship between the critical signal 502 of the design 302 and the physical signal 501 of the FPGA 401. The host 100 may save the value of the physical signal 501 in clock cycle a to a snapshot (not shown). The snapshot is generally a database (e.g., a waveform database). In an embodiment of the present application, the snapshot may include the signal value of the physical signal corresponding to the critical signal in the hardware simulation resource 410 at the restore point (i.e., clock cycle). In other embodiments, the snapshot may also include signal values of key signals of the logic system design at the restore point (ie, clock cycle).

According to the signal value of the first physical signal and the description of the logic system design (e.g., configuration file or netlist, etc.), the host 100 can determine the signal value of the key signal of the logic system design. For example, the host 100 can determine the first mapping 510 between the key signal 502 of the logic system design and the physical signal 501 according to the logic system design 302 and the configuration file 304; and determine the value of the key signal 502 of the logic system design corresponding to the physical signal 501 of the hardware resource 410 in clock cycle a according to the snapshot (not shown) and the first mapping 510.

In some embodiments, as shown in FIG5 , the first mapping 510 may include a mapping relationship between the critical signal 502 and the physical signal 501. The simulation tool 202 and the host 100 save the signal value of the physical signal 501 at the restore point a (i.e., a given clock cycle a) to a snapshot (not shown). Based on the first mapping 510 and the snapshot (not shown), the host 100 may determine the signal value of the critical signal 502 at the restore point a (i.e., clock cycle a) in the design 302 corresponding to the physical signal 501. It is understood that the snapshot (not shown) may also include the signal value of the critical signal 502 at the restore point a (i.e., clock cycle a).

When the simulation tool 202 starts to debug the logical system design 302, the host 100 can call the configuration file 306 to reconfigure the hardware simulation resources 420. According to the configuration file 306 and the logical system design 302, the host 100 can determine the second mapping 520 from the design 302 to the hardware simulation resources 420. The second mapping 520 includes at least a mapping relationship between the key signal 502 of the design 302 and the physical signal 503 of the FPGA 403.

In the above embodiment, as shown in FIG5 , according to the value of the key signal 502 at clock cycle a and the second mapping 520, the host 100 can determine the signal value of the physical signal 503 of the hardware simulation resource 420 at clock cycle a. More specifically, according to the second mapping 520, the host 100 can obtain the signal value of the physical signal 503 of the FPGA 403 on the hardware simulation tool 420 at clock cycle a by using the signal value of the key signal 502 of the design 302 at clock cycle a. In this way, the host 100 can use the signal value of the physical signal 503 at clock cycle a to initialize the physical signal 503, so that the logical system design 302 on the hardware simulation resource 420 is restored to clock cycle a.

In summary, the embodiments of the present application provide different configuration files for the prototype verification function and debugging function of the hardware simulation tool to configure different hardware resources, thereby speeding up the prototype verification of the hardware simulation tool while retaining the debugging capability of the hardware simulation tool, thereby improving the operating efficiency of the hardware simulation tool in simulating the logic system design.

FIG. 6 is a schematic diagram showing another process 600 of debugging the logic system design 302 according to an embodiment of the present application.

In some embodiments, as shown in FIG6 , the simulation tool 202 can perform prototype verification on the logic system design 302 on the hardware simulation resource 410. The configuration file of the hardware simulation resource 410 is not shown in FIG6 . The mapping 612 of the logic system design 302 to the hardware simulation resource 410 may include a mapping relationship of the key signal 603 to the physical signal 601 of the FPGA 401 and a mapping relationship of the key signal 604 to the physical signal 602 of the FPGA 404. According to the mapping 612 and the signal values of the physical signal 601 and the physical signal 602 in the clock cycle a, the host 100 can determine the signal values of the key signal 603 and the key signal 604 in the clock cycle a.

In some embodiments, the amount of resources of the simulation tool 202 originally used for prototyping the logic system design 302 is insufficient to implement the logic system design 302 with the debugging function. At this time, the host 100 can divide the logic system design 302 into multiple parts, select the debugging function and compile a part of the logic system design 302 to generate a new configuration file, so as to complete the debugging of the part on the simulation tool 202. The host 100 can determine that the amount of resources of the simulation tool 202 does not meet the needs of the debugging function, and as shown in FIG6, divide the logic system design 302 into a sub-design 312 and a sub-design 322. The output signal of the module B of the sub-design 312 is, for example, a key signal 602, and the output signal of the module C of the sub-design 322 is, for example, a key signal 604. The host 100 can implement the sub-design 312 on the hardware simulation resource 620 and debug it, and implement the sub-design 322 on the hardware simulation resource 630 and debug it. In this way, a mapping 622 from sub-design 312 to the actual circuit on hardware simulation resource 620 and a mapping 632 from sub-design 322 to the actual circuit on hardware simulation resource 630 are generated. In some embodiments, mapping 622 may include a mapping relationship between key signal 603 and physical signal 605 of FPGA 641; mapping 632 may include a mapping relationship between key signal 604 and physical signal 606 of FPGA 651.

According to the mapping 622 and the signal value of the key signal 603 at the clock cycle a, the host 100 can obtain the signal value of the physical signal 605 at the clock cycle a to initialize the physical signal 605, and finally initialize a part of the logic system design 302 (i.e., the sub-design 312) to the clock cycle a. Similarly, according to the mapping 632 and the signal value of the key signal 604 at the clock cycle a, the host 100 can obtain the signal value of the physical signal 606 at the clock cycle a to initialize the physical signal 606, and finally initialize another part of the logic system design 302 (i.e., the sub-design 322) to the clock cycle a.

In this way, by segmenting the logic system design during the debugging phase, not only the problem of insufficient hardware resources of the simulation tool is solved, but also the verification task of the complex logic system design can be segmented into multiple subtasks and debugged on hardware tools with lower specifications. At the same time, since the cost of hardware simulation tools loaded with a large number of FPGAs is high, the embodiments of the present application reduce the demand for high-performance hardware tools by debugging on hardware tools with lower specifications, thereby reducing the cost for users.

In summary, this application provides different configuration files for the prototype verification function and debugging function of the hardware simulation tool to configure different hardware resources, thereby speeding up the prototype verification of the hardware simulation tool, while retaining the debugging ability of the hardware simulation tool, thereby improving the operating efficiency of the hardware simulation tool in simulating the logic system design. This application also solves the problem of insufficient hardware resources that may exist in the simulation tool by segmenting the logic system design and then verifying or debugging it, and also simplifies the complex and numerous verification tasks, reduces the simulation tasks of the simulation tool, and speeds up the efficiency of the simulation system. At the same time, since the development cost of hardware simulation tools loaded with a large number of FPGAs is high, the simulation cost is greatly solved by segmenting the logic system design and then using hardware simulation tools with smaller resources for simulation.

The embodiment of the present application also provides a method for simulating a logic system design on a hardware simulation tool.

Fig. 7 shows a flow chart of a method 700 for simulating a logic system design on a hardware simulation tool according to an embodiment of the present application, wherein the method 700 may be executed by the host 100 shown in Fig. 2. The method 700 may include the following steps.

In step 701 , the host 100 may compile the logic system design (eg, the logic system design 302 in FIG. 3 ) to generate a first configuration file (eg, the configuration file 304 in FIG. 3 ) and a second configuration file (eg, the configuration file 306 in FIG. 3 ), respectively.

The first configuration file corresponds to a prototype verification function of the logic system design, and the second configuration file corresponds to a debugging function of the logic system design.

In some embodiments, in response to selecting the prototype verification function, the host 100 can compile the logic system design in combination with the prototype verification function to generate the first configuration file; in response to selecting the debug function, the host 100 can compile the logic system design in combination with the debug function to generate the second configuration file.

In step 702, the host 100 may configure the first hardware resource (the hardware simulation resource 410 of FIG. 4 ) of the hardware simulation tool (e.g., the hardware simulation tool 202 of FIG. 2 ) according to the first configuration file (e.g., the configuration file 304 of FIG. 3 ) to simulate the logic system design (e.g., the logic system design 302 of FIG. 3 ).

In step 703 , the host 100 obtains a first snapshot (not shown) of the simulation of the logic system design (eg, the logic system design 302 in FIG. 3 ) in a first clock cycle (eg, the above-mentioned clock cycle a).

In some embodiments, the first snapshot includes a value of a first physical signal (eg, physical signal 501 in FIG. 5 ) on the first hardware resource (eg, hardware emulation resource 410 in FIG. 5 ) in the first clock cycle.

In some other embodiments, in addition to the value of the physical signal in the first clock cycle, the first snapshot further includes the value of a key signal of the logic system design (eg, key signal 502 in FIG. 5 ) in the first clock cycle.

The first snapshot may be directly output by the hardware simulation tool 202 or the host 100 may obtain the value of the physical signal and then generate and store the value of the key signal. For example, the method 700 may further include: determining a first mapping (e.g., mapping 510 of FIG. 5 ) between the key signal of the logic system design and the first physical signal according to the logic system design and the first configuration file; determining the value of the key signal of the logic system design corresponding to the first physical signal of the first hardware resource in the first clock cycle according to the first snapshot and the first mapping.

In step 704 , the host 100 may configure a second hardware resource (eg, the hardware simulation resource 420 in FIG. 5 ) of the hardware simulation tool according to the second configuration file (eg, the configuration file 304 in FIG. 3 ) to debug the logic system design.

It is understandable that, since the debugging function occupies more hardware resources, the resource amount of the second hardware resource is greater than or equal to the resource amount of the first hardware resource. The resource amount of the hardware resource mentioned here may refer to the capacity of a programmable logic device, the number of hardware resources such as a subcard, etc. For example, the first hardware resource includes a programmable logic device.

In step 705 , the host 100 may restore the logic system design to the first time period on the second hardware resource (eg, the hardware simulation resource 420 in FIG. 5 ) according to the first snapshot.

In some embodiments, the host 100 may: determine, on the second hardware resource, a second physical signal (e.g., physical signal 503 of FIG. 5 ) corresponding to the critical signal (e.g., critical signal 502 of FIG. 5 ) and a second mapping between the critical signal and the second physical signal (e.g., mapping 520 of FIG. 5 ) based on the logical system design and the second configuration file (e.g., configuration file 304 of FIG. 3 ); and determine a value of the second physical signal in the first clock cycle based on the value of the critical signal in the first clock cycle and the second mapping.

In some embodiments, when the hardware simulation tool is not sufficient to support the logic system design with debugging function, the second configuration file may correspond to only a part of the logic system design.

Through the embodiments of the present application, the user can separate the prototype verification function and the debugging function, and use different configuration files in the prototype verification stage and the debugging stage, so that the hardware simulation tool can have a higher operating frequency in the prototype verification stage, while having the required debugging function in the debugging stage.

The embodiment of the present application also provides an electronic device. The electronic device may be the host 100 in FIG. 1 . The host 100 may include a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions so that the electronic device executes the method 700 .

The embodiment of the present application further provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores a set of instructions for a computer, and the set of instructions is used to enable the computer to perform method 700 when executed.

Some embodiments of the present application are described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the present application as described above, which are not provided in detail for the sake of simplicity.

Although the present application has been described in conjunction with specific embodiments of the present application, many alternatives, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.

This application is intended to cover all such substitutions, modifications and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application should be included in the scope of protection of this application.

Claims (10)

1. A method for simulating a logic system design on a hardware simulation tool, comprising: compiling the logic system design to generate a first configuration file and a second configuration file respectively; configuring a first hardware resource of the hardware simulation tool according to the first configuration file to simulate the logic system design; Acquire a first snapshot of the simulation of the logic system design at a first clock cycle; Configuring a second hardware resource of the hardware simulation tool according to the second configuration file to debug the logic system design; and The logic system design is restored to the first clock cycle on the second hardware resource according to the first snapshot. 2. The method of claim 1 , wherein the first configuration file corresponds to a prototype verification function of the logic system design, the second configuration file corresponds to a debugging function of the logic system design, and compiling the logic system design to generate the first configuration file and the second configuration file respectively further comprises: In response to selecting the prototype verification function, compiling the logic system design in conjunction with the prototype verification function to generate the first configuration file; and In response to selecting the debug function, compiling the logic system design in conjunction with the debug function to generate the second configuration. 3 . The method of claim 1 , wherein a resource amount of the second hardware resource is greater than or equal to a resource amount of the first hardware resource, and the first hardware resource comprises a programmable logic device. The method of claim 1 , wherein the first snapshot comprises a value of a first physical signal on the first hardware resource at the first clock cycle. 5. The method of claim 4, wherein the method further comprises: Determine a first mapping between a key signal of the logic system design and the first physical signal according to the logic system design and the first configuration file; A value of a key signal of the logic system design corresponding to a first physical signal of the first hardware resource in the first clock cycle is determined according to the first snapshot and the first mapping. 6 . The method of claim 4 , wherein the first snapshot further comprises a value of a critical signal of the logic system design at the first clock cycle. 7. The method of claim 5 or 6, wherein restoring the logic system design to the first clock cycle on the second hardware resource according to the first snapshot further comprises: Determining, on the second hardware resource according to the logical system design and the second configuration file, a second physical signal corresponding to the critical signal and a second mapping between the critical signal and the second physical signal; and The value of the second physical signal in the first clock cycle is determined according to the value of the key signal in the first clock cycle and the second mapping. 8. The method of any one of claims 1-6, wherein the second configuration file corresponds to a portion of the logical system design. 9. An electronic device for simulating a logic system design, comprising: a memory for storing a set of instructions; and At least one processor is configured to execute the set of instructions to perform the method according to any one of claims 1 to 8. 10. A non-transitory computer-readable storage medium storing a set of instructions for a computing device, the set of instructions being used to cause the computing device to execute the method according to any one of claims 1 to 8.