CN114548027A

CN114548027A - Method for tracking signal in verification system, electronic device and storage medium

Info

Publication number: CN114548027A
Application number: CN202111627227.5A
Authority: CN
Inventors: 黄世杰; 黄武
Original assignee: Xinhuazhang Technology Co ltd
Current assignee: Xinhuazhang Technology Co ltd
Priority date: 2021-12-28
Filing date: 2021-12-28
Publication date: 2022-05-27

Abstract

The present application provides a method of tracking a signal in an authentication system. The method comprises the following steps: generating a schematic diagram of the verification system according to the description of the verification system, wherein the description of the verification system comprises the description of the device to be tested and the 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 instant; and highlighting the signal propagation path in the schematic diagram.

Description

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

Technical Field

The embodiment of the application relates to the technical field of logic system design, in particular to a method for tracking signals in a verification system, electronic equipment and a storage medium.

Background

In the field of verification of integrated circuits, in order to verify whether a logic system design is correct, a verification environment needs to be designed for verifying the logic system design. The logic system design and verification environment as a whole may be referred to as a verification system. The verification system may be run on a computer or hardware simulation device after compilation to perform simulation testing on various functions of the logic system design to verify whether the logic system design is correct. The design may be, for example, a verification environment may be written in the SystemVerilog language, while the logic system design may be written in the Verilog language. Therefore, the logic system design tested or verified in the simulation may also be referred to as a Device Under Test (DUT).

During the verification process, it is often necessary to see which signals a particular signal in the DUT is driven by. As the chip design scale becomes larger and larger, the number of signals driving a particular signal is huge, and therefore it becomes more and more difficult to see the propagation path of one signal. Meanwhile, in the verification process, besides the possibility of design errors of the device to be tested, design errors may exist in the verification environment as well. That is, the signal driving the device under test may itself be an error. The prior art also fails to trace the initial source of the driving signal across the boundary of the dut and the verification environment, which results in a decrease in the efficiency of debugging the dut.

How to quickly and effectively show a propagation path of a signal to a designer, particularly a propagation path that crosses the boundary between a device under test and a verification environment, is an urgent problem to be solved.

Disclosure of Invention

A first aspect of the present application provides a method of tracking a signal in an authentication system. The method comprises the following steps: generating a schematic diagram of the verification system according to the description of the verification system, wherein the description of the verification system comprises the description of the device to be tested and the 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 instant; and highlighting the signal propagation path in the schematic diagram.

A second aspect of the present application provides an electronic device. The electronic device includes a memory for storing a set of instructions; and at least one processor configured to execute the set of instructions to cause the computing device to perform the method of the first aspect.

A second aspect of the application provides a non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method according to the first aspect.

Drawings

In order to more clearly illustrate the technical solutions in the present application or the related art, the drawings needed to be used in the description of the embodiments or the related art will be briefly introduced below, and it is obvious that the drawings in the following description are only embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.

Fig. 1 shows a schematic diagram of a host according to an embodiment of the application.

FIG. 2A shows a schematic diagram of a simulation tool and a debugging tool according to an embodiment of the present application.

FIG. 2B illustrates a schematic diagram of an exemplary verification system in accordance with embodiments of the present application.

FIG. 2C illustrates a schematic diagram of an exemplary verification system in accordance with embodiments of the present application.

FIG. 3 illustrates a schematic diagram of an exemplary verification system in accordance with embodiments of the present application.

Fig. 4 shows a schematic diagram of a method of tracking a signal in an authentication system according to an embodiment of the application.

Detailed Description

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

It is to be noted that, unless otherwise defined, technical or scientific terms used herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. As used in this application, the terms "first," "second," and the like do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and similar words are intended to mean that the elements or items listed before the word cover the elements or items listed after the word and their equivalents, without excluding other elements or items. "connected," and like terms, are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect.

Simulation testing is the application of various stimuli to a logic system design on a host computer running a simulation test system to detect whether the logic system design can perform a predetermined function.

Fig. 1 shows a schematic diagram of a host 100 according to an embodiment of the application. The host 100 may be an electronic device running an emulation 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. Wherein processor 102, memory 104, network interface 106, and peripheral interface 108 are communicatively coupled to each other within the host via 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 associated with the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated into a single logic component. As shown in FIG. 1, processor 102 may include a plurality of processors 103A, 103B, and 102 c.

