Method, electronic device and storage medium for tracking signals in verification system

Abstract

The present application provides a method for tracking signals in a verification system. The method includes: generating a schematic diagram of the verification system according to a description of the verification system, wherein the description of the verification system includes a description of a device under test and a description of a verification environment; receiving a target signal and a target time selection from a user; determining a signal propagation path that drives the target signal at the target time; and highlighting the signal propagation path in the schematic diagram.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of logic system design, and in particular to a method, electronic device, and storage medium for tracing signals in a verification system. Background Art

[0002] In the field of integrated circuit verification, in order to verify whether the logic system design is correct, it is necessary to design a verification environment for verifying the logic system design. The logic system design and the verification environment as a whole can be called a verification system. After compilation, the verification system can be run on a computer or hardware simulation device to simulate and test various functions of the logic system design, thereby verifying whether the logic system design is correct. The design can be, for example, that the verification environment can be written in SystemVerilog language, and the logic system design can be written in Verilog language. Therefore, the logic system design tested or verified in the simulation can also be called the device under test (DUT for short).

[0003] During the verification process, it is often necessary to check which signals drive a specific signal in the DUT. As chip design scales become larger and larger, the number of signals driving a specific signal is huge, so it is becoming increasingly difficult to view the propagation path of a signal. At the same time, during the verification process, in addition to the possible design errors in the device under test, the verification environment may also have design errors. In other words, the signal that drives the device under test may itself be an error. The existing technology is also unable to cross the boundary between the device under test and the verification environment to track the original source of the driving signal, which leads to a decrease in the efficiency of debugging the device under test.

[0004] How to quickly and effectively show designers the propagation path of signals, especially the propagation path that crosses the boundary between the device under test and the verification environment, is an urgent problem to be solved. Summary of the invention

[0005] The first aspect of the present application provides a method for tracking signals in a verification system. The method comprises: generating a schematic diagram of the verification system according to a description of the verification system, wherein the description of the verification system includes a description of a device under test and a description of a verification environment; receiving a target signal and a target time selection from a user; determining a signal propagation path that drives the target signal at the target time; and highlighting the signal propagation path in the schematic diagram.

[0006] The second aspect of the present application provides an electronic device, which includes a memory for storing a set of instructions and at least one processor configured to execute the set of instructions so that the computing device executes the method according to the first aspect.

[0007] A second 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

[0008] 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 only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0009] Figure 1 A schematic diagram of a host according to an embodiment of the present application is shown.

[0010] Figure 2A A schematic diagram of a simulation tool and a debugging tool according to an embodiment of the present application is shown.

[0011] Figure 2B A schematic diagram of an exemplary verification system according to an embodiment of the present application is shown.

[0012] Figure 2C A schematic diagram of an exemplary verification system according to an embodiment of the present application is shown.

[0013] Figure 3 A schematic diagram of an exemplary verification system according to an embodiment of the present application is shown.

[0014] Figure 4 A schematic diagram of a method for tracing a signal in a verification system according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0015] 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.

[0016] 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.

[0017] Simulation testing is to apply various stimuli to the logic system design on the host running the simulation test system to detect whether the logic system design can achieve the predetermined functions.

[0018] Figure 1 FIG. 1 is a schematic diagram of a host 100 according to an embodiment of the present application. The host 100 may be an electronic device running a simulation system. Figure 1 As shown, 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 host through the bus 110.

[0019] 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. Processor 102 may be used to perform functions related to the technology described in this application. In some embodiments, processor 102 may also include multiple processors integrated into a single logical component. Figure 1 As shown, the processor 102 may include a plurality of processors 103A, 103B, and 102c.

