Circuit test method, device, equipment and medium

Abstract

The invention provides a circuit testing method and device, equipment and a medium. The method comprises the steps of obtaining a circuit file of a to-be-tested design; acquiring a plurality of test signals, the plurality of test signals including a first signal and a second signal, the first signal being a to-be-debugged signal in the to-be-tested design, and the second signal being a blank signal; generating an FPGA debugging file based on the circuit file and the plurality of test signals, wherein the plurality of test signals are connected with a plurality of probes in the FPGA debugging file; and running and verifying the FPGA debugging file.

Description

Technical Field

[0001] This disclosure relates to the field of circuit verification technology, and more specifically, to a circuit testing method, apparatus, equipment, and medium. Background Technology

[0002] Chip verification can be involved in the entire chip development process. Chip verification typically includes software verification and FPGA prototyping. Compared to software verification, FPGA prototyping is faster and can interface with real peripherals.

[0003] As chip design scale and complexity increase, chip verification time also becomes longer. Chip verification often involves the need for rapid iterative debugging of signals to pinpoint problems in chip engineering. Summary of the Invention

[0004] This disclosure provides a circuit testing method, apparatus, device, and medium that can reduce chip verification time.

[0005] According to a first aspect of this disclosure, a circuit testing method is provided, comprising: acquiring a circuit file of a design under test; acquiring a plurality of test signals, wherein the plurality of test signals includes a first signal and a second signal, the first signal being a signal to be debugged in the design under test, and the second signal being a blank signal; generating an FPGA debug file based on the circuit file and the plurality of test signals, wherein the plurality of test signals in the FPGA debug file are connected to a plurality of probes; and running and verifying the FPGA debug file.

[0006] In some embodiments, running and verifying the FPGA debug file includes: in response to an exception occurring during the running of the FPGA debug file, acquiring an updated signal to be debugged; connecting the updated signal to be debugged to a probe corresponding to the second signal; generating an updated FPGA debug file using incremental routing; and running and verifying the updated FPGA debug file.

[0007] In some embodiments, acquiring multiple test signals includes acquiring the multiple test signals from Register Transfer Language (RTL) statements or from an input device configuration (IDC) file.

[0008] In some embodiments, generating an FPGA debug file based on the circuit file and the plurality of test signals includes: generating a netlist based on the circuit file and the plurality of test signals; connecting the plurality of test signals to a plurality of probes; placement and routing; and generating the FPGA debug file.

[0009] In some embodiments, the method further includes segmenting the netlist.

[0010] In some embodiments, the number of the second signal exceeds a preset threshold.

[0011] According to a second aspect of this disclosure, a circuit testing apparatus is provided, comprising: a first acquisition module configured to acquire a circuit file of a design under test; a second acquisition module configured to acquire a plurality of test signals, wherein the plurality of test signals includes a first signal and a second signal, the first signal being a signal to be debugged in the design under test, and the second signal being a blank signal; a debug file generation module configured to generate an FPGA debug file based on the circuit file and the plurality of test signals, wherein the plurality of test signals in the FPGA debug file are connected to a plurality of probes; and a verification module configured to run and verify the FPGA debug file.

[0012] According to a third aspect of this disclosure, a chip verification apparatus is provided, comprising: at least one processor; and a memory for storing computer-executable instructions that, when executed, cause the at least one processor to perform the method according to the first aspect described above.

[0013] According to a fourth aspect of this disclosure, a computer-readable storage medium is provided having computer-executable instructions stored thereon for performing the method according to the first aspect above.

[0014] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in accordance with the first aspect above.

[0015] According to the circuit testing method, apparatus, device, and medium disclosed herein, a circuit file of the design under test (DUT) is obtained, and multiple test signals are acquired. These multiple test signals include debug signals and blank signals from the DUT. An FPGA debug file is generated based on the circuit file and the multiple test signals, and debugging is performed on this file. Because the debug file includes blank signals, when new debug signals need to be added during debugging, the new debug signals can be directly connected to the probes corresponding to the blank signals without going through the complete compilation process, thereby improving testing efficiency. Attached Figure Description

[0016] Other features and advantages of this disclosure will be better understood through the following detailed description of preferred embodiments in conjunction with the accompanying drawings, wherein the same reference numerals denote the same or similar parts.