The memory 104 may be configured to store data (e.g., instruction sets, computer code, intermediate data, etc.). In some embodiments, the simulation test system for simulating a test design may be a computer program stored in memory 104. As shown in fig. 1, the data stored by the memory may include program instructions (e.g., for implementing the simulation method of the present application) and data to be processed (e.g., the memory may store temporary code generated during the compilation process). The processor 102 may also access memory-stored program instructions and data and execute the program instructions to operate on the data to be processed. The memory 104 may include volatile memory devices or non-volatile memory devices. In some embodiments, the memory 104 may include Random Access Memory (RAM), Read Only Memory (ROM), optical disks, magnetic disks, hard disks, Solid State Disks (SSDs), flash memory, memory sticks, and the like.

Network interface 106 may be configured to provide host 100 with communications with other external devices via a network. The network may be any wired or wireless network capable of transmitting and receiving data. For example, the network may 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 of the above. It is to be understood that the type of network is not limited to the specific examples described above. In some embodiments, network interface 106 may include any combination of any number of Network Interface Controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, and the like.

Peripheral interface 108 may be configured to connect host 100 with one or more peripheral devices to enable information input and output. For example, the peripheral devices may include input devices such as keyboards, mice, touch pads, touch screens, microphones, various sensors, and output devices such as displays, speakers, vibrators, indicator lights, and the like.

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

It should be noted that although the host architecture only shows the processor 102, the memory 104, the network interface 106, the peripheral interface 108, and the bus 110, in a specific implementation, the host architecture may also include other components necessary to achieve normal operation. Furthermore, those skilled in the art will appreciate that the above-described host architecture may also include only the components necessary to implement the embodiments of the present application, and need not include all of the components shown in the figures.

FIG. 2A shows a schematic diagram of a simulation tool 202 and a debugging tool 200 according to an embodiment of the present application. Simulation tool 202 and debug tool 200 may be computer programs running on host 100.

In the field of chip design, a design may be simulated using a simulation tool. The simulation tool may be, for example, a GalaxSim simulation tool available from Chihua chapter science and technology, Inc. The example simulation tool 202 shown in FIG. 2A may include a compiler 120 and a simulator 220. Compiler 120 may compile a design (e.g., verification system 210) into object code 204, simulator 220 may simulate from object code 204, and output simulation results 206. For example, the simulation tool 202 may output simulation results (e.g., a simulation waveform diagram) onto an output device (e.g., displayed on a display) via the peripheral interface 108 of fig. 1.

The debug tool 200 may also read the simulation results 206. For example, the debugging tool 200 may read the simulation results 206 stored in a waveform file and generate corresponding simulation waveforms for debugging. Debug tool 200 can also read the description of verification system 210 (typically SystemVerilog and Verilog code) and display it to the user. The debugging tool 200 may also generate various graphical interfaces to facilitate the debugging work of the user. The user may issue a debug command to the debug tool 200 (e.g., run the verification system 210 to a certain point), which the debug tool 200 then applies to the simulation tool 202 to execute accordingly.

It will be appreciated that in addition to interfacing with simulation tool 202, debug tool 200 may also interface with a hardware simulator (emulator).

FIG. 2B illustrates a schematic diagram of an exemplary validation system 210 according to an embodiment of the present application.

As shown in FIG. 2B, a verification system 210 that is simulated in the simulation tool 202 may include a device under test 212 and a verification environment 214. Testing of the device under test 212 entails utilizing the verification environment 214 to provide a stimulus signal (e.g., input 216) to the device under test 212, and the device under test 212 may generate a corresponding output signal (e.g., output 218) based on the stimulus signal. In some embodiments, the verification system 210 may include the device under test 212 and the verification environment 214 described previously. In this way, the simulation tool 202 simulates the verification system 210, and finally obtains a corresponding test result, so as to determine whether the device under test 212 correctly implements the function to be implemented based on the test result.

The device under test 212 may include various types of modules. Each module may further include one or more sub-modules (e.g., interface module 2122). Each module may include at least one input signal or output signal. Generally, the debugging tool 200 may generate a 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 (schematic diagram) of the device under test 212. Generating a schematic diagram of the device under test 212 is prior art and a detailed description is omitted here.

The verification environment 214 may be a test platform (testbench) built through a verification language (e.g., systemveilog, SystemC, PSS language, etc.) for testing the device under test 212. The verification environment 214 may include multiple components that implement different functionality. 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 transmit the excitation signals in a particular sequence. Signal driving component 2144 may convert the excitation signal into a signal that the device under test can receive (e.g., input 216 in fig. 2B) while driving device under test 212 according to a particular protocol. The signal acquisition component 2146 may collect the signal returned from the device under test 212 (e.g., output 218 in fig. 2B) and pass on 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 interfacing with the device under test 212, an environment component (not shown), an agent component (not shown), and so forth.

