CN114548027B - Method, electronic device and storage medium for tracking signals in verification system - Google Patents
Method, electronic device and storage medium for tracking signals in verification system Download PDFInfo
- Publication number
- CN114548027B CN114548027B CN202111627227.5A CN202111627227A CN114548027B CN 114548027 B CN114548027 B CN 114548027B CN 202111627227 A CN202111627227 A CN 202111627227A CN 114548027 B CN114548027 B CN 114548027B
- Authority
- CN
- China
- Prior art keywords
- signal
- under test
- propagation path
- device under
- verification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012795 verification Methods 0.000 title claims abstract description 124
- 238000000034 method Methods 0.000 title claims abstract description 35
- 238000012360 testing method Methods 0.000 claims abstract description 85
- 238000010586 diagram Methods 0.000 claims abstract description 28
- 238000011144 upstream manufacturing Methods 0.000 claims description 16
- 230000005284 excitation Effects 0.000 claims description 15
- 230000008859 change Effects 0.000 claims description 11
- 238000004088 simulation Methods 0.000 description 26
- 238000013461 design Methods 0.000 description 18
- 230000002093 peripheral effect Effects 0.000 description 8
- 230000006870 function Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 241000543370 Galax Species 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 238000012942 design verification Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 230000007274 generation of a signal involved in cell-cell signaling Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/39—Circuit design at the physical level
- G06F30/398—Design verification or optimisation, e.g. using design rule check [DRC], layout versus schematics [LVS] or finite element methods [FEM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
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
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 design verification environment is required 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 tests on various functions of the logic system design to verify that the logic system design is correct. The design may be, for example, the verification environment may be written in the SystemVerilog language, and the logic system design may be written in the Verilog language. Thus, a logic system design that is tested or verified in simulation may also be referred to as a device under test (Device Under Test, DUT for short).
During verification, it is often necessary to see which signals are driven by a particular signal in the DUT. As the chip design scale becomes larger and larger, the number of signals driving a particular signal is large, and thus it becomes more difficult to view the propagation path of one signal. Meanwhile, in the verification process, besides the device to be tested, there may be design errors, and the verification environment may also have design errors. That is, the signal driving the device under test itself may be erroneous. The prior art also fails to track the original source of the drive signal across the boundaries of the device under test and the verification environment, which results in a decrease in the efficiency of debugging the device under test.
How to quickly and effectively present the propagation paths of signals to designers, particularly those that cross the boundaries of the device under test and the verification environment, is a challenge.
Disclosure of Invention
A first aspect of the application provides a method of tracking a signal in an authentication system. The method includes generating a schematic diagram of the verification system from a description of the verification system, the description of the verification system including a description of a device under test and a description of a verification environment, receiving a target signal from a user and a selection of a target time, determining a signal propagation path to drive the target signal at the target time, and highlighting the signal propagation path in the schematic diagram.
A second aspect of the application provides an electronic device. The electronic device comprising a memory for storing a set of instructions, and at least one processor configured to execute the set of instructions to cause the computing apparatus to perform the method according to 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 of the first aspect.
Drawings
In order to more clearly illustrate the technical solutions of the present application or related art, the drawings that are required to be used in the description of the embodiments or related art will be briefly described below, and it is apparent that the drawings in the following description are only embodiments of the present application, and other drawings may be obtained according to the drawings without inventive effort to those of ordinary skill in the art.
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 debug tool in accordance with an embodiment of the present application.
FIG. 2B shows a schematic diagram of an exemplary verification system in accordance with an embodiment of the application.
FIG. 2C illustrates a schematic diagram of an exemplary verification system in accordance with an embodiment of the application.
FIG. 3 illustrates a schematic diagram of an exemplary verification system in accordance with an embodiment of the application.
Fig. 4 shows a schematic diagram of a method of tracking a signal in a verification system according to an embodiment of the application.
Detailed Description
The present application will be further described in detail below with reference to specific embodiments and with reference to the accompanying drawings, in order to make the objects, technical solutions and advantages of the present application more apparent.
It is to be noted that unless otherwise defined, technical or scientific terms used herein should be taken in a general sense as understood by one of ordinary skill in the art to which the present application belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" and the like means that elements or items preceding the word are included in the element or item listed after the word and equivalents thereof without precluding other elements or items. The term "coupled" and the like 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 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, host 100 may include a processor 102, a memory 104, a network interface 106, a peripheral interface 108, and a bus 110. Wherein the processor 102, the memory 104, the network interface 106, and the peripheral interface 108 are communicatively coupled to each other within the host via a bus 110.
The processor 102 may be a central processing unit (Central Processing Unit, CPU), an image processor, a neural Network Processor (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application SPECIFIC INTEGRATED Circuit (ASIC), or one or more integrated circuits. The processor 102 may be used to perform functions related to the techniques described herein. In some embodiments, processor 102 may also include multiple processors integrated as a single logical component. As shown in fig. 1, the processor 102 may include a plurality of processors 103A, 103B, and 102c.
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 used to simulate the 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., program instructions for implementing the simulation method of the present application) as well as data to be processed (e.g., the memory may store temporary code generated during compilation). The processor 102 may also access program instructions and data stored in the memory and execute the program instructions to perform operations on the data to be processed. The memory 104 may include volatile storage or nonvolatile storage. In some embodiments, memory 104 may include Random Access Memory (RAM), read Only Memory (ROM), optical disks, magnetic disks, hard disks, solid State Disks (SSD), flash memory, memory sticks, and the like.
The network interface 106 may be configured to provide communication with other external devices to the host 100 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 foregoing. It will be appreciated 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, receivers, modems, routers, gateways, adapters, cellular network chips, etc.
The peripheral interface 108 may be configured to connect the 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, touchpads, touch screens, microphones, various types of sensors, and output devices such as displays, speakers, vibrators, and indicators.
Bus 110 may be configured to transfer information between the 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), etc.
It should be noted that, although the above-described 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 proper operation. Furthermore, it will be understood by those skilled in the art that the above-described host architecture may include only components necessary for implementing the embodiments of the present application, and not all components shown in the drawings.
FIG. 2A shows a schematic diagram of a simulation tool 202 and a debug tool 200 in accordance with an embodiment of the present application. The emulation tool 202 and the debug tool 200 may be computer programs running on the host 100.
In the field of chip design, a design may be simulated, typically with simulation tools. The simulation tool may be, for example, galaxSim simulation tool available from core chapter technologies, inc. The example simulation tool 202 illustrated in FIG. 2A may include a compiler 120 and a simulator 220. Compiler 120 may compile the design (e.g., verification system 210) into object code 204, and simulator 220 may simulate based on object code 204 and output simulation results 206. For example, the simulation tool 202 may output simulation results (e.g., simulation waveform diagrams) onto an output device (e.g., displayed on a display) via the peripheral interface 108 of fig. 1.
Debug tool 200 may also read simulation results 206. For example, debug tool 200 may read simulation results 206 stored in a waveform file and generate corresponding simulated waveforms for debugging. Debug tool 200 may also read a description of verification system 210 (typically SystemVerilog and Verilog code) and display to the user. Debug tool 200 may also generate various graphical interfaces to facilitate the user's debugging efforts. The user may issue a debug command to the debug tool 200 (e.g., running the validation system 210 to a certain time), which the debug tool 200 then applies to the simulation tool 202 to execute accordingly.
It is understood that in addition to interfacing with simulation tool 202, debug tool 200 may also interface with hardware simulator (emulator).
Fig. 2B shows a schematic diagram of an exemplary verification system 210 according to an embodiment of the application.
As shown in FIG. 2B, a verification system 210 that simulates in a simulation tool 202 may include a device under test 212 and a verification environment 214. Testing of device under test 212 requires the use of verification environment 214 to provide stimulus signals (e.g., input 216) to device under test 212, and device under test 212 may generate corresponding output signals (e.g., output 218) based on the stimulus signals. In some embodiments, the verification system 210 may include the aforementioned device under test 212 and verification environment 214. In this way, the simulation tool 202 simulates the verification system 210, and a corresponding test result can be obtained finally, so that whether the device under test 212 correctly realizes the function required to be realized can be judged 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. In general, the debug tool 200 may generate connection relationships of the various modules in the device under test 212 from the description of the device under test 212 and further generate a schematic diagram of the device under test 212 (SCHEMATIC DIAGRAM). The schematic diagram for generating 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 in a verification language (e.g., systemVerilog, systemC, PSS language, etc.) for testing the device under test 212. The verification environment 214 may include a plurality of components that implement different functions. In some embodiments, the verification environment 214 may include a signal generation component (Sequencer) 2142, a signal Driver (Driver) 2144, and a signal acquisition component (Monitor) 2146. The signal generating component 2142 may transmit the excitation signal in a particular sequence. The signal driving component 2144 may convert the stimulus signal into a signal receivable by the device under test (e.g., input 216 in fig. 2B) while driving the device under test 212 in accordance with a particular protocol. The signal acquisition component 2146 may collect signals returned from the device under test 212 (e.g., output 218 in fig. 2B) and forward to other components in the verification environment 214 for further processing. In some embodiments, verification environment 214 may also include some other components, such as an interface 2148 for interfacing with device under test 212, an environment component (not shown), a proxy component (not shown), and the like.
Debug tool 200 may generate connection relationships for multiple components in the verification environment from the description of verification language 214 in the verification environment.
In some embodiments, the verification environment 214 may be UVM (Universal Verification Methodology) verification environments. The UVM verification environment may include a plurality of instructions, for example, a connect instruction and a hierarchy instruction. The debug tool 200 may generate connection relationships of multiple components in the UVM verification environment according to connection instructions (connection phase) in the UVM verification environment. The connect instruction is a task of the UVM during operation to connect the plurality of components according to user instructions (i.e., code descriptions). 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 debug tool 200 may determine that the signal driven component 2144 has a connection relationship with the signal generating component 2142 by analyzing the first line statement, more specifically, that the seq_item_port of the signal driven component 2144 is connected with the seq_item_export of the signal generating component 2142. By analyzing the second row of statements, it is determined that the signal driving component 2144 has a connection relationship with the interface component 2148, and more specifically, that the virtual interface vif of the signal driving component 2144 is connected with the virtual interface vif of the interface component 2148.
Accordingly, debug tool 200 may generate a schematic diagram of verification environment 214 from the connection relationships of the various components of verification environment 214.
Since in actual engineering, the verification environment 214 and the device under test 212 are generally used as a verification system as a whole for simulation test, error debugging, etc. Thus, in some embodiments, debug tool 200 need not only generate a schematic diagram of verification environment 214 and device under test 212, but also need to determine the manner of connection between device under test 212 and verification environment 214.
The connection between the device under test 212 and the verification environment 214 is also not an entity such as a wire or fiber optic cable or a simulation thereof, but is 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, a user may define an interface module (e.g., interface module 2122 in FIG. 2B) in the device under test 212 and an interface component (e.g., interface 2148 in FIG. 2B) in the verification environment 214 in communication with the interface module 2122. That is, the interface module and the interface assembly can exchange data with each other.
The interface module and the interface component are combined to form an interface protocol. It is understood that the same interface protocol may support both data (e.g., input 216 in FIG. 2B) from the verification environment 214 to the device under test 212 and data (e.g., output 218 in FIG. 2B) from the device under test 212 to the 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 debug tool 200 may determine the connection relationship of 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 Verilog Procedural Interface (VPI). Debug tool 200 may determine the connection of the verification environment to the device under test based on the VPI invocation and assignment.
Thus, debug tool 200 may determine how data interacts between device under test 212 and verification environment 214 based on the descriptions of device under test 212 and verification environment 214. That is, the debug tool 200 may determine the connection relationship between the device under test 212 and the verification environment 214 from 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 of the verification environment 214 and the device under test 212 and the connection relationship between them, the debug tool 200 may generate a schematic of the verification system.
Fig. 2C illustrates a schematic diagram of an exemplary verification system 220, according to an embodiment of the application. As shown in fig. 2C, the verification system 220 includes a device under test 222 and a verification environment 224. The 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, such as signal generating components 1 and 2, signal driving components 1 and 2, and signal acquisition components 1 and 2. The connections between the various components are shown in phantom. The connection between the device under test 222 and the verification environment 224 is represented by double arrows.
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. The signal propagation path is a propagation path from a signal source that drives a target signal at a target timing 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 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 and select a target time for the target signal on the schematic diagram of the verification system 220.
Fig. 3 illustrates a schematic diagram 300 of an exemplary verification system in accordance with an embodiment of the 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 one time axis. Generally, 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 one of the devices under test. The target signal may be the final output signal of the device under test or a signal of some module inside the device under test. Meanwhile, the signal source is typically a component of the verification environment (e.g., a signal generating component).
In some embodiments, the debug tool 200 may determine at least one upstream signal in the device under test 222 that is related to the drive 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 signals 304a-c and target signal 302.
However, since not every upstream signal can drive the target signal at the target time, the debug tool 200 also needs to determine a signal in which a Value Change (VC) occurs at the target time among the upstream signals. These signals that change in value at the target instant may be referred to as excitation signals.
Which signals change in value at a given time is typically not determinable by analysis of 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, debug tool 200 may look at which upstream signals have changed in value at time T based on actual simulation runs, and find stimulus signals therefrom. For example, in fig. 3, signal 304a is determined to be an excitation signal.
The connection of the target signal 302 and the signal 304a, and the signals therebetween, forms propagation paths 302-304a within the device under test 222.
As described above, debug tool 200 may determine the manner in which device under test 222 is connected to verification environment 224. Thus, debug tool 200 may determine the components connected to the stimulus signal based on the connection and the stimulus signal described above. As shown in fig. 3, debug tool 200 may determine that interface 306 of signal driven component 1 is connected to signal 304 a. Connecting the signal 304a with the interface 306 of the signal driving assembly 1 forms propagation paths 304a-306 between the device under test 222 and the 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 from data assignment relationships, etc. in the description of the verification environment. For example, debug tool 200 may determine that signal generating component 1 is a signal source. Connecting the interface 308 of the signal generating assembly 1 with the interface 306 of the signal driving assembly 1 forms propagation paths 306-308 within the verification environment 224.
The 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.
Debug tool 200 may highlight the signal propagation paths 302-308 on schematic 300. In some embodiments, the signal propagation paths 302-308 may be displayed in a highlighted, bolded, etc. manner. Shown exemplarily in bold in fig. 3. In this way, the user can clearly see how the signal of the drive target signal 302 is gradually transferred from the verification environment at the time T. The user may further select a component in the verification environment or a module in the device under test to observe how the signal propagation paths 302-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 input AND second input) AND gate, when the first input 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 at some time T+n the first input becomes "1". For the case where the user selects time T, the debugging device 200 may prompt the user that there is a signal propagation path of 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 a verification system according to an embodiment of the application. The method 400 may be performed by the host 100 of fig. 1. The method 400 may include the following steps.
At step 402, the host 100 may generate a schematic diagram of the authentication system (as shown in FIG. 2C) from a description of the authentication system (e.g., authentication system 210 of FIG. 2B). The description of the verification system includes a description of the device under test (e.g., device under test 222 of FIG. 3) and a description of the verification environment (e.g., verification environment 224 of FIG. 3). The verification environment may be UVM (Universal Verification Methodology) verification environments.
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 the 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, which is a component of the verification environment. The signal source is a signal generating component (sequencer)
At step 406, host 100 may determine a signal propagation path (e.g., paths 302-308 of FIG. 3) that drives the target signal at the target time. In some embodiments, determining the signal propagation path for driving the target signal at the target time further includes 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 based on a description of the device under test, determining an excitation signal (e.g., signal 304a of FIG. 3) that changes value at the target time in the at least one upstream signal, determining an interface component (e.g., interface 306 of signal driving component 1 of FIG. 3) that drives an authentication environment of the excitation signal based on a description of the authentication system that includes a manner in which the authentication environment is connected to the device under test, and determining the signal source that drives the interface component based on the description of the authentication environment.
In some embodiments, determining an excitation signal in the at least one upstream signal that has a value change at the target time further comprises operating 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.
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 that drives the target signal at the target time further includes determining the first propagation path including the excitation signal and the target signal based on a description of the device under test, determining the second propagation path including the excitation signal and the interface component based on a connection of the verification environment to the device under test, and determining the third propagation path including the interface component and the signal source based on a description of the verification environment.
At step 408, the host 100 may highlight the signal propagation path in the schematic diagram.
It should be noted that the method of the present application may be performed 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 is completed by mutually matching a plurality of devices. In the case of such a distributed scenario, one of the devices may perform only one or more steps of the method of the present application, the devices interacting with each other to complete the method.
The embodiment of the application also provides an electronic device comprising a memory for storing a set of instructions, and at least one processor configured to execute the shuffling instructions to cause the computing apparatus to perform the method 400 provided by the embodiment of the application.
Embodiments of the present application also provide a non-transitory computer readable storage medium storing a set of instructions for a computer, which when executed, are configured to cause the computer to perform the method 400 provided by the embodiments of the present application.
The foregoing describes some embodiments of the present application. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can 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 are also possible or may be advantageous.
It will be appreciated by persons skilled in the art that the foregoing discussion of any embodiment is merely exemplary and is not intended to imply that the scope of the application (including the claims) is limited to these examples, that combinations of technical features in the foregoing embodiments or in different embodiments may be implemented in any order and that many other variations of the different aspects of the application as described above may exist within the spirit of the application, and that they are not provided in detail for clarity.
While the application has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of those embodiments will be apparent to those skilled in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the embodiments discussed.
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 omission, modification, equivalent replacement, improvement, etc. of the present application should be included in the scope of the present application.
Claims (8)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111627227.5A CN114548027B (en) | 2021-12-28 | 2021-12-28 | Method, electronic device and storage medium for tracking signals in verification system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111627227.5A CN114548027B (en) | 2021-12-28 | 2021-12-28 | Method, electronic device and storage medium for tracking signals in verification system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114548027A CN114548027A (en) | 2022-05-27 |
| CN114548027B true CN114548027B (en) | 2025-04-15 |
Family
ID=81669280
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111627227.5A Active CN114548027B (en) | 2021-12-28 | 2021-12-28 | Method, electronic device and storage medium for tracking signals in verification system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114548027B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115470751B (en) * | 2022-09-22 | 2023-06-06 | 沐曦科技(北京)有限公司 | Tracking information generation system based on memory database |
| CN116401989B (en) * | 2023-06-09 | 2023-08-15 | 成都融见软件科技有限公司 | Signal checking method based on chip design source code, electronic equipment and medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106980311A (en) * | 2016-01-15 | 2017-07-25 | 帝斯贝思数字信号处理和控制工程有限公司 | Signal path verifying attachment |
| CN113378502A (en) * | 2021-08-11 | 2021-09-10 | 中科亿海微电子科技（苏州）有限公司 | Test method, device, medium and equipment for verifying signal trend code matching |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2872076B2 (en) * | 1995-04-27 | 1999-03-17 | 日本電気アイシーマイコンシステム株式会社 | Logic verification apparatus and method |
| US5903577A (en) * | 1997-09-30 | 1999-05-11 | Lsi Logic Corporation | Method and apparatus for analyzing digital circuits |
-
2021
- 2021-12-28 CN CN202111627227.5A patent/CN114548027B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106980311A (en) * | 2016-01-15 | 2017-07-25 | 帝斯贝思数字信号处理和控制工程有限公司 | Signal path verifying attachment |
| CN113378502A (en) * | 2021-08-11 | 2021-09-10 | 中科亿海微电子科技（苏州）有限公司 | Test method, device, medium and equipment for verifying signal trend code matching |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114548027A (en) | 2022-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114548027B (en) | Method, electronic device and storage medium for tracking signals in verification system | |
| CN114168200B (en) | System and method for verifying memory access consistency of multi-core processor | |
| CN111624475B (en) | Method and system for testing large-scale integrated circuit | |
| CN117112447B (en) | Data transmission method and device, electronic equipment and readable storage medium | |
| CN112286750A (en) | GPIO (general purpose input/output) verification method and device, electronic equipment and medium | |
| CN115470125B (en) | Log file-based debugging method, device and storage medium | |
| US20060212768A1 (en) | Verification circuitry for master-slave system | |
| CN117910398B (en) | Method, electronic device and storage medium for designing simulation logic system | |
| CN116594830B (en) | Hardware simulation tool, debugging method and storage medium | |
| CN116151187B (en) | Method, apparatus and storage medium for processing trigger condition | |
| CN115510782B (en) | Method for locating verification errors, electronic device and storage medium | |
| US20240184967A1 (en) | Focused testing and verification of circuit designs using hardware description language simulation | |
| CN116911219A (en) | Method, electronic device and storage medium for simulation of logic system design | |
| CN113177388B (en) | Apparatus, system and method for IP core testing and verification | |
| CN115906730A (en) | Method, device and storage medium for verifying logic system design | |
| CN115732025A (en) | Method and device for verifying RAM access conflict | |
| CN114169287B (en) | Method for generating connection schematic diagram of verification environment, electronic equipment and storage medium | |
| CN114186396A (en) | Simulation test method, device, equipment and system for chip | |
| CN117332733B (en) | A method, device and storage medium for locating errors in logic system design | |
| US7277840B2 (en) | Method for detecting bus contention from RTL description | |
| CN117454835B (en) | Method for storing and reading waveform data, electronic device and storage medium | |
| CN117172203B (en) | Method for processing script commands, electronic device and storage medium | |
| CN117313596B (en) | Method, equipment and storage medium for positioning errors of logic system design | |
| CN117933155B (en) | A multi-process joint simulation system and method, electronic device and storage medium | |
| CN115292102B (en) | Simulation method, electronic device, and readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |