CN116933707B - Test method, device, equipment and medium for design circuit - Google Patents
Test method, device, equipment and medium for design circuit Download PDFInfo
- Publication number
- CN116933707B CN116933707B CN202311197916.6A CN202311197916A CN116933707B CN 116933707 B CN116933707 B CN 116933707B CN 202311197916 A CN202311197916 A CN 202311197916A CN 116933707 B CN116933707 B CN 116933707B
- Authority
- CN
- China
- Prior art keywords
- test
- circuit
- design circuit
- output result
- lua
- 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
- 238000013461 design Methods 0.000 title claims abstract description 161
- 238000010998 test method Methods 0.000 title claims abstract description 10
- 238000012360 testing method Methods 0.000 claims abstract description 306
- 238000004088 simulation Methods 0.000 claims abstract description 136
- 230000006870 function Effects 0.000 claims description 76
- 238000000034 method Methods 0.000 claims description 51
- 230000001960 triggered effect Effects 0.000 claims description 20
- 230000008569 process Effects 0.000 claims description 18
- 230000004044 response Effects 0.000 claims description 11
- 239000012634 fragment Substances 0.000 claims description 4
- 238000012545 processing Methods 0.000 description 16
- 238000004891 communication Methods 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 9
- 230000000630 rising effect Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000012546 transfer Methods 0.000 description 7
- 230000006399 behavior Effects 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 4
- 238000005070 sampling Methods 0.000 description 4
- 230000005236 sound signal Effects 0.000 description 4
- 101100457838 Caenorhabditis elegans mod-1 gene Proteins 0.000 description 3
- 101150110972 ME1 gene Proteins 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000011056 performance test Methods 0.000 description 3
- 230000001133 acceleration Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000005192 partition Methods 0.000 description 2
- 238000003672 processing method Methods 0.000 description 2
- 241000220317 Rosa Species 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000000654 solvent vapour annealing Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012795 verification 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/32—Circuit design at the digital level
- G06F30/333—Design for testability [DFT], e.g. scan chain or built-in self-test [BIST]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- Quality & Reliability (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
The application provides a test method, a device, equipment and a medium for a design circuit, which relate to the technical field of circuit test and comprise the following steps: acquiring a file to be tested and a test case; the test cases comprise circuit input data, and the test cases are obtained by describing test tasks of a designed circuit through the Lua language; inputting a file to be tested into a test case, executing the file to be tested based on circuit input data and a test task in the test case, and obtaining a simulation output result aiming at a designed circuit; and obtaining a test result of the design circuit according to the simulation output result. The test case based on Lua language description tests the design circuit of the file to be tested, and the test efficiency of the design circuit is improved.
Description
Technical Field
The present disclosure relates to the field of design circuit testing technologies, and in particular, to a method, an apparatus, a device, and a medium for testing a design circuit.
Background
When designing a circuit using a hardware description language (Verilog Hardware Description Language, verilog HDL), it is necessary to test the performance of the designed circuit.
In the prior art, performance tests of the designed circuit can be performed based on Verilog language or based on Python language.
However, verilog language is mainly used for hardware description, and has a problem of low test efficiency when performing performance test on a design circuit such as an application specific integrated circuit (Application Specific Integrated Circuit). The Python language is a script language with complex bottom layer, and when the performance test of the design circuit is performed, the simulation speed of the design circuit is affected, so that the problem of low test efficiency is caused.
Disclosure of Invention
The embodiment of the application provides a test method, a test device, test equipment and test media for a design circuit, which are used for solving the problem of low test efficiency of the design circuit in the prior art.
In a first aspect, embodiments of the present application provide a test method for designing a circuit, the method including:
acquiring a file to be tested and a test case; the test case comprises circuit input data, and is obtained by describing a test task of the design circuit through a Lua language; inputting the file to be tested into the test case, executing the file to be tested based on circuit input data and test tasks in the test case, and obtaining a simulation output result aiming at the design circuit; and obtaining a test result of the design circuit according to the simulation output result.
In a second aspect, embodiments of the present application provide a test apparatus for designing a circuit, the apparatus including:
the first acquisition module is used for acquiring a file to be tested and a test case; the test case comprises circuit input data, and is obtained by describing a test task of the design circuit through a Lua language; the second acquisition module is used for inputting the file to be tested into the test case, executing the file to be tested based on circuit input data and test tasks in the test case, and acquiring a simulation output result aiming at the design circuit; and the third acquisition module is used for acquiring the test result of the design circuit according to the simulation output result.
In a third aspect, embodiments of the present application further provide an electronic device, including a processor;
a memory for storing the processor-executable instructions;
wherein the processor is configured to execute the instructions to implement the method of the first aspect.
In a fourth aspect, embodiments of the present application also provide a computer-readable storage medium, which when executed by a processor of an electronic device, causes the electronic device to perform the method of the first aspect.
In the embodiment of the application, a file to be tested is obtained, a test case obtained by describing a test task of a design circuit through Lua language is obtained, the file to be tested is input into the test case, the file to be tested is executed based on circuit input data and the test task in the test case, a simulation output result aiming at the design circuit is obtained, and the test result of the design circuit is obtained according to the simulation output result. The method adopts the Lua language to describe the test task of the design circuit to obtain the test case, and tests the design circuit of the file to be tested based on the test case described by the Lua language, so that the test efficiency of the design circuit is improved in the test process of the design circuit, and the problem of low test efficiency of the design circuit in the related technology is solved.
The foregoing description is only an overview of the technical solutions of the present application, and may be implemented according to the content of the specification in order to make the technical means of the present application more clearly understood, and in order to make the above-mentioned and other objects, features and advantages of the present application more clearly understood, the following detailed description of the present application will be given.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort to those of ordinary skill in the art.
FIG. 1 is a flow chart of steps of a testing method for a design circuit according to an embodiment of the present invention;
FIG. 2 is a flowchart illustrating steps of another method for testing a design circuit according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of a file to be tested according to an embodiment of the present application;
FIG. 4 is a flow chart of steps of a data processing method of a simulator and a Lua scheduler provided in an embodiment of the present application;
FIG. 5 is a flowchart illustrating steps of a test method for designing a circuit according to another embodiment of the present application;
FIG. 6 is a block diagram of a test apparatus for designing a circuit according to an embodiment of the present invention;
FIG. 7 is a block diagram of an electronic device provided by an embodiment of the present invention;
fig. 8 is a block diagram of another electronic device in accordance with another embodiment of the invention.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
The terms first, second and the like in the description and in the claims, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged, as appropriate, such that embodiments of the present application may be implemented in sequences other than those illustrated or described herein, and that the objects identified by "first," "second," etc. are generally of a type and not limited to the number of objects, e.g., the first object may be one or more. Furthermore, the term "and/or" as used in the specification and claims to describe an association of associated objects means that there may be three relationships, e.g., a and/or B, may mean: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship. The term "plurality" in the embodiments of the present application means two or more, and other adjectives are similar thereto.
When designing a circuit, the structure and the behavior of the designed circuit can be described through a Verilog language to obtain a file to be tested, a test task for testing the designed circuit is described through a Lua language to obtain a test case, the designed circuit in the file to be tested is tested through the test case, and the designed circuit is optimized according to the test result of the designed circuit to obtain the designed circuit meeting the requirements of users.
The test method of the design circuit provided by the embodiment of the application is described in detail below by means of specific embodiments and application scenes thereof with reference to the accompanying drawings.
Fig. 1 is a flowchart of steps of a testing method for a design circuit according to an embodiment of the present application, as shown in fig. 1, the method may include:
and step 101, acquiring a file to be tested and a test case.
In this step, the test file is a file obtained by describing the structure and behavior of the designed circuit through the Verilog HDL language.
Specifically, the test case includes circuit input data, and the test case is a case obtained by describing a test task of a design circuit through the Lua language.
Further, the number of test cases may be one or plural. Each test case has a corresponding test task.
Step 102, inputting a file to be tested into a test case, and executing the file to be tested based on circuit input data and test tasks in the test case to obtain a simulation output result aiming at a designed circuit.
In some embodiments, circuit input data in a test case is configured to a design circuit in a file to be tested through a simulator, the file to be tested is executed according to a test task corresponding to the test case, and a simulation output result aiming at the design circuit in the file to be tested is obtained.
And step 103, obtaining a test result of the design circuit according to the simulation output result.
In some embodiments, the test result of the design circuit is determined according to the simulation output result and the preset output result of the design circuit.
In summary, in the embodiment of the application, a file to be tested is obtained, a test case obtained by describing a test task of a design circuit through Lua language is input into the test case, the file to be tested is executed based on circuit input data and the test task in the test case, a simulation output result aiming at the design circuit is obtained, and a test result of the design circuit is obtained according to the simulation output result. The method adopts the Lua language to describe the test task of the design circuit to obtain the test case, and tests the design circuit of the file to be tested based on the test case described by the Lua language, so that the test efficiency of the design circuit is improved in the test process of the design circuit, and the problem of low test efficiency of the design circuit in the related technology is solved.
Fig. 2 is a flowchart of specific steps of a testing method for a design circuit according to an embodiment of the present application, and as shown in fig. 2, the method may include:
step 201, obtaining a file to be tested and a test case.
The test case comprises circuit input data, and the test case is obtained by describing test tasks of a designed circuit through the Lua language.
In one embodiment, in a test case, the circuit signals of the design circuits in the file to be tested are described in terms of a path agent table. Referring to the schematic diagram of the file structure to be tested shown in fig. 3, the file to be tested Top includes a subfile mod_0 and a subfile mod_1, where the subfile mod_1 includes a subfile mod_2. When "dut" is used to denote the file to be tested Top, then when one of the input data in_0 of the subfile mod_2 is described in the test case, the input data may be denoted as dut.mod_1.mod_2.in_0. Based on the description mode, the circuit signal of the design circuit can be visually represented through the form of object attribute access, so that the layering expression of the file to be tested is realized.
It should be noted that, when describing the circuit signal of the design circuit in the file to be tested according to the path proxy table, the meta-table characteristic in Lua is used on the underlying process, when a new proxy object needs to be created, or the circuit signal described based on the path proxy table is accessed, or the circuit signal described based on the path proxy table is assigned, the Lua end will call the meta-method corresponding to the meta-table to create the new proxy object, or by calling the VPI interface of the underlying layer, the signal value of the circuit signal is read, or the signal value of the circuit signal is written. Based on the processing method, a user can intuitively understand the circuit signals described in the test case.
The method for obtaining the file to be tested and the test case is described in step 101, and will not be described here again.
Step 202, stopping executing the test case and generating an instruction for indicating circuit simulation when a task handover event preset in the test case is triggered by the Lua scheduler.
In this step, a preset task transfer event is set according to the test task in the test case. The task handover event is exemplarily described below.
In one embodiment, the test tasks of the test case include obtaining a simulation output result "duc.out" of the design circuit according to circuit input data "duc.in_0" and "duc.in_1" of the design circuit, and performing a design circuit test according to the simulation output result "duc.out", where in a simulation process of the design circuit, after values of the circuit input data "duc.in_0" and "duc.in_1" are configured to the design circuit, one clock cycle needs to be waited to obtain the simulation output result "duc.out" of the design circuit. In this case, the task handover event may be set to wait for one clock period "await_clock ()".
Correspondingly, when a task handover event 'await_clock ()' is triggered by the Lua scheduler, stopping executing the instruction after the task handover event instruction in the test case, and generating an instruction for indicating circuit simulation so as to give control right to the simulator, and further, performing simulation of a design circuit by the simulator to obtain a simulation output result.
In step 203, in response to the instruction indicating the circuit simulation, the simulator configures the circuit input data as the input data of the design circuit, and performs the simulation of the design circuit, thereby obtaining the simulation output result.
In this step, the simulator is a Verilog simulator, and the specific type of simulator is not limited herein, and may be, for example, a compiled Verilog simulator (Compiled Verilog Simulator, VCS), an icrus Verilog, a Verilog, or other Verilog simulator.
In one embodiment, in response to an instruction indicating circuit emulation, a callback function corresponding to a task handover event is registered by an emulator, and emulation of a designed circuit is performed by the emulator. The callback function may be set according to a test task in the test case and a design circuit in the file to be tested, for example, the callback function may be signal jump, delay a simulation event, and wait.
In the circuit simulation process through the simulator, after a stopping event corresponding to the callback function is triggered, the simulation output result of the design circuit is stored in a preset memory area, and a wake-up function for indicating the Lua dispatcher to continue to execute the test case is registered, so that control right is transferred to the Lua dispatcher.
And 204, obtaining a test result of the design circuit according to the simulation output result through the Lua scheduler.
In the step, a simulation output result in the simulator is obtained through the Lua dispatcher, and a test result of the design circuit is obtained according to the simulation output result.
In this embodiment, the file to be tested is obtained by describing the structure and behavior of the design circuit by using Verilog language, and the test task of the design circuit is described by using Lua language to obtain a test case, so as to test the design circuit. In the process, the Lua language is used as a Verilog simulation scheduling framework, and based on the VPI interface and the LuaBridge provided by the Verilog, the Lua can call functions of the C language or the C++ language in the simulator, and then the VPI interface is called in the Lua, so that signal acquisition is realized. For example, the simulation output data stored in the simulator may be obtained through a VPI interface.
In summary, in the embodiment of the present application, the test case is a case obtained by describing a test task of a design circuit in a file to be tested through the Lua language, when a task handover event preset in the test case is triggered through the Lua scheduler, the execution of the test case is stopped, the simulation of the design circuit is performed through the simulator, a simulation output result is obtained, and then the test result of the design circuit is obtained through the Lua scheduler according to the simulation output result. When a task transfer event preset in the test case is triggered by the Lua scheduler, control right is handed over to the simulator so as to simulate a design circuit by the simulator, after the simulator obtains a simulation output result, the control right is handed back to the Lua scheduler so as to continuously execute the test case by the Lua scheduler, and the purposes of taking the Lua language as a simulation scheduling frame and testing the design circuit in the file to be tested are achieved.
In one embodiment, step 204 may include the sub-steps of:
in sub-step 2041, in the case that the simulation output result meets the preset output result requirement, the test result of the design circuit is determined to pass the test.
In one embodiment, whether the simulation output result meets the preset output result requirement is determined according to the simulation output result and the preset simulation result. The preset simulation result is a preset value of a result output by a user expected to design the circuit.
In sub-step 2042, if it is determined that the simulation output result does not meet the preset output result requirement, it is determined that the test result of the design circuit fails the test.
In practical application, under the condition that the simulation output result is determined to be not in accordance with the preset output result requirement, determining that the test result of the design circuit is not passing the test, optimizing the design circuit in the file to be tested according to the test result, and testing the optimized design circuit to obtain the design circuit in accordance with the preset output result requirement.
In one embodiment, after step 203, further comprising:
and 205, stopping executing the simulation of the design circuit when a preset stopping event is triggered by the simulator, obtaining a simulation output result, and registering a wake-up function for indicating to continue executing the test case.
In this step, the stop event is an event corresponding to a task transfer event in the test case, and the stop event may be used to indicate that the simulation task corresponding to the task transfer event is completed.
In one embodiment, a correspondence between a task handover event and a stop event may be set according to a structure and a behavior of a design circuit and a test task of a test case, and a stop event corresponding to the task handover event may be determined according to the correspondence. Illustratively, the stop event may include an edge trigger event, which may include a rising edge trigger event, a falling edge trigger event, or a double edge trigger event, and further, the Verilog process interface (Verilog Procedural Interface, VPI) trigger type corresponding to the edge trigger event is cbValueChange. The stop event may further include a time trigger event, and further, the VPI trigger type corresponding to the time trigger event is cbAfterDelay. The stop event may further include a read-write domain trigger event, and further, the VPI trigger type corresponding to the read-write domain trigger event is cbReadWriteSynch.
An exemplary explanation of a stop event is provided below: in one embodiment, the task handover event in the test case is waiting for one clock period "await_clock ()", and the stop event corresponding to the task handover event may be an edge trigger event. The edge trigger event may be a rising edge, a falling edge, or a double edge, for example.
In one embodiment, the edge trigger event is a rising edge, and correspondingly, in the process of performing circuit simulation by the simulator, when the circuit simulation of one clock cycle is completed when the circuit simulation is triggered to the rising edge, a simulation output result can be obtained.
In step 206, in response to the wake-up function, the Lua scheduler is switched to continue executing the test case.
In this embodiment, when a preset stop event is triggered by the simulator, the simulation of the design circuit is stopped, a simulation output result is obtained, a wake-up function is registered, and in response to the wake-up function, control rights are handed over from the simulator to the Lua scheduler, the Lua scheduler continues to execute test cases, and the Lua scheduler can perform the test of the design circuit based on the simulation output result obtained by the simulation of the design circuit.
In some embodiments, after triggering the task handover event preset in the test case by the Lua scheduler in step 202, the method further includes:
in step 207, a callback function generation instruction is generated by the Lua scheduler, where the callback function generation instruction is used to instruct to register a callback function corresponding to the task handover event.
In this step, a callback function generation instruction is generated by the Lua scheduler,
And step 208, registering a callback function through the simulator, and determining a stopping event corresponding to the task handover event according to the callback function.
For example, the task handover event is waiting for one clock cycle, and the callback function registered by the emulator is used to represent waiting for one clock cycle, and the stop event corresponding to the handover task event may be waiting for a rising edge of the clock signal. In this embodiment, a rising edge occurs on the clock signal, which indicates that the circuit simulation has completed one clock cycle. It should be noted that the stop event in this embodiment may also be a falling edge of the waiting clock signal, or other events that may indicate that the circuit simulation completes one clock cycle.
In some embodiments, the callback function generation instruction includes identification information of the test case, and correspondingly, the wake function registered by the emulator in step 205 for indicating to continue to execute the test case may include the following sub-steps:
in a substep 2051, a wake-up function including identification information is registered by the emulator.
In one embodiment, after the task handover event is triggered by the Lua scheduler, when a callback function generation instruction is generated, identification information of the test case is sent to the simulator. And when a preset stopping event is triggered by the simulator, a wake-up function of the Lua scheduler is called in the callback function, and the wake-up function can acquire the identification information from the user data.
Correspondingly, in step 206, the test case is continuously executed by the Lua scheduler, including the following sub-steps:
sub-step 2061, in response to the wake-up function, continues execution of the test case corresponding to the identification information by the Lua scheduler.
In this step, the Lua scheduler determines a test case corresponding to the identification information from the identification information, and continues to execute the test case.
In this embodiment, the simulator registers the wake-up function including the identification information for identifying the test case, and the Lua scheduler continues to execute the test case corresponding to the identification information, so that the control right is handed over to the Lua scheduler.
In some embodiments, the test cases are multiple, and the test cases are coroutines.
It should be noted that, a Coroutine (Coroutine) is a program component, and in the case that the test cases are coroutines, the simulator may process multiple test cases in parallel.
Correspondingly, executing the file to be tested by the simulator in step 203, obtaining the simulation output result for the design circuit may include the following sub-steps:
sub-step 2031, when a task handoff event preset in the currently executed test case is triggered by the Lua scheduler, stops executing the current test case and starts executing other at least partially unexecuted test cases in parallel.
In this step, when the Lua scheduler triggers a task handover event preset in the currently executed test cases, the execution of the current test case is stopped, and the parallel execution of other at least part of the test cases that are not executed is started, so that the parallel execution of a plurality of test cases can be realized.
Referring to fig. 4, the lua scheduler includes three parts: task iterators, task handover events, and VPI interfaces. In the case of executing a plurality of test cases by the Lua scheduler, the Lua scheduler first enters a task iterator, and polls and invokes the test cases corresponding to each test task, for example, the test tasks may include a test task 1 and a test task 2, and the test tasks N total N test tasks, where each test task corresponds to a test case described based on Lua language. It should be noted that, through the task iterator in the Lua scheduler, serial scheduling of a plurality of test tasks can be realized, but based on the characteristic of test case corutine cooperative procedure corresponding to the test tasks in the application, event-level parallel processing can be realized through the Lua scheduler, which is specifically expressed as follows: and processing the test cases corresponding to the plurality of test tasks in parallel, wherein each test case is independently executed and shares the state of the same simulator. Further, the state that each test case shares the same simulator includes: before the stop event is triggered by the simulator, the information value of the same circuit information used by each test case is the same, after the stop event is triggered by the simulator, the information value of the circuit information is updated, and then each test case uses the updated information value of the circuit information.
The Lua dispatcher executes test tasks corresponding to the test cases in parallel, after a task handover event in any one test case is triggered, the execution of the test case is stopped, an instruction for indicating the simulator to register a callback function is generated, the simulator registers the VPI callback function through a VPI interface in response to the instruction, and design circuit simulation is performed, so that the controller is handed over from the Lua dispatcher to the simulator. In the process of circuit simulation by the simulator, after triggering a stopping event corresponding to the VPI callback function, generating a wake-up function, responding to the wake-up function, and continuing to execute the test case executed by the Lua scheduler before interrupting, thereby realizing the transfer of control rights from the simulator to the Lua scheduler. Based on the processing steps of the Lua scheduler and the simulator shown in FIG. 3, the scheduling of each test case by the Lua scheduler and the transfer of control rights between the Lua scheduler and the simulator are realized, and based on the scheduling of each test case by the Lua scheduler and the transfer of control rights between the scheduler and the simulator, the test of a design circuit by adopting the Lua language as a Verilog simulation scheduling frame is realized.
Sub-step 2032, after registering, by the emulator, a wake function indicating that execution of the current test case is continued, concurrently executing, by the Lua scheduler, the current test case and other executing test cases in response to the wake function.
In this step, after a wake-up function for instructing to continue execution of the current test case is registered by the emulator, the execution of the current test case stopped before the execution is continued by the Lua scheduler in response to the wake-up function, and other test cases being executed are not interrupted.
In some embodiments, prior to step 204, further comprising:
step 209, obtaining a simulation output result for the design circuit through the simulator, and storing the simulation output result in a memory chip area of the simulator memory.
In the step, circuit input data in the test case is configured as input data of a design circuit through a simulator, and the design circuit is simulated, so that a simulation output result is obtained.
Step 210, obtaining, by the emulator, a first handle for indicating the address of the memory partition, and converting the first handle into a second handle corresponding to the Lua language.
In this step, the simulation output result is stored in a memory patch of the simulator by the simulator, and a first handle corresponding to the memory patch is acquired.
In one embodiment, the program language of the emulator is C language or c++ language, and the first handle obtained by the emulator is a pointer that can be stored in C language or c++ language and is used for indicating the address of the memory partition, and Lua cannot directly store the first handle in C language or c++ language. In order to store the first handle in Lua, the first handle needs to be converted into a second handle corresponding to Lua language.
Illustratively, the first handle obtained by the emulator is a Struct type handle, which may be stored in C++ but not in Lua. And converting the first handle of the Struct type into a second handle of the longLong type which can be stored by Lua through the characteristic of a C++ encoder in the simulator, so as to store by Lua.
Step 211, storing the second handle by the Lua scheduler, and converting the second handle into the first handle when executing the instruction for obtaining the simulation output result for the design circuit, and extracting the simulation output result from the memory fragment according to the first handle.
In this step, when the Lua scheduler executes an instruction for obtaining a simulation output result of the design circuit, the second handle is converted into the first handle by the simulator, an address for storing the simulation output result is determined according to the first handle, and the simulation output result is extracted from the memory fragment according to the address.
For example, when the Lua scheduler executes an instruction for obtaining a simulation output result of the design circuit, the Lua scheduler converts the second handle of the LongLong type into a first handle of a Struct type which can be stored by c++ by adopting the characteristic of an encoder of c++ in the simulator, so as to obtain the simulation output result in the memory according to the first handle.
In some embodiments, after step 203, further comprising:
step 212, generating log data according to one or more of circuit input data of the design circuit, simulation output result, clock period data of the design circuit and intermediate data generated in the process of executing the file to be tested.
In this step, according to the user's demand, one or more kinds of data are selected from the circuit input data of the design circuit, the simulation output result, the clock cycle data of the design circuit, and the intermediate data generated in the process of executing the file to be tested, thereby generating log data.
In step 213, the log data is stored in the level db database.
The level DB is an open source Key-Value database. Specifically, the data stored in the level db database includes a signal (Key) in log data, and a corresponding signal Value (Value).
In one embodiment, the signals corresponding to the preset clock period are stored in a level db database, and the signal values of the signals, the level db database storing the data may be marked as a SignalDB file. Further, a corresponding VPI Callback function may be registered in the Lua scheduler for the SignalDB to obtain a signal value of the design circuit signal through the SignalDB in response to the VPI Callback function. After the simulation of one clock cycle is completed, the simulation output result of the design circuit can be obtained, and then a new signal value of a signal corresponding to the clock cycle is obtained, so that the time granularity for triggering the VPI Callback function can be set as each simulated clock cycle, and the storage of the signal value of the signal of each clock cycle is realized.
It should be noted that the SignalDB does not record the signal values of all signals in the design circuit simulation process, but records the signal values of the signals in the log data.
In one embodiment, a log generation task for generating log data is described by the Lua language, and the log data is generated based on the log generation task.
In practical application, a preset signal table callback signaltable is constructed through Lua language, wherein the preset signal table callback signaltable is used for storing a handle indicating an address where a user needs data. Specifically, when the API of the user-required data stored in the SignalDB is called, a handle for indicating the user-required data storage address is added to the preset signal table CallbackSignalTable.
Further, generating the signalDB file based on the log data recorded by the LevelDB database may implement advanced usage supported by, for example, systemVerilog, for example, a sampling function of the following sampling function may be implemented: past, stable, rose, fell, changed. In the process of testing the performance of the design circuit, it is generally necessary to verify the signal values of some circuit signals of the design circuit, sample the information values of the circuit signals by a sampling function, and test the design circuit based on the signal values of the circuit signals obtained by sampling.
In addition, a signalDB file is generated based on log data recorded by the LevelDB database, and data such as historical signal values, trigger signal conditions and the like of circuit signals required by users are recorded, so that an assertion checking function of Systemverilog assertion (Systemverilog assertion, SVA) can be realized. It should be noted that, SVAs are called sequence detectors or sequence verifiers, which are descriptions of how specific circuit behaviors should be performed when designing a circuit, and can view anomalies of the designed circuit behaviors when simulating the circuit.
Enriches the functions of the Verilog verification framework in the Lua language
In this embodiment, log data is generated according to user selection and stored in a level db database, so that the problem of large data recording overhead caused by storing all design circuit simulation data is avoided. In addition, the log data is stored by the LevelDB database, so that the memory space for storing the log data in the memory of the simulator can be saved.
Fig. 5 is a flowchart of steps of a method for testing a design circuit according to an embodiment of the present application, and referring to fig. 5, the method for testing a design circuit may include the following steps:
step S1, simulation starts.
In this step, a test file describing the design circuit by Verilog language and a test case describing the test task of the design circuit by Lua language are compiled by a simulator.
Step S2, initializing VPI startup callback and VPI cleanup callback by the emulator, and registering the Lua virtual machine.
In this step, the Lua runtime environment is created by initializing VPI startup callback and VPI cleanup callback by the emulator and registering the Lua virtual machine.
And S3, calling an initializing function of the Lua end through the simulator, and giving control right to the Lua dispatcher.
In this step, based on the Lua-side simulation entry, control is given to the Lua scheduler by the simulator to execute the Lua-side control code by the Lua scheduler, specifically, to execute each test case by polling by the Lua scheduler.
And S4, executing the test case through the Lua scheduler.
In the step, the Lua end schedules the Lua control code of the Lua end through a Lua scheduler, wherein the Lua control code of the Lua end comprises codes of a plurality of test cases, and each test case is used for executing a test task for testing a design circuit. That is, the Lua control code of the Lua end may be composed of a plurality of test cases corresponding to a plurality of test tasks, where each test task is a Coroutine protocol. In the process of carrying out the design circuit simulation, the simulator acquires a simulation output result when triggering a stop event so as to update the design circuit information, the circuit information read by each test task is the same before the simulation output result, and the circuit information before the simulation output result is updated is the same as the circuit information before the simulation output result is updated.
And S5, triggering a task handover event in the test case through the Lua scheduler, and transferring control right to the simulator to interrupt the execution of the test case.
In this step, by transferring control to the simulator to perform circuit simulation by the simulator, the Lua scheduler terminal executes a test case to wait for the simulator to trigger a stop event corresponding to a task handover event, which is a simulation event corresponding to a task handover event.
Step S6, registering the callback function through the simulator.
In this step, a callback function is registered through the VPI interface, the callback function corresponding to the task handover event. Illustratively, the task handoff event is waiting for one clock cycle, the callback function is used to wait for a stop event indicating completion of one clock cycle, e.g., the stop event may be a rising edge trigger event in an edge trigger event, and then the callback function is used to wait for a rising edge of the emulated signal.
And S7, performing circuit simulation through a simulator.
In this step, the design circuit in the file to be tested is subjected to circuit simulation by the simulator.
And S8, processing the CallBack scheduling by the simulator and giving control to the Lua scheduler.
In this step, by detecting a stop event corresponding to the callback, when the stop event is triggered, control is given to the Lua scheduler.
Step S9, the interrupted test case is continuously executed.
Specifically, when a stop event is triggered by the emulator, a wake-up function is registered, and in response to the wake-up function, the Lua scheduler continues to execute the test task in the previously interrupted test case.
Referring to fig. 6, which shows a testing apparatus for a design circuit provided in an embodiment of the present application, a testing apparatus 30 for a design circuit includes:
the first obtaining module 301 is configured to obtain a file to be tested and a test case; the test case comprises circuit input data, and is obtained by describing a test task of the design circuit through a Lua language; the second obtaining module 302 is configured to input the file to be tested into the test case, and execute the file to be tested based on the circuit input data and the test task in the test case, to obtain a simulation output result for the design circuit; and a third obtaining module 303, configured to obtain a test result of the design circuit according to the simulation output result.
Optionally, the second obtaining module 302 may include:
the generation sub-module is used for stopping executing the test case and generating an instruction for indicating circuit simulation when a task handover event preset in the test case is triggered by the Lua scheduler;
the first acquisition submodule is used for responding to an instruction for indicating circuit simulation, configuring the circuit input data into the input data of the design circuit through the simulator, carrying out simulation of the design circuit and acquiring a simulation output result;
correspondingly, the third acquisition module 303 may include:
and the second acquisition submodule is used for acquiring the test result of the design circuit according to the simulation output result through the Lua dispatcher.
Optionally, the test device 30 for designing a circuit may further include:
the fourth acquisition module is used for stopping executing the simulation of the design circuit when a preset stopping event is triggered by the simulator after the simulation output result is acquired by the simulator, acquiring the simulation output result and registering a wake-up function for indicating the continuous execution of the test case;
and the switching module is used for responding to the wake-up function, switching to the Lua scheduler and continuing to execute the test case.
Optionally, the test device 30 for designing a circuit may further include:
the registration module is used for registering a callback function generation instruction through the Lua scheduler after triggering a task handover event preset in the test case through the Lua scheduler, wherein the callback function generation instruction is used for indicating to register a callback function corresponding to the task handover event;
and the generation module is used for generating a callback function through the simulator and determining a stopping event corresponding to the task handover event according to the callback function.
Optionally, the callback function generation instruction includes identification information of the test case;
correspondingly, the fourth acquisition module may include:
a booklet module for registering, by the emulator, a wake-up function including the identification information;
correspondingly, the switching module may include:
and the execution sub-module is used for responding to the wake-up function and continuously executing the test cases corresponding to the identification information through the Lua scheduler.
Optionally, the test cases are plural, and the test cases are coroutines.
Correspondingly, the second acquisition module 302 may include:
the first execution sub-module is used for stopping executing the current test case and starting to execute other at least partial unexecuted test cases in parallel when triggering a task handover event preset in the current test case through the Lua scheduler;
And the second execution sub-module is used for responding to the wake-up function after registering the wake-up function for indicating to continue to execute the current test case through the simulator, and executing the current test case and other executing test cases in parallel through the Lua scheduler.
Optionally, the test device 30 for designing a circuit may further include:
a fifth obtaining module, configured to obtain, by the simulator, a simulation output result for the design circuit before obtaining a test result of the design circuit according to the simulation output result, and store the simulation output result in a memory slice of the simulator memory;
the conversion module is used for obtaining a first handle for indicating the memory fragment address through the simulator and converting the first handle into a second handle corresponding to the Lua language;
and a sixth obtaining module, configured to store, by the Lua scheduler, the second handle, and convert the second handle into the first handle when executing an instruction for obtaining a simulation output result for the design circuit, and extract the simulation output result from the memory chip area according to the first handle.
Optionally, the test device 30 for designing a circuit may further include:
the generation module is used for generating log data according to one or more of circuit input data of the design circuit, the simulation output result, clock period data of the design circuit and intermediate data generated in the process of executing the file to be tested after the file to be tested is executed and the simulation output result of the design circuit is obtained;
and the storage module is used for storing the log data in the LevelDB database.
Optionally, the third obtaining module 303 may include:
the first determining submodule is used for determining that the test result of the design circuit passes the test under the condition that the simulation output result meets the preset output result requirement;
and the second determining submodule is used for determining that the test result of the design circuit fails the test under the condition that the simulation output result is determined to be not in accordance with the preset output result requirement.
In summary, in the embodiment of the application, a file to be tested is obtained, a test case obtained by describing a test task of a design circuit through Lua language is input into the test case, the file to be tested is executed based on circuit input data and the test task in the test case, a simulation output result aiming at the design circuit is obtained, and a test result of the design circuit is obtained according to the simulation output result. The method adopts the Lua language to describe the test task of the design circuit to obtain the test case, and tests the design circuit of the file to be tested based on the test case described by the Lua language, so that the test efficiency of the design circuit is improved in the test process of the design circuit, and the problem of low test efficiency of the design circuit in the related technology is solved.
Fig. 7 is a block diagram of an electronic device 400, according to an example embodiment. For example, electronic device 400 may be a mobile phone, computer, digital broadcast terminal, messaging device, game console, tablet device, medical device, exercise device, personal digital assistant, or the like.
Referring to fig. 7, an electronic device 400 may include one or more of the following components: a processing component 402, a memory 404, a power supply component 406, a multimedia component 408, an audio component 410, an input/output (I/O) interface 412, a sensor component 414, and a communication component 416.
The processing component 402 generally controls overall operation of the electronic device 400, such as operations associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 402 may include one or more processors 420 to execute instructions to perform all or part of the steps of the methods described above. Further, the processing component 402 can include one or more modules that facilitate interaction between the processing component 402 and other components. For example, the processing component 402 may include a multimedia module to facilitate interaction between the multimedia component 408 and the processing component 402.
Memory 404 is used to store various types of data to support operations at electronic device 400. Examples of such data include instructions for any application or method operating on electronic device 400, contact data, phonebook data, messages, pictures, multimedia, and so forth. The memory 404 may be implemented by any type or combination of volatile or nonvolatile memory devices such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk.
The power supply component 406 provides power to the various components of the electronic device 400. The power components 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 400.
The multimedia component 408 includes a screen between the electronic device 400 and the user that provides an output interface. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may not only sense demarcations of touch or sliding actions, but also detect durations and pressures associated with touch or sliding operations. In some embodiments, the multimedia component 408 includes a front camera and/or a rear camera. When the electronic device 400 is in an operational mode, such as a photographing mode or a multimedia mode, the front-facing camera and/or the rear-facing camera may receive external multimedia data. Each front camera and rear camera may be a fixed optical lens system or have focal length and optical zoom capabilities.
The audio component 410 is for outputting and/or inputting audio signals. For example, the audio component 410 includes a Microphone (MIC) for receiving external audio signals when the electronic device 400 is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals may be further stored in the memory 404 or transmitted via the communication component 416. In some embodiments, audio component 410 further includes a speaker for outputting audio signals.
The I/O interface 412 provides an interface between the processing component 402 and peripheral interface modules, which may be a keyboard, click wheel, buttons, etc. These buttons may include, but are not limited to: homepage button, volume button, start button, and lock button.
The sensor assembly 414 includes one or more sensors for providing status assessment of various aspects of the electronic device 400. For example, the sensor assembly 414 may detect an on/off state of the electronic device 400, a relative positioning of the components, such as a display and keypad of the electronic device 400, the sensor assembly 414 may also detect a change in position of the electronic device 400 or a component of the electronic device 400, the presence or absence of a user's contact with the electronic device 400, an orientation or acceleration/deceleration of the electronic device 400, and a change in temperature of the electronic device 400. The sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects in the absence of any physical contact. The sensor assembly 414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 414 may also include an acceleration sensor, a gyroscopic sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.
The communication component 416 is used to facilitate communication between the electronic device 400 and other devices, either wired or wireless. The electronic device 400 may access a wireless network based on a communication standard, such as WiFi, an operator network (e.g., 2G, 3G, 4G, or 5G), or a combination thereof. In one exemplary embodiment, the communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component 416 further includes a Near Field Communication (NFC) module to facilitate short range communications. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra Wideband (UWB) technology, bluetooth (BT) technology, and other technologies.
In an exemplary embodiment, the electronic device 400 may be implemented by one or more Application Specific Integrated Circuits (ASICs), digital Signal Processors (DSPs), digital Signal Processing Devices (DSPDs), programmable Logic Devices (PLDs), field Programmable Gate Arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic elements for implementing a method of testing a design circuit as provided by embodiments of the present application.
In an exemplary embodiment, a non-transitory computer-readable storage medium is also provided, such as memory 404, that includes instructions executable by processor 420 of electronic device 400 to perform the above-described method. For example, the non-transitory storage medium may be ROM, random Access Memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.
Fig. 8 is a block diagram of an electronic device 500, according to an example embodiment. For example, electronic device 500 may be provided as a server. Referring to fig. 8, electronic device 500 includes a processing component 522 that further includes one or more processors and memory resources represented by memory 532 for storing instructions, such as applications, executable by processing component 522. The application programs stored in the memory 532 may include one or more modules each corresponding to a set of instructions. In addition, the processing component 522 is configured to execute instructions to perform a test method of designing a circuit provided by embodiments of the present application.
The electronic device 500 may also include a power component 526 configured to perform power management of the electronic device 500, a wired or wireless network interface 550 configured to connect the electronic device 500 to a network, and an input output (I/O) interface 558. The electronic device 500 may operate based on an operating system stored in the memory 532, such as Windows Server, mac OS XTM, unixTM, linuxTM, freeBSDTM, or the like.
The embodiment of the application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to realize a testing method of a design circuit.
Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.
It is to be understood that the present application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.
The foregoing description of the preferred embodiments of the present application is not intended to be limiting, but rather is intended to cover any and all modifications, equivalents, alternatives, and improvements within the spirit and principles of the present application.
The foregoing has described in detail the methods, apparatus, electronic devices and computer readable storage medium for testing a design circuit provided herein, and specific examples have been applied to illustrate the principles and embodiments of the present application, and the above examples are only used to help understand the methods and core ideas of the present application; meanwhile, as those skilled in the art will vary in the specific embodiments and application scope according to the ideas of the present application, the contents of the present specification should not be construed as limiting the present application in summary.
Claims (12)
1. A method of testing a design circuit, the method comprising:
acquiring a file to be tested and a test case; the test case comprises circuit input data, and is obtained by describing a test task of the design circuit through a Lua language; inputting the file to be tested into the test case, executing the file to be tested based on circuit input data and test tasks in the test case, and obtaining a simulation output result aiming at the design circuit; obtaining a test result of the design circuit according to the simulation output result;
Inputting the file to be tested into the test case, executing the file to be tested based on circuit input data and test tasks in the test case, and obtaining a simulation output result aiming at the design circuit, wherein the method comprises the following steps:
stopping executing the test case and generating an instruction for indicating circuit simulation when a task handover event preset in the test case is triggered by the Lua scheduler;
and responding to an instruction for indicating circuit simulation, configuring the circuit input data into the input data of the design circuit through a simulator, and performing simulation of the design circuit to obtain a simulation output result.
2. The method of claim 1, wherein the obtaining the test result of the design circuit according to the simulation output result comprises: and obtaining a test result of the design circuit according to the simulation output result through the Lua scheduler.
3. The method of claim 2, further comprising, after obtaining the simulation output result by the simulator:
stopping executing the simulation of the design circuit when a preset stopping event is triggered by the simulator, obtaining a simulation output result, and registering a wake-up function for indicating to continue executing the test case;
And responding to a wake-up function, switching to the Lua scheduler, and continuing to execute the test case.
4. A method according to claim 3, further comprising, after triggering a task handoff event preset in the test case by a Lua scheduler:
registering a callback function generation instruction through the Lua dispatcher, wherein the callback function generation instruction is used for indicating to register a callback function corresponding to the task handover event;
and generating a callback function through the simulator, and determining a stopping event corresponding to the task handover event according to the callback function.
5. The method of claim 4, wherein the callback function generation instruction comprises identification information of the test case;
registering, by the emulator, a wake-up function for indicating continued execution of the test case, comprising:
registering, by the emulator, a wake-up function including the identification information;
continuing to execute the test case by the Lua scheduler, including:
and responding to the wake-up function, and continuing to execute the test cases corresponding to the identification information through the Lua scheduler.
6. The method of claim 1, wherein, in the case where there are a plurality of test cases and the test cases are coroutines, the executing the file to be tested, obtaining the simulation output result for the design circuit, includes:
When triggering a task handover event preset in the currently executed test cases through the Lua scheduler, stopping executing the current test cases, and starting to execute other at least partial unexecuted test cases in parallel;
after registering a wake-up function for indicating to continue executing a current test case through a simulator, the current test case and other executing test cases are executed in parallel through the Lua scheduler in response to the wake-up function.
7. The method of claim 1, further comprising, prior to obtaining the test result of the design circuit based on the simulation output result:
obtaining a simulation output result aiming at the design circuit through a simulator, and storing the simulation output result in a memory area of a simulator memory;
acquiring a first handle for indicating the memory fragment address through the simulator, and converting the first handle into a second handle corresponding to the Lua language;
and storing the second handle through the Lua scheduler, converting the second handle into the first handle when executing an instruction for acquiring a simulation output result of the design circuit, and extracting the simulation output result from the memory chip area according to the first handle.
8. The method of claim 1, further comprising, after executing the file to be tested and obtaining the simulated output results for the design circuit:
generating log data according to one or more of circuit input data of the design circuit, the simulation output result, clock period data of the design circuit and intermediate data generated in the process of executing the file to be tested;
the log data is stored in a level db database.
9. The method according to any one of claims 1 to 8, wherein the obtaining the test result of the design circuit according to the simulation output result includes:
under the condition that the simulation output result meets the preset output result requirement, determining that the test result of the design circuit passes the test;
and under the condition that the simulation output result is determined to be not in accordance with the preset output result requirement, determining that the test result of the design circuit fails the test.
10. A test apparatus for designing a circuit, the apparatus comprising:
the first acquisition module is used for acquiring a file to be tested and a test case; the test case comprises circuit input data, and is obtained by describing a test task of the design circuit through a Lua language; the second acquisition module is used for inputting the file to be tested into the test case, executing the file to be tested based on circuit input data and test tasks in the test case, and acquiring a simulation output result aiming at the design circuit; and the third acquisition module is used for acquiring the test result of the design circuit according to the simulation output result.
11. An electronic device, comprising: a processor;
a memory for storing the processor-executable instructions;
wherein the processor is configured to execute the instructions to implement the method of any one of claims 1 to 9.
12. A computer readable storage medium, characterized in that instructions in the computer readable storage medium, when executed by a processor of an electronic device, enable the electronic device to perform the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311197916.6A CN116933707B (en) | 2023-09-15 | 2023-09-15 | Test method, device, equipment and medium for design circuit |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311197916.6A CN116933707B (en) | 2023-09-15 | 2023-09-15 | Test method, device, equipment and medium for design circuit |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116933707A CN116933707A (en) | 2023-10-24 |
| CN116933707B true CN116933707B (en) | 2023-12-22 |
Family
ID=88390024
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311197916.6A Active CN116933707B (en) | 2023-09-15 | 2023-09-15 | Test method, device, equipment and medium for design circuit |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116933707B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117271374A (en) * | 2023-11-20 | 2023-12-22 | 北京开源芯片研究院 | Simulation test method, device and equipment for chip and storage medium |
| CN117762717B (en) * | 2024-02-18 | 2024-04-26 | 北京开源芯片研究院 | Method and device for testing working mechanism of processor cache |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH01277781A (en) * | 1988-04-30 | 1989-11-08 | Nippon Telegr & Teleph Corp <Ntt> | Testing apparatus for integrated circuit |
| US7137087B1 (en) * | 2003-08-20 | 2006-11-14 | Adaptec, Inc. | Integrated circuit verification scheme |
| CN116401980A (en) * | 2023-03-02 | 2023-07-07 | 上海空间电源研究所 | Automatic simulation verification method and system for full working condition of circuit schematic diagram |
| CN116736088A (en) * | 2023-08-11 | 2023-09-12 | 上海类比半导体技术有限公司 | Chip testing method for assisting post-silicon test |
-
2023
- 2023-09-15 CN CN202311197916.6A patent/CN116933707B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH01277781A (en) * | 1988-04-30 | 1989-11-08 | Nippon Telegr & Teleph Corp <Ntt> | Testing apparatus for integrated circuit |
| US7137087B1 (en) * | 2003-08-20 | 2006-11-14 | Adaptec, Inc. | Integrated circuit verification scheme |
| CN116401980A (en) * | 2023-03-02 | 2023-07-07 | 上海空间电源研究所 | Automatic simulation verification method and system for full working condition of circuit schematic diagram |
| CN116736088A (en) * | 2023-08-11 | 2023-09-12 | 上海类比半导体技术有限公司 | Chip testing method for assisting post-silicon test |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116933707A (en) | 2023-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN116933707B (en) | Test method, device, equipment and medium for design circuit | |
| US10705780B2 (en) | Method, device, and storage medium for displaying application page | |
| CN111176960B (en) | User operation behavior tracking method, device, equipment and storage medium | |
| RU2640733C2 (en) | Method and device for application management | |
| CN106598630A (en) | Key control method and apparatus, and terminal | |
| EP3757739A1 (en) | Method for display when exiting an application, and terminal | |
| CN111767058A (en) | Program compiling method and device, electronic equipment and storage medium | |
| CN114741292A (en) | Test script management method and device, electronic equipment and storage medium | |
| CN111061452A (en) | Voice control method and device of user interface | |
| CN113868132A (en) | Application program testing method and device, electronic equipment and storage medium | |
| CN110851370B (en) | Program testing method and device and storage medium | |
| CN113377664A (en) | Model testing method and device, electronic device and storage medium | |
| CN106020694B (en) | Electronic equipment, and method and device for dynamically adjusting selected area | |
| CN112416751A (en) | Processing method and device for interface automation test and storage medium | |
| CN112256563A (en) | Android application stability testing method and device, electronic equipment and storage medium | |
| CN115373763B (en) | Plug-in loading method and device, electronic equipment and storage medium | |
| CN111596980B (en) | Information processing method and device | |
| CN112637409B (en) | Content output method and device and electronic equipment | |
| CN114896165A (en) | Testing method and device of conversation robot system, electronic equipment and storage medium | |
| CN111338961B (en) | Application debugging method and device, electronic equipment and storage medium | |
| CN113760946A (en) | Pre-verification processing method, device, equipment and medium applied to data source migration | |
| CN111427642A (en) | Data processing method and device, terminal equipment and computer readable storage medium | |
| CN110858174A (en) | Picture auditing method for mobile device chat software | |
| CN109739763B (en) | Code segment operation method, device, terminal and storage medium | |
| CN109947640B (en) | Regression test-based core function coverage statistical method and device |
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 |