[0017] Figure 1 A flowchart of an exemplary circuit testing method according to the prior art is shown.

[0018] Figure 2 A flowchart of an exemplary circuit testing method according to an embodiment of the present disclosure is shown.

[0019] Figure 3 A flowchart is shown of an exemplary method for running and verifying an FPGA debug file according to an embodiment of this disclosure.

[0020] Figure 4 A schematic diagram of an exemplary circuit testing apparatus according to an embodiment of the present disclosure is shown.

[0021] Figure 5 A schematic diagram of the structure of a circuit testing apparatus according to an embodiment of the present disclosure is shown. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions of this disclosure, the disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the disclosure.

[0023] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of the methods and systems according to various embodiments of this disclosure. It should be noted that the functions marked in the boxes may occur in a different order than that shown in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. Furthermore, in this disclosure, the terms "first," "second," etc., are used only for distinction and not for limiting the order of events, unless otherwise stated.

[0024] Chip verification can be conducted throughout the entire chip design process. Verification is used at various stages before tape-out to identify risks or errors in the chip design's concept, functionality, and implementation. Chip verification typically includes software simulation, hardware simulation, and FPGA prototyping verification. Different verification methods can be used depending on the stage of the design. For example, in the early stages of design, software simulation or hardware simulation is helpful in identifying design flaws. Software verification is suitable for high-precision verification, but it suffers from slow processing speed.

[0025] Field-Programmable Gate Array (FPGA) prototyping verifies chip functionality by porting Register Transfer Level (RTL) circuitry to the FPGA. RTL circuitry is a common hardware description level. RTL circuitry describes the behavior and structure of digital circuits and is represented using a register transfer level abstraction. RTL circuit descriptions are typically written using Hardware Description Languages ​​(HDLs). Designers can use RTL-level descriptions to define and implement the desired digital circuit functionality, and then use synthesis tools to translate the RTL-level description into a physical implementation in a Field-Programmable Gate Array (FPGA).

[0026] An FPGA is a reconfigurable integrated circuit chip with a wide range of applications. Unlike traditional fixed-function integrated circuits (ASICs), FPGAs can be flexibly reprogrammed and reconfigured according to user needs, adapting them to different applications and functions. An FPGA consists of a large number of programmable logic blocks and programmable interconnect resources. Programmable logic blocks typically consist of look-up tables (LUTs), registers, and other logic elements, capable of performing various logical functions. Programmable interconnect resources are used to connect logic blocks to form the required circuit structure. Using FPGAs, design engineers can describe the required circuit functions using hardware description languages ​​and translate them into a bitstream compatible with the FPGA chip using programming tools. FPGA prototyping allows for driver and application development after the chip's basic functionality has been verified, enabling the implementation of custom functions and algorithms at the hardware level without the need for traditional custom integrated circuit design and manufacturing processes, thus reducing chip design costs. Furthermore, FPGA prototyping offers advantages such as high operating speed and the ability to connect to external physical devices.

[0027] Currently, FPGA prototype verification uses a compilation method, and its process includes: reading in the design, synthesis, partitioning, placement and routing, generating download files, and debugging on the board. Figure 1 A flowchart of a prior art circuit testing method 10 is shown. Method 10 includes steps S11-S17.

[0028] In S11, the circuit file is obtained. This can be done by loading the circuit file to be verified into the client. The circuit file can be one or more of the following: RTL file, IP core file, constraint file, memory initialization file, and script file. As mentioned earlier, RTL circuit descriptions are typically written using a Hardware Description Language (HDL). HDLs include, for example, VHDL (VHSIC Hardware Description Language), Verilog HDL, and SystemVerilog HDL. The constraint file can include timing, pinout, and physical constraints.

[0029] In S12, the signal to be measured is acquired.

[0030] In some examples, you can select the signal you want to debug, i.e. the signal under test, using the RTL code viewer.

[0031] In S13, the synthesis.

[0032] In this step, the high-level abstraction RTL hardware description is converted into a low-level abstraction (logic gate level) netlist through logic synthesis. A netlist is a description method that uses basic logic gates to describe the connections of digital circuits. Because the array of logic gates has an appearance similar to a netlist, it is called a "netlist." Netlists typically convey information about circuit connections, such as instances of modules, nets, and related attributes.