The debug tool 200 can generate the connection relationships of the plurality of components in the verification environment according to the description of the verification language 214 in the verification environment.

In some embodiments, the Verification environment 214 may be a UVM (Universal Verification method) Verification environment. The UVM verification environment may include a plurality of instructions, for example, a join instruction and a hierarchy instruction. Debug tool 200 may generate connection relationships for a plurality of components in the UVM verification environment according to a connection instruction (connect phase) in the UVM verification environment. The connect instruction is a task of the UVM during operation to connect a plurality of components according to a user instruction (i.e., a code description). For example, refer to the connection instruction as follows.

m_driver.seq_item_port.connect(m_sequencer.seq_item_export)；

m_driver.vif＝m_cfg.vif；

Where m _ driver represents the signal driving component 2144, m _ sequence represents the signal generating component 2142, m _ cfg represents the interface component 2148, and connect () is a connect command. The debugging tool 200 may determine that the signal driving component 2144 and the signal generating component 2142 have a connection relationship by analyzing the first row statement, and more specifically, that the seq _ item _ port of the signal driving component 2144 is connected with the seq _ item _ port of the signal generating component 2142. By analyzing the second row of statements, it is determined that the signal driving component 2144 and the interface component 2148 have a connection relationship, and more specifically, the virtual interface vif of the signal driving component 2144 is connected to the virtual interface vif of the interface component 2148.

Accordingly, the debugging tool 200 may generate a schematic diagram of the verification environment 214 according to the connection relationship of the respective components of the verification environment 214.

In actual engineering, the verification environment 214 and the device under test 212 generally perform simulation testing, error debugging, and the like as a verification system as a whole. Thus, in some embodiments, the debug tool 200 needs to not only generate a schematic of the verification environment 214 and the device under test 212, but also determine the manner of connection between the device under test 212 and the verification environment 214.

The connection between the device under test 212 and the verification environment 214 is not an entity such as a wire or fiber optic cable or an analog thereof, but rather an interface protocol between the device under test 212 and the verification environment 214. Such an interface protocol may be implemented by an authentication language. For example, the user may define an interface module (e.g., interface module 2122 in fig. 2B) in the device under test 212 in advance and an interface component (e.g., interface 2148 in fig. 2B) in the verification environment 214 to communicate with the interface module 2122. That is, the interface module and the interface component can exchange data with each other.

The combination of the interface module and the interface component is an interface protocol. It is to be appreciated that the same interface protocol can support both data (e.g., input 216 in FIG. 2B) from verification environment 214 to device under test 212 and data (e.g., output 218 in FIG. 2B) from device under test 212 to verification environment 214. In some embodiments, the transfer of data between the verification environment 214 and the device under test 212 may be accomplished through a virtual interface. The debugging tool 200 may determine the connection relationship between the verification environment and the device under test according to the call relationship of the virtual interface. In some embodiments, the transfer of data may be accomplished through a Verilog Produceral Interface (VPI). The debugging tool 200 can determine the connection relationship between the verification environment and the device to be tested according to the calling and assignment of the VPI.

Thus, the debug tool 200 can determine how data is interacted between the device under test 212 and the verification environment 214 from the descriptions of the device under test 212 and the verification environment 214. That is, 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).

Based on the schematic diagrams of the verification environment 214 and the device under test 212 and the connection relationship therebetween, the debug tool 200 can generate a schematic diagram of a verification system.

FIG. 2C illustrates a schematic diagram of an exemplary verification system 220 in accordance with embodiments of the present application. As shown in fig. 2C, the verification system 220 includes a device under test 222 and a verification environment 224. Device under test 222 may include a plurality of modules, for example, interface modules F1 and F2 and module 2222. The connections between the various modules are shown in dashed lines. The verification environment 224 may include a plurality of components, for example, signal generating

components

1 and 2, signal driving

components

1 and 2, and signal acquiring

components

1 and 2. Connections between the various components are shown in dashed lines. The connection between the device under test 222 and the verification environment 224 is indicated by a double arrow.

On the schematic diagram of verification system 220, a user may select a target signal and a target time to observe the signal propagation path of the target signal at the target time. A signal propagation path is a propagation path from a signal source that drives a target signal at a target instant to the target signal. That is, a change in the signal source at the target time may cause a change in the target signal. It will be appreciated that for a target signal, there may be multiple signal sources and corresponding propagation paths, and that the propagation paths at different times may be different.

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

FIG. 3 illustrates a schematic diagram 300 of an exemplary verification system in accordance with embodiments of the present application.