[0020] The memory 104 may be configured to store data (eg, 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. Figure 1 As shown, the data stored in the memory may include program instructions (e.g., program instructions for implementing the simulation method 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.

[0021] 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.

[0022] 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.

[0023] 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.

[0024] It should be noted that, although the above host 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 host 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 host 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.

[0025] Figure 2A The schematic diagram of the simulation tool 202 and the debugging tool 200 according to the embodiment of the present application is shown. The simulation tool 202 and the debugging tool 200 may be computer programs running on the host 100.

[0026] In the field of chip design, a design can usually be simulated using a simulation tool, such as the GalaxSim simulation tool produced by Xinhuazhang Technology Co., Ltd. Figure 2A The exemplary simulation tool 202 shown may include a compiler 120 and a simulator 220. The compiler 120 may compile a design (e.g., a verification system 210) into a target code 204, and the simulator 220 may perform simulation according to the target code 204 and output a simulation result 206. For example, the simulation tool 202 may output the simulation result (e.g., a simulation waveform) via Figure 1 The peripheral interface 108 outputs the data to an output device (eg, displayed on a display).

[0027] The debugging tool 200 can also read the simulation result 206. For example, the debugging tool 200 can read the simulation result 206 stored in the waveform file, and generate the corresponding simulation waveform for debugging. The debugging tool 200 can also read the description of the verification system 210 (usually SystemVerilog and Verilog code), and display it to the user. The debugging tool 200 can also generate various graphical interfaces to facilitate the debugging work of the user. The user can issue a debugging command to the debugging tool 200 (for example, run the verification system 210 to a certain moment), and the debugging tool 200 applies the debugging command to the simulation tool 202 to execute accordingly.

[0028] It is understandable that, in addition to being connected to the simulation tool 202 , the debugging tool 200 may also be connected to a hardware emulator.

[0029] Figure 2B A schematic diagram of an exemplary verification system 210 according to an embodiment of the present application is shown.

[0030] like Figure 2B As shown, the verification system 210 simulated in the simulation tool 202 may include a device under test 212 and a verification environment 214. The test of the device under test 212 requires the use of the verification environment 214 to provide an excitation signal (e.g., input 216) to the device under test 212, and the device under test 212 can generate a corresponding output signal (e.g., output 218) based on the excitation signal. In some embodiments, the verification system 210 may include the aforementioned device under test 212 and the verification environment 214. In this way, by simulating the verification system 210 through the simulation tool 202, a corresponding test result can be finally obtained, and then it can be judged based on the test result whether the device under test 212 correctly implements the required function.

[0031] The device under test 212 may include various modules. Each module may further include one or more submodules (e.g., interface module 2122). Each module may include at least one input signal or output signal. Generally, the debugging tool 200 may generate the connection relationship of each module in the device under test 212 according to the description of the device under test 212, and further generate a schematic diagram of the device under test 212. Generating a schematic diagram of the device under test 212 is a prior art, and a specific description is omitted here.

[0032] The verification environment 214 may be a testbench for testing the device under test 212 built by a verification language (e.g., SystemVerilog, SystemC, PSS language, etc.). The verification environment 214 may include multiple components that implement different functions. In some embodiments, the verification environment 214 may include a signal generation component (Sequencer) 2142, a signal driver component (Driver) 2144, and a signal acquisition component (Monitor) 2146. The signal generation component 2142 may send an excitation signal in a specific sequence. The signal driver component 2144 may convert the excitation signal into a signal that the device under test can receive (e.g., Figure 2B The signal acquisition component 2146 can collect signals returned from the device under test 212 (e.g., Figure 2B The output 218 in the verification environment 214 is forwarded to other components in the verification environment 214 for further processing. In some embodiments, the verification environment 214 may also include some other components, such as an interface 2148 for docking with the device under test 212, an environment component (not shown), an agent component (not shown), etc.

[0033] The debugging tool 200 may generate connection relationships between multiple components in the verification environment according to the description of the verification language 214 in the verification environment.

[0034] In some embodiments, verification environment 214 can be a UVM (Universal Verification Methodology) verification environment. The UVM verification environment can include multiple instructions, such as connection instructions and level instructions. Debug tool 200 can generate the connection relationship of multiple components in the UVM verification environment according to the connection instruction (connect phase) in the UVM verification environment. The connection instruction is a task of UVM during operation, which is used to connect multiple components according to user instructions (i.e., code description). For example, refer to the following connection instruction.

[0035] m_driver.seq_item_port.connect(m_sequencer.seq_item_export);

[0036] m_driver.vif = m_cfg.vif;

[0037] Among them, m_driver represents the signal driver component 2144, m_sequencer represents the signal generation component 2142, m_cfg represents the interface component 2148, and .connect() is a connection command. The debugging tool 200 can determine that the signal driver component 2144 and the signal generation component 2142 have a connection relationship by analyzing the first line of statements, and more specifically, the seq_item_port of the signal driver component 2144 is connected to the seq_item_export of the signal generation component 2142. By analyzing the second line of statements, it is determined that the signal driver component 2144 and the interface component 2148 have a connection relationship, and more specifically, the virtual interface vif of the signal driver component 2144 is connected to the virtual interface vif of the interface component 2148.

[0038] Accordingly, the debugging tool 200 may generate a schematic diagram of the verification environment 214 according to the connection relationship between the various components of the verification environment 214 .

[0039] In actual projects, the verification environment 214 and the device under test 212 are usually used as a verification system as a whole for simulation testing, error debugging, etc. Therefore, in some embodiments, the debugging tool 200 not only needs to generate the schematic diagram of the verification environment 214 and the device under test 212, but also needs to determine the connection method between the device under test 212 and the verification environment 214.

[0040] The connection between the device under test 212 and the verification environment 214 is not a physical connection such as a wire or an optical cable or a simulation thereof, but an interface protocol between the device under test 212 and the verification environment 214. This interface protocol can be implemented by a verification language. For example, a user can pre-define an interface module in the device under test 212 (for example, Figure 2B 2122 in the interface module), and define an interface component in the verification environment 214 (e.g., Figure 2B The interface 2148 in the embodiment communicates with the interface module 2122. That is, the interface module and the interface component can exchange data with each other.

[0041] The combination of the interface module and the interface component is an interface protocol. It is understandable that the same interface protocol can support both data (for example, Figure 2B 216) from the verification environment 214 to the device under test 212, and may also support data (e.g., Figure 2BThe output 218 in the test environment 214 is from the device under test 212 to the verification environment 214. In some embodiments, the data transmission between the verification environment 214 and the device under test 212 can be completed through a virtual interface. The debugging tool 200 can determine the connection relationship between the verification environment and the device under test based on the calling relationship of the virtual interface. In some embodiments, the data transmission can be implemented through a Verilog Procedural Interface (VPI). The debugging tool 200 can determine the connection relationship between the verification environment and the device under test based on the calling and assignment of the VPI.

[0042] Therefore, the debugging tool 200 can determine how data is interacted between the device under test 212 and the verification environment 214 according to the description of the device under test 212 and the verification environment 214. In other words, the debugging tool 200 can determine the connection relationship between the device under test 212 and the verification environment 214 according to the description of the verification system (including the description of the device under test 212 and the description of the verification environment 214).

[0043] According to the schematic diagrams of the verification environment 214 and the device under test 212 and the connection relationship between them, the debugging tool 200 can generate a schematic diagram of the verification system.

[0044] Figure 2C FIG. 2 shows a schematic diagram of an exemplary verification system 220 according to an embodiment of the present application. Figure 2C As shown, the verification system 220 includes a device under test 222 and a verification environment 224. The device under test 222 may include multiple modules, for example, interface modules F1 and F2 and module 2222. The connection between multiple modules is represented by a dotted line. The verification environment 224 may include multiple components, for example, signal generation components 1 and 2, signal drive components 1 and 2, and signal acquisition components 1 and 2. The connection between each component is represented by a dotted line. The connection between the device under test 222 and the verification environment 224 is represented by a double arrow.

[0045] On the schematic diagram of the verification system 220, the user can select a target signal and a target time to observe the signal propagation path of the target signal at the target time. The signal propagation path is the propagation path from the signal source driving the target signal at the target time to the target signal. In other words, the change of the signal source at the target time can cause the change of the target signal. It is understandable that for a target signal, there may be multiple signal sources and corresponding propagation paths, and the propagation paths at different times may be different.

[0046] In some embodiments, a user may click on a target signal on a schematic diagram of the verification system 220 and select a target time for the target signal.

[0047] Figure 3 A schematic diagram 300 of an exemplary verification system according to an embodiment of the present application is shown.

[0048] like Figure 3 As shown, the output signal 300 of module 2222 is selected as the target signal, and the moment T is selected as the target moment on a time axis. Generally speaking, the user applies the stimulus signal to the device under test using the verification environment and observes the output signal of the device under test. Therefore, the target signal is usually a signal in the device under test. The target signal can be the final output signal of the device under test or the signal of a module inside the device under test. At the same time, the signal source is usually a component of the verification environment (for example, a signal generation component).

[0049] In some embodiments, the debugging tool 200 can determine at least one upstream signal related to the driving target signal 302 in the device under test 222 according to the description of the device under test 222. Figure 3 In the example, the debugging tool 200 may determine that the signals 304a-c and the like are upstream signals of the target signal 302. It is understood that the upstream signals also include a series of signals between the signals 304a-c and the target signal 302.

[0050] However, since not every upstream signal can drive the target signal at the target time, the debugging tool 200 also needs to determine the signals whose value changes (VC) occur at the target time among these upstream signals. These signals whose value changes occur at the target time can be called stimulus signals.

[0051] It is usually impossible to determine which signals have changed in value at a given moment by analyzing the code of the device under test. Therefore, in some embodiments, in order to determine the stimulus signal, the debugging tool 200 can run the verification system to the target time T. In this way, the debugging tool 200 can check which upstream signals have changed in value at time T based on the actual simulation operation, and then find the stimulus signal from them. For example, Figure 3 In FIG. 3 , signal 304 a is determined to be the excitation signal.

[0052] The target signal 302 and the signal 304 a as well as the signals therebetween are connected to form a propagation path 302 - 304 a within the device under test 222 .

[0053] As described above, the debugging tool 200 can determine the connection mode between the device under test 222 and the verification environment 224. Therefore, the debugging tool 200 can determine the component connected to the stimulus signal according to the above connection mode and the stimulus signal. Figure 3As shown, the debugging tool 200 can determine that the interface 306 of the signal driving component 1 is connected to the signal 304a. After the signal 304a is connected to the interface 306 of the signal driving component 1, a propagation path 304a-306 between the device under test 222 and the verification environment 224 is formed.

[0054] Further, the debugging tool 200 can determine the signal source driving the signal driving component 1 according to the description of the verification environment. In some embodiments, the verification environment can be described by SystemVerilog, so the debugging tool 200 can determine the signal source according to the data assignment relationship in the description of the verification environment. For example, the debugging tool 200 can determine that the signal generating component 1 is the signal source. After the interface 308 of the signal generating component 1 is connected to the interface 306 of the signal driving component 1, the propagation path 306-308 in the verification environment 224 is formed.

[0055] The three propagation paths 302-304a, propagation paths 304a-306 and propagation paths 306-308 constitute the signal propagation path 302-308 of the target signal 302 in the entire verification system including the verification environment.

[0056] The debugging tool 200 may highlight the signal propagation paths 302-308 on the schematic diagram 300. In some embodiments, the signal propagation paths 302-308 may be displayed in a highlighted, bold, or other manner. Figure 3 In this way, the user can clearly see how the signal driving the target signal 302 is gradually transmitted from the verification environment at time T. The user can also further select a component in the verification environment or a module in the device under test to observe how the signal propagation path 302-308 exists inside the component or module.

[0057] It is understandable that in some embodiments, there may be no signal propagation path at time T. For example, for an AND gate with two inputs (a first input and a second input), when the first input is "0" at time T, the output of the AND gate is always "0" regardless of how the second input changes. In other words, at time T, there is no signal driving the AND gate. At this time, the debugging tool 200 can continue to simulate and run the verification system in the background until the first input becomes "1" at a certain time T+n. In the case where the user selects time T, the debugging device 200 can prompt the user that there is a signal propagation path for the target signal at time T+n.

[0058] An embodiment of the present application also provides a method for tracing a signal in a verification system.

[0059] Figure 4FIG. 4 is a schematic diagram showing a method 400 for tracking signals in a verification system according to an embodiment of the present application. The method 400 may be Figure 1 The method 400 may be performed by the host 100. The method 400 may include the following steps.

[0060] In step 402, the host 100 may perform a verification according to the verification system (eg, Figure 2B The description of the verification system 210) generates a schematic diagram of the verification system (such as Figure 2C The description of the verification system includes a device under test (for example, Figure 3 Description of the device under test 222) and the verification environment (e.g., Figure 3 The verification environment 224 may be a UVM (Universal Verification Methodology) verification environment.

[0061] In step 404, the host 100 may receive a target signal (eg, Figure 3 signal 302) and the target time (such as Figure 3 The target signal is a signal in the device under test, and the signal propagation path includes the target signal as the end point and the signal source (such as Figure 3 The signal source is a component of the verification environment. The signal source is a signal generating component (sequencer)

[0062] In step 406, the host 100 may determine a signal propagation path (eg, Figure 3 In some embodiments, determining the signal propagation path that drives the target signal at the target time further includes: determining at least one upstream signal (e.g., Figure 3 304a, 304b and 304c, etc.); determining in the at least one upstream signal an excitation signal (such as Figure 3 Determine the interface component of the verification environment that drives the stimulus signal according to the description of the verification system (for example, Figure 3 The description of the verification system includes the connection mode between the verification environment and the device under test; and determining the signal source driving the interface component according to the description of the verification environment.

[0063] In some embodiments, determining an excitation signal in the at least one upstream signal that has a value change at the target time further includes: running the verification system to the target time; determining whether the at least one upstream signal has a value change at the target time; and determining the excitation signal in the at least one upstream signal.

[0064] In some embodiments, the signal propagation path includes a first propagation path within the device under test, a second propagation path between the device under test and the verification environment, and a third propagation path within the verification environment, and determining the signal propagation path for driving the target signal at the target moment further includes: determining the first propagation path according to a description of the device under test, the first propagation path including the excitation signal and the target signal; determining the second propagation path according to a connection method between the verification environment and the device under test, the second propagation path including the excitation signal and the interface component; and determining the third propagation path according to the description of the verification environment, the third propagation path including the interface component and the signal source.

[0065] In step 408 , the host 100 may highlight the signal propagation path in the schematic diagram.

[0066] It should be noted that the method of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the present application, and the multiple devices will interact with each other to complete the described method.

[0067] An embodiment of the present application also provides an electronic device, including a memory for storing a group of instructions; and at least one processor configured to execute the reorganized instructions so that the computing device executes the method 400 provided by the embodiment of the present application.

[0068] The embodiment of the present application also provides a non-transitory computer-readable storage medium, which stores a set of instructions for a computer, and the set of instructions is used to enable the computer to perform the method 400 provided in the embodiment of the present application when executed.

[0069] 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.

[0070] Those 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.

[0071] Although the present application has been described in conjunction with specific embodiments of the present application, many replacements, 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.

[0072] 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

1. A method for tracking a signal in a verification system, comprising: Generating a schematic diagram of the verification system according to the description of the verification system, wherein the description of the verification system includes a description of the device under test and a description of the verification environment; receiving a target signal and a selection of a target time from a user; determining a signal propagation path that drives the target signal at the target time; as well as highlighting the signal propagation path in the schematic diagram; Wherein, determining the signal propagation path driving the target signal at the target time further includes: Determine at least one upstream signal in the device under test that is related to driving the target signal according to the description of the device under test; determining, in the at least one upstream signal, an excitation signal having a value change at the target time; Determining an interface component of the verification environment that drives the stimulus signal according to the description of the verification system, wherein the description of the verification system includes a connection method between the verification environment and the device under test; and A signal source driving the interface component is determined according to the description of the verification environment.

2. The method of claim 1, wherein: The target signal is a signal in the device under test, the signal propagation path includes the target signal as an end point and a signal source as a starting point, and the signal source is a component of the verification environment.

3. The method of claim 1, wherein: Determining the excitation signal having a value change at the target time in the at least one upstream signal further comprises: Running the verification system to the target time; determining whether the at least one upstream signal has a value change at the target time; and The excitation signal is determined in the at least one upstream signal.

4. The method of claim 1, wherein: The signal propagation path includes a first propagation path within the device under test, a second propagation path between the device under test and the verification environment, and a third propagation path within the verification environment, and determining the signal propagation path that drives the target signal at the target time further includes: Determine the first propagation path according to the description of the device under test, where the first propagation path includes the excitation signal and the target signal; determining the second propagation path according to a connection mode between the verification environment and the device under test, wherein the second propagation path includes the excitation signal and the interface component; and The third propagation path is determined according to the description of the verification environment, and the third propagation path includes the interface component and the signal source.

5. The method of claim 2, wherein: The verification environment is a UVM verification environment.

6. The method of claim 5, wherein: The signal source is a signal generating component.

7. An electronic device comprising a memory for storing a set of instructions; and At least one processor is configured to execute the set of instructions so that the electronic device performs the method according to any one of claims 1 to 6. 8 . A non-transitory computer-readable storage medium storing a set of instructions for a computer, the set of instructions being used to cause the computer to perform the method according to claim 1 when executed.

Images