[0033] In S14, insert the probe.

[0034] The acquired signal under test is associated or mapped with the probes on the FPGA prototype verification board.

[0035] In S15, layout and routing are performed.

[0036] In this step, the synthesized netlist is converted into a concrete physical implementation. During placement, the hardware primitives and low-level units from the netlist are rationally configured to specific locations on the FPGA chip. Placement includes global placement and detailed placement. During routing, based on the topology of the placement, various interconnect resources within the FPGA chip are used to rationally connect the various components. Routing includes full routing over long distances and local routing between adjacent logic units. In placement and routing, factors such as timing, area, and power consumption can be comprehensively considered to determine the placement and routing strategy.

[0037] In S16, generate debug files.

[0038] After placement and routing, timing analysis and optimization, physical constraints generation, bitstream generation configuration, and debug files, such as bit files, can be performed. Debug files contain information for programming and configuring the FPGA's internal logic and interconnect resources.

[0039] In S17, debug.

[0040] The host computer can be connected to the FPGA chip via JTAG, USB, or other cables, and the debug file can be downloaded to the FPGA chip using the hardware manager. Stimulus signals are applied to the FPGA chip, and the FPGA chip is run. The values ​​of the probe signals captured in real time can be compared with the expected results. If the comparison results are inconsistent, the debug loop is entered, for example, returning to the previous steps including locating the problem based on the waveform, modifying the RTL code or constraints, resynthesizing, place-and-route, and generating debug files.

[0041] In FPGA prototyping, the time required for a single synthesis and chip design implementation is becoming increasingly lengthy. Furthermore, probe insertion is typically done after synthesis; therefore, if new test signals need to be added during debugging, even minor modifications to the chip design necessitate re-running the entire compilation process, including the aforementioned steps S12-S16. For large-scale chip projects, the compilation process can take hours or even days, and the entire process consumes significant computing resources. As the scale and complexity of chip designs increase, existing chip verification methods cannot meet the need for rapid iterative debugging of signals to pinpoint problems in chip engineering.

[0042] To address the aforementioned problems, one embodiment of this disclosure provides a circuit testing method 20, such as... Figure 2 As shown. Method 20 includes steps S21-S24. Method 20 can be derived from... Figure 4 Circuit testing device 400 or Figure 5 The circuit testing equipment 500 in the middle is implemented.

[0043] In S21, obtain the circuit file of the design under test.

[0044] Electronic design automation (EDA) refers to the design process that utilizes computer-aided design software to complete the functional design, synthesis, verification, and physical design of very large-scale integrated circuit (VLSI) chips. Design Under Test (DUT) refers to the hardware design unit that is verified in the chip design process. DUT can be the entire chip or a portion of it. DUT may include multiple sub-modules and typically requires step-by-step verification.

[0045] Calls or loads the circuit file of the design under test that needs to be debugged and verified. The circuit file can be one or more of the following: RTL file, IP core file, constraint file, memory initialization file, and script file.

[0046] In S22, multiple test signals are acquired, including a first signal and a second signal. The first signal is the signal to be debugged in the design under test, and the second signal is a blank signal.

[0047] Multiple test signals include signals to be debugged and blank signals in the design under test (DUT). In some examples, the specific signals to be debugged can be determined based on the verification requirements of the DUT. The signals to be debugged in the DUT can be varied, including one or more of the following: control signals, interface signals, and critical path signals.

[0048] In some examples, multiple test signals can be obtained from RTL statements. Multiple test signals are defined in the RTL code, such as declared in the top-level module. Additionally, attributes can be added to prevent synthesis tools from optimizing these signals. Test signals can typically be declared using various RTL synthesis tools, such as Synplify or Protocomplier in HAPS, Vivado or ISE in Xilinx, and Quartus in Intel. In some examples, multiple test signals can be obtained from the Input Device Configuration (IDC) file.