As shown in fig. 3, the output signal 300 of the module 2222 is selected as the target signal, and the time T is selected as the target time on a time axis. In general, a user applies an excitation signal to a device under test using a verification environment and observes an output signal of the device under test. Thus, the target signal is typically a signal in the device under test. The target signal may be the final output signal of the device under test or a signal of a certain module inside the device under test. Meanwhile, the signal source is typically a component of the verification environment (e.g., a signal generation component).

In some embodiments, the debug tool 200 can determine at least one upstream signal in the device under test 222 that is related to the driving target signal 302 from the description of the device under test 222. For example, in FIG. 3, debug tool 200 may determine that signals 304a-c, etc. are upstream signals of target signal 302. It will be appreciated that the upstream signal also includes a series of signals between the signals 304a-c and the target signal 302.

However, since not every upstream signal can drive the target signal at the target time, debug tool 200 also needs to determine, among the upstream signals, the signal at which the Value Change (VC) occurs at the target time. These signals, which change in value at the target time instant, may be referred to as excitation signals.

The change in which signal occurrences occur at a given time is generally not determinable by analyzing the code of the device under test. Thus, in some embodiments, to determine the stimulus signal, debug tool 200 may run the verification system to this target time T. In this way, the debugging tool 200 can check which upstream signals have changed values at time T according to the actual simulation run, and further find the stimulus signal therefrom. For example, in FIG. 3, signal 304a is determined to be the excitation signal.

Connecting the target signal 302 and the signal 304a and the signal therebetween forms a propagation path 302-304a within the device under test 222.

As described above, the debug tool 200 can determine the manner in which the device under test 222 is connected to the verification environment 224. Thus, the debug tool 200 can determine the components connected to the excitation signal according to the connection mode and the excitation signal. As shown in fig. 3, the debug tool 200 may determine that the interface 306 of the signal driving component 1 is connected with the signal 304 a. Connecting signal 304a with interface 306 of signal driving assembly 1 forms propagation paths 304a-306 between device under test 222 and verification environment 224.

Further, the debugging tool 200 may determine the signal source driving the signal driving component 1 according to the description of the verification environment. In some embodiments, the verification environment may be described by SystemVerilog, and thus, debug tool 200 may determine the signal source based on data assignment relationships or the like in the description of the verification environment. For example, the debugging tool 200 may determine that the signal generating component 1 is a signal source. The

propagation path

306 and 308 within the verification environment 224 are formed by connecting the interface 308 of the signal generation component 1 and the interface 306 of the signal driving component 1.

These three propagation paths 302-304a, 304a-306, and 306-308 constitute signal propagation paths 302-308 of the target signal 302 throughout the verification system, including the verification environment.

The debug tool 200 may highlight 308 the signal propagation path 302 on the schematic diagram 300. In some embodiments, signal propagation paths 302-308 may be highlighted, bolded, etc. Which is shown in fig. 3 by way of example in bold. In this way, the user can clearly see how the signal of the driving target signal 302 is gradually transferred from the authentication environment at the time T. The user may further select a module in a component or device under test in the verification environment to observe how the

signal propagation path

302 and 308 exist within the component or module.

It will be appreciated that in some embodiments, there may be no signal propagation path at time T. For example, for a two-input (first AND second input) AND gate, when the first input therein is "0" at time T, the output of the AND gate is always "0" regardless of the change in the second input. That is, at time T, no signal is driving the AND gate. At this point, debug tool 200 may continue to simulate running the verification system in the background until the first input becomes "1" at some point in time T + n. For the case where the user selects time T, the commissioning device 200 may prompt the user for the presence of a signal propagation path for the target signal at time T + n.

Embodiments of the present application also provide a method of tracking a signal in an authentication system.

Fig. 4 shows a schematic diagram of a method 400 of tracking a signal in an authentication system according to an embodiment of the application. Method 400 may be performed by host 100 of fig. 1. The method 400 may include the following steps.

At step 402, host 100 may generate a schematic diagram (as shown in FIG. 2C) of the authentication system (e.g., authentication system 210 of FIG. 2B) according to the description of the authentication system. The description of the verification system includes a description of a device under test (e.g., device under test 222 of FIG. 3) and a description of a verification environment (e.g., verification environment 224 of FIG. 3). The Verification environment may be a uvm (universal Verification method) Verification environment.

At step 404, host 100 may receive a target signal (e.g., signal 302 of FIG. 3) and a selection of a target time (e.g., time T of FIG. 3) from a user. The target signal is a signal in the device under test, and the signal propagation path includes the target signal as an end point and a signal source (e.g., signal 308 of fig. 3) as a start point, the signal source being a component of the verification environment. The signal source is a signal generating assembly (sequencer)