[0049] In some examples, a large number of blank signals can be declared, meaning the number of second signals exceeds a preset threshold. Declaring a large number of blank signals in advance avoids the problem of insufficient debug interfaces when additional debug signals need to be added later. The preset threshold can be determined based on the actual situation, for example, more than two groups, such as four to five groups, totaling 64 bits.

[0050] In S23, an FPGA debug file is generated based on the circuit file and multiple test signals, where the multiple test signals are connected to multiple probes.

[0051] S23 is similar to S13-S16, including steps such as synthesis, probe insertion, placement and routing, and generating debug files.

[0052] In S24, run and verify the FPGA debug file.

[0053] Trigger conditions can be set according to requirements, and trigger signals can be captured. During the comparison process, the debugging success can be determined by comparing simulated waveforms or expected values. If successful, the debugging is complete. Otherwise, the previous steps can be returned to generate an updated FPGA debug file for continued debugging.

[0054] In method 20, the circuit file of the design under test (DUT) is obtained, along with multiple test signals. These test signals include the debug signals and blank signals from the DUT. An FPGA debug file is generated based on the circuit file and the multiple test signals, and debugging is performed on this file. Because the debug file includes blank signals, when new debug signals need to be added during debugging, they can be directly connected to the probes corresponding to the blank signals without going through the complete compilation process, thereby improving testing efficiency.

[0055] In some implementations, specifically, the step S23 of generating an FPGA debug file based on the circuit file and multiple test signals includes sub-steps S231-S234.

[0056] In S231, a netlist is generated based on the circuit file and multiple test signals. In FPGA debugging synthesis, the process of converting the high-level hardware description language (HDL) in the circuit file into a netlist is called synthesis. Specifically, the HDL code is converted into combinations of logic gates (e.g., AND, OR, NOT) and flip-flops (FF), the logic is mapped to the FPGA's physical resources, and a standard-format netlist file is output. Additionally, a netlist is generated based on the acquired circuit file and the declared multiple test signals during synthesis.

[0057] In S232, multiple test signals are connected to multiple probes. Based on S231, multiple test signals can be individually connected to or mapped to their corresponding probes.

[0058] In S233, layout and routing.

[0059] In some examples, the netlist can be segmented before placement and routing. Combinational logic alignment segmentation based on the input general gate netlist can yield an FPGA-specific netlist composed of LUTs, FFs, BRAMs, and DSPs.

[0060] In S234, FPGA debug files are generated.

[0061] In some implementations, when debugging fails, S24 running and verifying the FPGA debug file may include the following sub-steps S241-S243.

[0062] In S241, in response to an exception occurring during the execution of the FPGA debug file, an updated debug signal is obtained.

[0063] In S242, the updated signal to be debugged is connected to the probe corresponding to the second signal.

[0064] In S243, incremental routing is used to generate an updated FPGA debug file.

[0065] In S244, run and verify the updated FPGA debug file.

[0066] After the above steps, when additional debug signals need to be added, these debug signals are connected to the probes corresponding to the reserved blank signals and incremental routing is used, without having to retrace the entire process, thus reducing compilation time.

[0067] To better illustrate the process of running and verifying FPGA debug files, Figure 3 This is a flowchart illustrating a method 30 for running and verifying an FPGA debug file according to one embodiment of this disclosure. Method 30 includes steps S31-S36. Method 30 can be performed by... Figure 4 Circuit testing device 400 or Figure 5 The circuit testing equipment 500 in the middle is implemented.

[0068] In S31, generate FPGA debug files.

[0069] This step can be referenced. Figure 2 Step S23 in the process will not be described again here.

[0070] In S32, debug.

[0071] In step S33, it checks whether the debugging process passed, i.e., whether any exceptions occurred during the execution of the FPGA debug file. If so, the process ends. Otherwise, it proceeds to step S34.

[0072] In S34, in response to an exception occurring during the execution of the FPGA debug file, an updated debug signal is obtained.

[0073] In S35, the updated signal to be debugged is connected to the probe corresponding to the second signal. The second signal is a reserved blank signal. When a new debug signal needs to be added, the updated signal to be debugged can be associated or mapped to the probe corresponding to the blank signal.

[0074] In some examples, the updated signal to be debugged can be connected to the corresponding probe through the Engineering Change Order (ECO) process in Vivado.

[0075] In S36, incremental routing.