At step 406, host 100 may determine a signal propagation path (e.g., path 302-308 of FIG. 3) that drives the target signal at the target time. In some embodiments, determining a signal propagation path that drives the target signal at the target time further comprises: determining at least one upstream signal (e.g., signals 304a, 304b, and 304c of FIG. 3, etc.) in the device under test that is related to driving the target signal from the description of the device under test; determining, among the at least one upstream signal, an excitation signal (e.g., signal 304a of FIG. 3) that varies in value at the target time instant; determining an interface component (e.g., interface 306 of signal driving component 1 of fig. 3) of a verification environment that drives the excitation signal according to a description of the verification system, which includes a connection manner of 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.

In some embodiments, determining, among the at least one upstream signal, an excitation signal that varies in value at the target time further comprises: running the verification system to the target time; determining whether there is a change in value of the at least one upstream signal at the target time; and determining the excitation signal in the at least one upstream signal.

In some embodiments, the signal propagation paths include 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 instance further comprises: determining the first propagation path according to the description of the device to be tested, wherein the first propagation path comprises the excitation signal and the target signal; determining the second propagation path according to the connection mode of the verification environment and the device to be tested, wherein the second propagation path comprises the excitation signal and the interface component; and determining the third propagation path from the description of the verification environment, the third propagation path including the interface component and the signal source.

At step 408, host 100 may highlight the signal propagation path in the schematic.

It should be noted that the method of the present application may be executed by a single device, such as a computer or a server. The method of the embodiment can also be applied to a distributed scene and completed by the mutual cooperation of a plurality of devices. In the case of such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the present application, and the multiple devices interact with each other to complete the method.

An embodiment of the present application further provides an electronic device, including a memory configured to store a set of instructions; and at least one processor configured to execute the shuffling instructions to cause the computing device to perform the method 400 provided by embodiments of the present application.

Embodiments of the present application also provide a non-transitory computer-readable storage medium storing a set of instructions of a computer for causing the computer to perform the method 400 provided by embodiments of the present application when executed.

Some embodiments of the present application are described above. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

Those of ordinary skill in the art will understand that: the discussion of any embodiment above is meant to be exemplary only, and is not intended to intimate that the scope of the disclosure, including the claims, is limited to these examples; within the context of the present application, features from the above embodiments or from different embodiments may also be combined, 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 brevity.

While the present application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic ram (dram)) may use the discussed embodiments.

The present application is intended to embrace all such alternatives, modifications and variances which fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalents, improvements, and the like that may be made without departing from the spirit or scope of the present application are intended to be included within the scope of the claims.

Claims

1. A method of tracking a signal in an authentication 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 comprises the description of the device to be tested and the 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 instant; and

the signal propagation path is highlighted in the schematic.

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

3. The method of claim 2, wherein determining a signal propagation path that drives the target signal at the target time instant further comprises:

determining at least one upstream signal in the device under test that is relevant to driving the target signal according to the description of the device under test;

determining, among the at least one upstream signal, an excitation signal that varies in value at the target time instant;

determining an interface component of a verification environment for driving the excitation signal according to the description of the verification system, wherein the description of the verification system comprises a connection mode of the verification environment and the device to be tested; and

determining the signal source driving the interface component according to the description of the verification environment.

4. The method of claim 3, wherein determining, among the at least one upstream signal, an excitation signal that varies in value at the target time further comprises:

running the verification system to the target time;

determining whether there is a change in value of the at least one upstream signal at the target time; and

determining the excitation signal in the at least one upstream signal.

5. The method of claim 3, wherein the signal propagation paths include 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 instance further comprises:

determining the first propagation path according to the description of the device to be tested, wherein the first propagation path comprises the excitation signal and the target signal;

determining the second propagation path according to the connection mode of the verification environment and the device to be tested, wherein the second propagation path comprises the excitation signal and the interface component; and

determining the third propagation path from the description of the verification environment, the third propagation path including the interface component and the signal source.

6. The method of claim 2, wherein the Verification environment is a uvm (universal Verification method) Verification environment.

7. The method of claim 6, wherein the signal source is a signal generating component (sequencer).

8. An electronic device comprises

A memory for storing a set of instructions; and

at least one processor configured to execute the set of instructions to cause the computing device to perform the method of any of claims 1 to 7.

9. A non-transitory computer readable storage medium storing a set of instructions of a computer for, when executed, causing the computer to perform the method of any of claims 1 to 7.