[0076] Unlike global routing, incremental routing rerouting only the problem area and its surroundings based on existing routing. Incremental routing typically involves steps such as identifying the problem area, reconnecting some existing routing, and locally rerouting. Incremental routing can significantly reduce compilation time and also facilitates rapid iterative debugging.

[0077] After incremental routing in S36, an updated FPGA debug file can be generated based on this, that is, return to step S31 and then execute the subsequent steps of method 30.

[0078] In Method 30, when additional debug signals need to be added, they only need to be connected to existing probes and routed incrementally, without having to go through the entire compilation process from scratch, which can significantly reduce testing efficiency. Method 30 can reduce debugging time from several hours to a few minutes to tens of minutes.

[0079] Figure 4 This is a schematic diagram of a circuit testing apparatus 400 according to one embodiment of the present disclosure. The circuit testing apparatus 400 includes modules 401-404.

[0080] The first acquisition module 401 is configured to acquire the circuit file of the design under test.

[0081] The second acquisition module 402 is configured to acquire multiple test signals, including a first signal and a second signal, wherein the first signal is a signal to be debugged in the design under test, and the second signal is a blank signal.

[0082] The debug file generation module 403 is configured to generate an FPGA debug file based on a circuit file and multiple test signals, in which multiple test signals are connected to multiple probes.

[0083] Verification module 404 is configured to run and verify the FPGA debug file. In some examples, verification module 404 is also configured to execute... Figure 3 Steps S32-S36 in the process.

[0084] In the circuit testing apparatus 400, the debug file generation module 403 generates an FPGA debug file based on the circuit file acquired by the first acquisition module 401 and multiple test signals acquired by the second acquisition module 402. The verification module 404 performs debugging based on this. Because the debug file includes blank signals, when additional debug signals are needed during debugging, the new debug signals can be directly connected to the probes corresponding to the blank signals without going through the complete compilation process, thereby improving testing efficiency.

[0085] It should be understood that the circuit testing apparatus 400 can be a physical device, a component of a physical device (e.g., an integrated circuit, a chip, etc.), or a functional module within a physical device. The modules of the circuit testing apparatus 400 can be implemented using software, hardware, or a combination of both.

[0086] Based on the same inventive concept, this disclosure also provides a circuit testing device that can integrate the above-mentioned circuit testing apparatus. Figure 5 A block diagram of an exemplary circuit testing apparatus 500 according to an embodiment of the present disclosure is shown. The circuit testing apparatus may be a physical device, a component of a physical device (e.g., an integrated circuit, a chip, etc.), or a functional module within a physical device.

[0087] like Figure 5 As shown, the circuit test apparatus 500 includes a processor 501. In one possible implementation, it may also include at least one communication interface 502, or the processor 501 and the communication interface 502 may be coupled. In yet another possible implementation, it may also include at least one memory 503, which may be integrated with the processor 501, discretely configured, or located outside the circuit test apparatus 500. It should be understood that this disclosure does not limit the number of processors and memories in the circuit test apparatus 500.

[0088] Processor 501 is a module for performing calculations and may include any one or more of the following: controller (e.g., memory controller), logic circuit, baseband processor, central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), digital signal processor (DSP), coprocessor (assisting the central processing unit in completing corresponding processing and applications), field programmable gate array (FPGA), application specific integrated circuit (ASIC), microcontroller unit (MCU).

[0089] Communication interface 502 is used to provide information input or output to at least one processor. In some examples, communication interface 502 can be used to receive data sent externally and / or send data externally. Memory 503 is used to provide storage space, in which application data, user data, operating system and computer programs, configuration files, etc., can be stored. Memory 503 may include volatile memory, such as random access memory (RAM). Memory 503 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0090] The circuit test equipment 500 may also include a bus 504. The communication bus 504 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus 504 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 504 may include a path for transmitting information between various components of the circuit test device 500 (e.g., memory 503, processor 501, communication interface 502).

[0091] In embodiments of this disclosure, memory 503 stores executable instructions, and processor 501 executes these executable instructions to implement the aforementioned method, for example... Figures 2-3 The methods described in the embodiments will not be repeated here. That is, the memory 503 stores instructions for performing the above methods.

[0092] Alternatively, the above methods can be implemented using a computer-readable storage medium. The computer-readable storage medium carries computer-readable program instructions for executing the various embodiments of this disclosure. The computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. The computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof.

[0093] Therefore, in another embodiment, this disclosure provides a computer-readable storage medium having computer-executable instructions stored thereon for performing the methods of various embodiments of this disclosure.

[0094] In one embodiment, this disclosure provides a computer program product including computer-executable instructions for implementing the methods in various embodiments of this disclosure.

[0095] Furthermore, although exemplary embodiments have been described herein, their scope includes any and all embodiments based on this disclosure that have equivalent steps, modifications, omissions, combinations (e.g., schemes involving overlapping embodiments), adaptations, or alterations. The steps in the claims are to be interpreted broadly based on the language used in the claims and are not limited to the examples described in this specification or during the implementation of this disclosure, which are to be interpreted as non-exclusive. Therefore, this specification and examples are intended to be considered illustrative only, and the true scope and spirit are indicated by the various claims in the claims and the full scope of their equivalents.

[0096] The above description is intended to be illustrative and not restrictive. For example, the above examples (or one or more thereof) can be used in combination with each other. Other embodiments can be used by those skilled in the art when reading the above description. Furthermore, in the above specific embodiments, various features may be grouped together to simplify this disclosure. Features disclosed that are not claimed in the claims are not essential to any claim. Rather, the subject matter of this disclosure may be less than all the features of a particular disclosed embodiment.

[0097] Therefore, the claims are incorporated herein by way of example or embodiment, wherein each claim is an independent, separate embodiment, and these embodiments are contemplated to be combined with each other in various combinations or arrangements. The scope of protection of this disclosure should be determined by reference to the appended claims and the full scope of their equivalents.

Claims

1. A circuit testing method, comprising: Obtain the circuit file of the design under test; Acquire multiple test signals, wherein the multiple test signals include a first signal and a second signal, the first signal being the signal to be debugged in the design under test, and the second signal being a blank signal; An FPGA debug file is generated based on the circuit file and the plurality of test signals, wherein the plurality of test signals in the FPGA debug file are connected to a plurality of probes. as well as Run and verify the FPGA debug file.

2. The circuit testing method according to claim 1, wherein, Running and verifying the FPGA debug file includes, In response to an exception occurring during the execution of the FPGA debug file, an updated debug signal is obtained; Connect the updated signal to be debugged to the probe corresponding to the second signal; Use incremental routing to generate updated FPGA debug files; as well as Run and verify the updated FPGA debug file.

3. The circuit testing method according to claim 1, wherein, Acquiring multiple test signals includes obtaining the multiple test signals from Register Transfer Language (RTL) statements or from an input device configuration (IDC) file.

4. The circuit testing method according to claim 1, wherein, Generating an FPGA debug file based on the circuit file and the plurality of test signals includes: generating a netlist based on the circuit file and the plurality of test signals; connecting the plurality of test signals to a plurality of probes; placement and routing; and generating the FPGA debug file.

5. The circuit testing method according to claim 4, wherein, It also includes segmenting the netlist.

6. The circuit testing method according to claim 1, wherein, The number of the second signal exceeds a preset threshold.

7. A circuit testing apparatus, comprising: The first acquisition module is configured to acquire the circuit file of the design under test. The second acquisition module is configured to acquire multiple test signals, wherein the multiple test signals include a first signal and a second signal, the first signal being a signal to be debugged in the design under test, and the second signal being a blank signal; The debug file generation module is configured to generate an FPGA debug file based on the circuit file and the plurality of test signals, wherein the plurality of test signals in the FPGA debug file are connected to a plurality of probes. as well as The verification module is configured to run and verify the FPGA debug file.

8. A circuit testing device, comprising: At least one processor; as well as A memory for storing computer-executable instructions that, when executed, cause the at least one processor to perform the circuit testing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, wherein, The computer-readable storage medium has computer-executable instructions stored thereon for performing the circuit testing method according to any one of claims 1 to 6.

10. A computer program product comprising a computer program, wherein, When the computer program is executed by the processor, it implements the circuit testing method according to any one of claims 1 to 6.

Images