CN113656227A - Chip verification method and device, electronic equipment and storage medium - Google Patents
Chip verification method and device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN113656227A CN113656227A CN202110932656.7A CN202110932656A CN113656227A CN 113656227 A CN113656227 A CN 113656227A CN 202110932656 A CN202110932656 A CN 202110932656A CN 113656227 A CN113656227 A CN 113656227A
- Authority
- CN
- China
- Prior art keywords
- test
- chip
- interface
- test interface
- tested
- 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.)
- Pending
Links
- 238000012795 verification Methods 0.000 title claims abstract description 169
- 238000000034 method Methods 0.000 title claims abstract description 60
- 238000012360 testing method Methods 0.000 claims abstract description 481
- 230000004044 response Effects 0.000 claims description 16
- 238000004590 computer program Methods 0.000 claims description 12
- 238000010276 construction Methods 0.000 claims description 4
- 239000000126 substance Substances 0.000 claims description 4
- 238000013473 artificial intelligence Methods 0.000 abstract description 21
- 230000006870 function Effects 0.000 description 23
- 238000010586 diagram Methods 0.000 description 15
- 238000004088 simulation Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 7
- 238000012545 processing Methods 0.000 description 7
- 230000000903 blocking effect Effects 0.000 description 6
- 230000005284 excitation Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000002776 aggregation Effects 0.000 description 3
- 238000004220 aggregation Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 3
- 230000011218 segmentation Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012549 training Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/2247—Verification or detection of system hardware configuration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
- G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
Abstract
The disclosure provides a chip verification method, a chip verification device, electronic equipment and a storage medium, and relates to the field of artificial intelligence, in particular to the field of integrated circuits. The specific implementation scheme is as follows: constructing a corresponding test sequence aiming at the current test interface based on a default sequence constructed in advance; testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface; and judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface. The embodiment of the application can more conveniently construct the corresponding test sequence aiming at different interfaces, thereby simplifying the user operation and reducing the workload of compiling the test sequence; and the verification time can be shortened, and the expandability is enhanced.
Description
Technical Field
The present disclosure relates to the field of artificial intelligence technologies, and further relates to integrated circuit technologies, and in particular, to a chip verification method and apparatus, an electronic device, and a storage medium.
Background
At present, a System on Chip (soc) simulation verification platform for verifying an Artificial Intelligence (AI) Chip is mainly implemented by the following technologies: 1) realizing each verification component of the platform based on UVM verification methodology, System Verilog language, C language and the like; 2) generating various excitations in sequence (sequence) according to time sequence, and specifying specific parameters of the excitations in a test case, such as packet length, interval, original data file and the like; 3) reading the simulation result, automatically comparing the simulation result, and judging whether the simulation result is correct or wrong; 4) and (4) realizing batch simulation of a large number of test cases through regression, and judging whether the overall coverage rate and each function point meet the requirements or not.
The existing soc simulation verification platform is not clear enough about the layering of the test sequence, and a platform user needs to pay attention to not only the function scenario of the test but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface when constructing the test of various application scenarios. For example, how many high speed bus protocol (AXI for short) packets a block of data should be divided into, the bit width of the Interface bus, whether the address is out of range, etc., which results in repeated labor with low efficiency.
In addition, in the existing soc simulation verification platform, the same stimulus in the AI chip can be sent from multiple interfaces, each interface uses different protocols, physical characteristics and parameters, different verification components and sequencers are used, the sequences of different verification components cannot be compatible, and sending a stimulus from another interface requires rewriting a test sequence to conform to the characteristics of the interface. Therefore, in actual testing, the required test sequence is often very complex, the repeated programming of the test sequence greatly increases the workload, and the chip verification convergence time is prolonged.
Furthermore, the verification platform is difficult to migrate between different projects. When the subsequent project uses different modules and different interface protocol types, the test sequence needs to be rewritten due to lack of reasonable abstraction of the excitation level; if a new module is added, the structure of the platform also needs to be modified, and the platform lacks expansibility.
Disclosure of Invention
The disclosure provides a chip verification method, a chip verification device, an electronic device and a storage medium.
In a first aspect, the present application provides a chip verification method, including:
constructing a corresponding test sequence aiming at the current test interface based on a default sequence constructed in advance;
testing a chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operations until obtaining the test result returned by the chip to be tested aiming at each test interface;
and judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface.
In a second aspect, the present application provides a chip verification apparatus, the apparatus comprising: the system comprises a construction module, a test module and a verification module; wherein the content of the first and second substances,
the building module is used for building a corresponding test sequence for the current test interface based on a default sequence built in advance;
the test module is used for testing a chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operations until obtaining the test result returned by the chip to be tested aiming at each test interface;
and the verification module is used for judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface.
In a third aspect, an embodiment of the present application provides an electronic device, including:
one or more processors;
a memory for storing one or more programs,
when the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the chip verification method according to any embodiment of the present application.
In a fourth aspect, the present application provides a storage medium, on which a computer program is stored, where the computer program is executed by a processor to implement the chip verification method according to any embodiment of the present application.
In a fifth aspect, a computer program product is provided, which when executed by a computer device implements the chip verification method according to any of the embodiments of the present application.
According to the technical scheme provided by the application, the corresponding test sequences can be more conveniently constructed aiming at different interfaces, so that the user operation can be simplified, and the workload of compiling the test sequences is reduced; and the verification time can be shortened, and the expandability is enhanced.
It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.
Drawings
The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:
fig. 1 is a first flowchart of a chip verification method according to an embodiment of the present disclosure;
fig. 2 is a schematic structural diagram of an AI chip provided in the embodiment of the present application;
FIG. 3 is a schematic structural diagram of a soc validation platform provided by an embodiment of the present application;
FIG. 4 is a second flowchart of a chip verification method according to an embodiment of the present disclosure;
FIG. 5 is a diagram illustrating a test sequence structure provided by an embodiment of the present application;
fig. 6 is a schematic structural diagram of a virtual sequencer according to an embodiment of the present application;
fig. 7 is a third flowchart of a chip verification method according to an embodiment of the present disclosure;
fig. 8 is a schematic structural diagram of a packet number queue according to an embodiment of the present application;
FIG. 9 is a schematic structural diagram of a chip verification module according to an embodiment of the present disclosure;
fig. 10 is a block diagram of an electronic device for implementing the chip verification method according to the embodiment of the present application.
Detailed Description
Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
Example one
Fig. 1 is a first flowchart of a chip verification method provided in an embodiment of the present application, where the method may be performed by a chip verification apparatus or an electronic device, where the apparatus or the electronic device may be implemented by software and/or hardware, and the apparatus or the electronic device may be integrated in any intelligent device with a network communication function; the electronic equipment in the application can be suitable for the soc verification platform developed by the cloud AI chip. As shown in fig. 1, the chip verification method may include the steps of:
s101, constructing a corresponding test sequence for the current test interface based on a default sequence constructed in advance.
In this step, the soc verification platform may construct a corresponding test sequence for the current test interface based on a default sequence constructed in advance; wherein the default sequence includes at least one generic base task; common basic tasks include, but are not limited to: a read operation task, a write operation task, an initialization program and an interrupt processing program; the read operation tasks include: a read register and a read memory; the write operation tasks include: write registers and write memory. Specifically, the soc verification platform may first receive test configuration parameters input by a user for a current test interface; wherein, the test configuration parameters at least comprise interface number identification; then acquiring a general basic task corresponding to the current test interface in a default sequence based on the test configuration parameters; and then constructing a corresponding test sequence aiming at the current test interface based on the general basic task corresponding to the current test interface.
In a specific embodiment of the application, before the soc verification platform constructs a corresponding test sequence for a current test interface, corresponding basis functions can be respectively constructed for each general basis task; and then packaging the basic functions corresponding to the general basic tasks into a default sequence respectively.
S102, testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; and taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface.
In this step, the soc verification platform may test the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested for the current test interface; and taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface. Specifically, the soc verification platform may first send each data packet in a test sequence corresponding to the current test interface to the chip to be tested, and press the serial number of each data packet into a predefined queue; if the correct response of the data packet is received within the response time length corresponding to each data packet, deleting the serial number of the data packet in the queue; if the serial numbers of all the data packets in the queue are deleted, judging that the test result returned by the chip to be tested aiming at the current test interface is passed through verification; and if the serial numbers of all the data packets in the queue are not deleted, judging that the test result returned by the chip to be tested aiming at the current test interface is unverified and passed.
S103, judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface.
In this step, the soc verification platform may determine that the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested for each test interface. Specifically, if the test results returned by the chip to be tested for each test interface are all verified, the soc verification platform can determine that the chip to be tested passes verification; if the test result returned by the chip to be tested aiming at any test interface is unverified, the soc verification platform can judge that the chip to be tested is unverified. For example, for a certain chip to be tested, three interfaces thereof need to be tested, and the three interfaces are respectively: interface 1, interface 2 and interface 3, their test sequence that corresponds respectively is: test sequence 1, test sequence 2, and test sequence 3. In the test process, testing a chip to be tested on the interface 1 by using the test sequence 1, testing the chip to be tested on the interface 2 by using the test sequence 2, and testing the chip to be tested on the interface 3 by using the test sequence 3; then the soc verification platform can obtain test results returned by the chip to be tested respectively aiming at the interface 1, the interface 2 and the interface 3; if the test results returned by the chip to be tested aiming at the interface 1, the interface 2 and the interface 3 are all verified, the soc verification platform can judge that the chip to be tested passes the verification; if the test result returned by the chip to be tested aiming at the interface 1, the interface 2 or the interface 3 is unverified, the soc verification platform can judge that the chip to be tested is unverified.
Fig. 2 is a schematic structural diagram of an AI chip provided in the embodiment of the present application. As shown in fig. 2, the AI chip may include: a PCIE module, a memory module, a microcontroller module, an interrupt controller, an inter-chip interconnection module, AI computing units 0 and …, and an AI computing unit N; the modules and units are connected by an AXI bus. The AI chip has the basic features: a bus based on an on-chip high-speed protocol (taking an AXI protocol as an example) is controlled by a host computer of the computer card, and the host computer configures and reads and writes the AI chip through an interface connected with the PCIE. In addition, the microcontroller module configures an AI chip and reads and writes the on-chip memory through an interface connected with the AXI bus, and the bus is also provided with other-purpose main equipment which reads and writes the on-chip memory through an interface connected with the AXI bus through the inter-chip interconnection module. The AI chip may be tested on each of the different interfaces using a respective test sequence. For example, on an interface where the host is connected to the PCIE module, a test sequence corresponding to the interface is input to test the AI chip; and inputting a test sequence corresponding to the interface to test the AI chip on the interface where the PCIE module is connected with the AXI bus. In the existing chip verification method, a platform user needs to rewrite a test sequence aiming at different interfaces, and at the moment, the platform user needs to pay attention to not only a function scene of the test but also implementation details of a protocol bottom layer and specific parameters of a sending interface, so that the mode has repeated labor with low efficiency. According to the method and the device, the test sequence corresponding to each interface is established based on the default sequence, a platform user does not need to pay attention to implementation details of a protocol bottom layer and specific parameters of a sending interface, user operation can be simplified, and workload for compiling the test sequence is greatly reduced.
Fig. 3 is a schematic structural diagram of a soc verification platform provided in an embodiment of the present application. As shown in fig. 3, the soc validation platform may include: the system comprises a virtual sequencer, a PCIE verification component, an AXI verification component, an interconnection agent module, a parameter configuration module, a clock check module and a reset check module; the PCIE verification assembly is connected with the chip to be tested through the PCIE interface; the AXI verifying component is connected with the chip to be tested through an AXI interface; wherein, the AXI interface may include: AXI interface 1, AXI interface 2, …, AXI interface K; k is a natural number more than or equal to 1; the interconnection agent module is connected with the chip to be tested through an interconnection interface; the parameter configuration module may include: PCIE parameter configuration, AXI parameter configuration, jtag parameter configuration and interconnection interface parameter configuration. Because a plurality of interfaces of the AI chip can participate in data stream sending and receiving of reasoning and training scenes, the same test sequence is required to be multiplexed to the interface types as many as possible. Meanwhile, the requirement of the AI chip on the performance determines the condition of simulating the maximum bandwidth of each protocol interface.
The chip verification method provided by the embodiment of the application comprises the steps of firstly constructing a corresponding test sequence aiming at a current test interface based on a default sequence constructed in advance; then testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface; and finally, judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface. That is to say, the default sequence in the present application has a clear hierarchical structure, and a test sequence meeting the requirements of different test interfaces can be constructed by calling a general basic task in the default sequence, so that a platform user does not need to write corresponding test sequences for different test interfaces, and does not need to pay attention to implementation details of a protocol bottom layer and specific parameters of a sending interface. However, the existing soc simulation verification platform is not clear enough about the layering of the test sequence, and when a platform user constructs the test of various application scenarios, the platform user needs to pay attention to not only the function scenario of the test, but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface. Because the technical means of constructing the corresponding test sequence aiming at the current test interface based on the default sequence constructed in advance is adopted, the technical problems of large workload, long verification time, lack of expandability and the like caused by the fact that the existing platform user needs to pay attention to not only the function scene of the test but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface when constructing the test of various application scenes are solved; the verification time can be shortened, and the expandability is enhanced; moreover, the technical scheme of the embodiment of the application is simple and convenient to implement, convenient to popularize and wide in application range.
Example two
Fig. 4 is a second flowchart of the chip verification method according to the embodiment of the present application. Further optimization and expansion are performed based on the technical scheme, and the method can be combined with the various optional embodiments. As shown in fig. 4, the chip verification method may include the steps of:
s401, receiving test configuration parameters input by a user aiming at a current test interface; wherein, the test configuration parameters at least comprise interface number identification.
In this step, the soc verification platform may receive the test configuration parameters input by the user for the current test interface; wherein, the test configuration parameters at least comprise interface number identification; for example, the interface number is identified as the mater _ id. And identifying the current interface number through a function defined by the mater _ id, and transmitting the corresponding sequencer member in the virtual sequencer to the current sequencer. The function is called before the test sequence is constructed each time, so that the transaction of the current sequence can be sent from the specified interface during the operation, and the same group of sequences can flexibly switch the interfaces of different protocol types in different test cases.
Fig. 5 is a schematic diagram of a test sequence structure provided in an embodiment of the present application. As shown in fig. 5, the test sequence structure may include four levels, respectively: a first level, a second level, a third level, and a fourth level; wherein the first level is uvm sequence framework (uvm _ sequence); the second level is a verification platform base class sequence (soc _ base _ vseq); the third level is test sequence 0(test _ vseq0), test sequence 1(test _ vseq1), …, test sequence (test _ vseqN); n is a natural number more than or equal to 1; the fourth level is a combined scene sequence 0(scenario _ vseq0), … and a combined scene sequence M (scenario _ vseqM); wherein M is a natural number of 1 or more. Specifically, uvm _ sequence refers to a verification framework in the prior art; soc _ base _ vseq is based on this verification framework; the test _ vseq is derived from the soc _ base _ vseq, and it can be understood that the test _ vseq and the soc _ base _ vseq are in an inheritance relationship; the scenario _ vseq is obtained by arranging and combining test _ vseq, and the process is a complex calling process and can be executed in series or in parallel. The test sequence structure is characterized in that: the default sequence is soc _ base _ vseq, which is used as a base class of all test sequences, and defines general basic functions or tasks, including a read operation task, a write operation task, an initialization program of a main module, an interrupt handler and the like, and the functions or tasks can be reused by all the test sequences. When testing a single data path, the runtime specifies that a test sequence derived from soc _ base _ vseq reloads a base class sequence to send stimuli; when testing a multi-pass concurrency scenario, the scenario _ vseq is derived from soc _ base _ vseq.
Fig. 6 is a schematic structural diagram of a virtual sequencer according to an embodiment of the present application. As shown in fig. 6, the virtual sequencer may include: a current sequencer, a virtual sequencer, and a verification component; the virtual sequencer may include X virtual sequencer members, which are virtual sequencer member 1, virtual sequencer member 2, …, and virtual sequencer member X. Each virtual sequencer can be connected with a corresponding verification component; the virtual sequencer member 1 is connected with the verification component 1; virtual sequencer member 2 connects verification components 2, …, virtual sequencer member X connects verification component X. The verification component may include AXI protocol related components and may also include other protocol related components, which are not limited herein.
S402, acquiring a general basic task corresponding to the current test interface in a default sequence based on the test configuration parameters.
S403, constructing a corresponding test sequence for the current test interface based on the general basic task corresponding to the current test interface.
In a specific embodiment of the application, the soc verification platform may first obtain a general basic task corresponding to the current test interface in a default sequence based on the test configuration parameters; then, constructing a corresponding test sequence aiming at the current test interface based on a general basic task corresponding to the current test interface; wherein the default sequence includes at least one generic base task; common basic tasks include, but are not limited to: a read operation task, a write operation task, an initialization program and an interrupt processing program; the read operation tasks include: a read register and a read memory; the write operation tasks include: write registers and write memory.
When reading or writing the register, determining which interface the current excitation is sent according to the sequencer label (sqr _ id) and the aggregation parameter specified in the operation, and sending the data packet conforming to the interface format. For example, the host writes a register through an AXI interface, except for the address and data of a given sending transaction, the width (burst _ size) of a data packet of the sending transaction is 4 bytes, the bit width of id is 2 bits, and the id value is random from 0 to 3. When the host writes the register through the PCIE interface, the PCIE verification assembly is called, 32-bit data is written according to the configured mapping space and the PCIE protocol, and then register writing operation is completed once.
When reading or writing memory, it is also first determined on which interface the current stimulus is sent, based on the sequencer number (sqr _ id) and the aggregation parameter specified at run-time. When a host user writes a memory space with a given initial address and length through an AXI interface, due to the limitation of an AXI protocol, firstly, if the current writing crosses a 4K address boundary, the AXI writing operation is segmented by the 4K boundary address, and the current task is called recursively, wherein the writing length is equal to the boundary address-the initial address. If the write length still crosses the 4K boundary after the segmentation, the segmentation is continued until the residual length does not cross the 4K boundary. Checking the length of the segmented write transaction, wherein the bit width of a host AXI interface signal is 256 bits, the maximum data packet length is 16, 32 bytes × 16 is 512 bytes, if the write length is greater than 512 bytes, the data packet width (burst _ size) is sent first to 32 bytes, the data packet length (burst _ len) is 16, id bit width is 4, namely, the data packet length is random between 0 and 15, and then determining a user field value according to a virtualization user; the process continues to be repeated until the remaining transaction is less than 512 bytes in length. At this time, it is determined whether the length is equal to or greater than 256 bytes. Until it is sliced to 4 bytes in length. Thus, the AXI write transaction is segmented by the most appropriate length, and an implementer can also consider both write operation efficiency and implementation complexity on the specific segmentation method.
When the host writes the memory space through the PCIE interface, the PCIE verification assembly is called, data transportation is configured according to the configured mapping space and a PCIE protocol, a destination address and a length are given, data transportation is initiated once, and interruption of data transportation is waited.
When the host writes the memory space through the backdoor, a backdoor read-write function is defined for the global memory, backdoor write or backdoor read can be appointed when the host runs in a test case, and if the read-write address is located in the effective address range of the global memory, the initiated operation is the backdoor read/write memory. The front door access and the back door access of the same sequence are controlled through the parameters in the running process.
S404, testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; and taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface.
S405, judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface.
The chip verification method provided by the embodiment of the application comprises the steps of firstly constructing a corresponding test sequence aiming at a current test interface based on a default sequence constructed in advance; then testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface; and finally, judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface. That is to say, the default sequence in the present application has a clear hierarchical structure, and a test sequence meeting the requirements of different test interfaces can be constructed by calling a general basic task in the default sequence, so that a platform user does not need to write corresponding test sequences for different test interfaces, and does not need to pay attention to implementation details of a protocol bottom layer and specific parameters of a sending interface. However, the existing soc simulation verification platform is not clear enough about the layering of the test sequence, and when a platform user constructs the test of various application scenarios, the platform user needs to pay attention to not only the function scenario of the test, but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface. Because the technical means of constructing the corresponding test sequence aiming at the current test interface based on the default sequence constructed in advance is adopted, the technical problems of large workload, long verification time, lack of expandability and the like caused by the fact that the existing platform user needs to pay attention to not only the function scene of the test but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface when constructing the test of various application scenes are solved; the verification time can be shortened, and the expandability is enhanced; moreover, the technical scheme of the embodiment of the application is simple and convenient to implement, convenient to popularize and wide in application range.
EXAMPLE III
Fig. 7 is a third flowchart of a chip verification method according to an embodiment of the present application. Further optimization and expansion are performed based on the technical scheme, and the method can be combined with the various optional embodiments. As shown in fig. 7, the chip verification method may include the steps of:
s701, receiving test configuration parameters input by a user aiming at a current test interface; wherein, the test configuration parameters at least comprise interface number identification.
S702, determining at least one virtual sequencer member corresponding to the current test interface in the pre-designated virtual sequencers based on the test configuration parameters.
S703, acquiring a general basic task corresponding to the current test interface in a default sequence through the at least one virtual sequencer member and the verification component connected with each virtual sequencer member in advance.
In this step, the soc verification platform may obtain, in the default sequence, the general basic task corresponding to the current test interface through the at least one virtual sequencer member and the verification component connected to each virtual sequencer member in advance. Specifically, the virtual sequencer may include: a current sequencer, a virtual sequencer, and a verification component; the virtual sequencer may include X virtual sequencer members, which are virtual sequencer member 1, virtual sequencer member 2, …, and virtual sequencer member X. Each virtual sequencer can be connected with a corresponding verification component; the virtual sequencer member 1 is connected with the verification component 1; virtual sequencer member 2 connects verification components 2, …, virtual sequencer member X connects verification component X. The virtual sequencer enables multiplexing of stimuli between different interfaces. The sequencer (sequencer) of the AXI verification component is connected to the virtual sequencer at the test base class (base _ test) connection phase (connect _ phase).
S704, obtaining at least one test sequence composed of a plurality of read operation tasks and a plurality of write operation tasks through the general basic task corresponding to the current test interface.
In this step, the soc verification platform may obtain at least one test sequence composed of a plurality of read operation tasks and a plurality of write operation tasks based on a general basic task corresponding to the current test interface. The embodiment of the application can define a runtime input parameter master _ id for identifying an interface number, defining a function, identifying a current interface number, and transmitting a corresponding sequencer member in a virtual sequencer to the current sequencer. The function is called before the test sequence is constructed each time, so that the transaction of the current sequence can be sent from the specified interface during the operation, and the same group of sequences can flexibly switch the interfaces of different protocol types in different test cases.
S705, obtaining a test sequence corresponding to the current test interface by calling at least one test sequence consisting of a read operation task and a write operation task; wherein, the verification component comprises a high-speed bus protocol and a non-high-speed bus protocol.
In this step, the soc verification platform may obtain a test sequence corresponding to the current test interface by calling at least one test sequence composed of a read operation task and a write operation task; wherein, the verification component comprises a high-speed bus protocol and a non-high-speed bus protocol. Specifically, the soc verification platform can derive test _ vseq0, test _ vseq1, … and test _ vseqN through soc _ base _ vseq; by calling test _ vseq0, test _ vseq1, … and test _ vseqN, scenario _ vseq0, scenario _ vseq1, … and scenario _ vseqM are obtained.
S706, testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; and taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface.
In this step, the soc verification platform may test the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested for the current test interface; and taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface. Specifically, the soc verification platform may send each data packet in a test sequence corresponding to the current test interface to the chip to be tested, and press the serial number of each data packet into a predefined queue; if the correct response of each data packet is received within the response time corresponding to the data packet, the soc verification platform can delete the serial number of the data packet in the queue; if the serial numbers of all the data packets in the queue are deleted, the soc verification platform can judge that the test result returned by the chip to be tested aiming at the current test interface is passed through verification; if the serial numbers of all the data packets in the queue are not deleted, the soc verification platform can determine that the test result returned by the chip to be tested for the current test interface is unverified and passed.
Fig. 8 is a schematic structural diagram of a packet number queue according to an embodiment of the present application. As shown in fig. 8, the AXI interface needs to support characteristics such as outranging, out-of-order, and the like, that is, continuous data packets are sent non-blocking, a read operation task or a write operation task needs to wait until an AXI data read response or write response returns to be ended, and the AXI non-blocking data packets cannot be sent continuously. Not waiting for a return may result in a write response queue overflow and the read data not being received. Therefore, it is necessary to define a queue trans _ q in a task of reading or writing a memory, push the packet number into the queue when sending an AXI packet, wait for the packet response while continuing to send subsequent packets in parallel, and implement the AXI non-blocking mode sending outranging. When each packet receives the response, the number of the packet is obtained, the packet number is compared with the number sequence in the queue trans _ q, and if the number is equal, the number is deleted from the queue trans _ q. For the task of writing the memory, waiting for the queue trans _ q to be emptied in the non-blocking mode to show that all data packets sent by the task receive responses and the task is normally finished. For the memory space reading task, in order to collect all the read data, the read data obtained by each packet of read transaction is cached, all the cached data of the task of this time are merged to obtain all the read data when the queue trans _ q is emptied in the non-blocking mode, and the problem that all the read data cannot be obtained because the operation of this time is finished in advance because the read data is not returned is solved. The simulation time can be compressed to 36.3% of the blocking mode by actually measuring the test case of the typical host read-write memory.
In the specific embodiment of the application, when a user test sequence needs system interrupt, a unified interrupt processing task defined in a base class is called, and after the interrupt is received, a relevant register and a status bit of an interrupt controller are read, written and cleared according to different interrupt sources such as a current master _ id and an interface protocol type. Therefore, the user test sequence only needs to pay attention to the service and interrupt according to the requirement without paying attention to the type difference of the interrupt when the current test sequence is sent by different interfaces.
In embodiments of the present application, the runtime specifies the verification platform parameters, and the modification parameters do not need to be recompiled. Parameters for controlling the verification platform and part of hardware configuration parameters are defined in an aggregation parameter class, non-random parameters are extracted from a command line of a runtime executable command (simv) by using a system function, and are specified in a test case and transmitted to the runtime executable command parameters by an automation tool, so that the platform parameters and the register configuration are modified without recompilation. Meanwhile, the current test sequence can be appointed in the test case in the running process in a mode of overloading the base class sequence, and more flexibility is given to a test case constructor.
And S707, judging whether the chip to be tested passes the verification or fails the verification based on the test result returned by the chip to be tested aiming at each test interface.
In this step, the soc verification platform may determine that the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested for each test interface. Specifically, if the test results returned by the chip to be tested for each test interface are all verified, the soc verification platform can determine that the chip to be tested passes verification; if the test result returned by the chip to be tested aiming at any test interface is unverified, the soc verification platform can judge that the chip to be tested is unverified.
The method and the device for testing the chip can obviously improve the efficiency of developing the test sequence and the test case by a chip verification engineer, and simultaneously support the test to cover all functional scenes. AI chip system level verification sequences often reach hundreds, and the multiplexing of the same group of sequences in various interfaces and scenes avoids repeated development. The platform parameters can be modified in the test case without recompilation, the structure of the test case is simplified, and the verification iteration time is greatly shortened. Meanwhile, the problem that errors are caused due to the fact that accumulated version differences are difficult to find out when a large number of repeated codes are copied in actual development is solved. In the project practice, the overall efficiency of cloud AI chip system-level verification is improved by 200-300%. The verification accelerates convergence, so that the development time of the chip is shortened, and the streaming state is reached earlier.
The chip verification method provided by the embodiment of the application comprises the steps of firstly constructing a corresponding test sequence aiming at a current test interface based on a default sequence constructed in advance; then testing the chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operation until obtaining the test result returned by the chip to be tested aiming at each test interface; and finally, judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface. That is to say, the default sequence in the present application has a clear hierarchical structure, and a test sequence meeting the requirements of different test interfaces can be constructed by calling a general basic task in the default sequence, so that a platform user does not need to write corresponding test sequences for different test interfaces, and does not need to pay attention to implementation details of a protocol bottom layer and specific parameters of a sending interface. However, the existing soc simulation verification platform is not clear enough about the layering of the test sequence, and when a platform user constructs the test of various application scenarios, the platform user needs to pay attention to not only the function scenario of the test, but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface. Because the technical means of constructing the corresponding test sequence aiming at the current test interface based on the default sequence constructed in advance is adopted, the technical problems of large workload, long verification time, lack of expandability and the like caused by the fact that the existing platform user needs to pay attention to not only the function scene of the test but also the implementation details of the protocol bottom layer and the specific parameters of the sending interface when constructing the test of various application scenes are solved; the verification time can be shortened, and the expandability is enhanced; moreover, the technical scheme of the embodiment of the application is simple and convenient to implement, convenient to popularize and wide in application range.
Example four
Fig. 9 is a schematic structural diagram of a chip verification apparatus according to an embodiment of the present application. As shown in fig. 9, the apparatus 900 includes: a construction module 901, a test module 902 and a verification module 903; wherein the content of the first and second substances,
the constructing module 901 is configured to construct a corresponding test sequence for a current test interface based on a default sequence constructed in advance;
the test module 902 is configured to test a chip to be tested on the current test interface based on a test sequence corresponding to the current test interface, so as to obtain a test result returned by the chip to be tested for the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operations until obtaining the test result returned by the chip to be tested aiming at each test interface;
the verification module 903 is configured to determine that the chip to be tested passes verification or fails verification based on a test result returned by the chip to be tested for each test interface.
Further, the building module 901 is specifically configured to receive a test configuration parameter input by a user for the current test interface; wherein the test configuration parameters at least comprise interface number identification; acquiring a general basic task corresponding to the current test interface in the default sequence based on the test configuration parameters; wherein the default sequence includes at least one generic base task; the generic basic tasks include, but are not limited to: a read operation task, a write operation task, an initialization program and an interrupt processing program; the read operation task comprises the following steps: a read register and a read memory; the write operation task comprises the following steps: a write register and a write memory; and constructing a corresponding test sequence aiming at the current test interface based on the general basic task corresponding to the current test interface.
Further, the building module 901 is specifically configured to determine, based on the test configuration parameters, at least one virtual sequencer member corresponding to the current test interface in a pre-specified virtual sequencer; and acquiring a universal basic task corresponding to the current test interface in the default sequence through the at least one virtual sequencer member and a verification component connected with each virtual sequencer member in advance.
Further, the building module 901 is specifically configured to obtain at least one test sequence composed of a plurality of the read operation tasks and a plurality of the write operation tasks based on a general basic task corresponding to the current test interface; obtaining a test sequence corresponding to the current test interface by calling at least one test sequence consisting of a plurality of read operation tasks and a plurality of write operation tasks; wherein the verification component includes a high speed bus protocol and a non-high speed bus protocol.
Further, the test module 902 is specifically configured to send each data packet in the test sequence corresponding to the current test interface to the chip to be tested, and press the number of each data packet into a predefined queue; if the correct response of the data packet is received within the response time length corresponding to each data packet, deleting the number of the data packet in the queue; if the serial numbers of all the data packets in the queue are deleted, the test result returned by the chip to be tested aiming at the current test interface is verified to be passed; and if the serial numbers of all the data packets in the queue are not deleted, the test result returned by the chip to be tested aiming at the current test interface is unverified and passed.
Further, the verification module 903 is specifically configured to determine that the chip to be tested passes verification if the test results returned by the chip to be tested for each test interface are verification passed; and if the test result returned by the chip to be tested aiming at any test interface is unverified, judging that the chip to be tested is unverified.
The chip verification device can execute the method provided by any embodiment of the application, and has the corresponding functional modules and beneficial effects of the execution method. For details of the chip verification method provided in any embodiment of the present application, reference may be made to the technical details not described in detail in this embodiment.
In the technical scheme of the disclosure, the acquisition, storage, application and the like of the personal information of the related user all accord with the regulations of related laws and regulations, and do not violate the good customs of the public order.
EXAMPLE five
The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.
FIG. 10 illustrates a schematic block diagram of an example electronic device 1000 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.
As shown in fig. 10, the apparatus 1000 includes a computing unit 1001 that can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM)1002 or a computer program loaded from a storage unit 1008 into a Random Access Memory (RAM) 1003. In the RAM 1003, various programs and data necessary for the operation of the device 1000 can also be stored. The calculation unit 1001, the ROM1002, and the RAM 1003 are connected to each other by a bus 1004. An input/output (I/O) interface 1005 is also connected to bus 1004.
A number of components in device 1000 are connected to I/O interface 1005, including: an input unit 1006 such as a keyboard, a mouse, and the like; an output unit 1007 such as various types of displays, speakers, and the like; a storage unit 1008 such as a magnetic disk, an optical disk, or the like; and a communication unit 1009 such as a network card, a modem, a wireless communication transceiver, or the like. The communication unit 1009 allows the device 1000 to exchange information/data with other devices through a computer network such as the internet and/or various telecommunication networks.
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.
Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.
The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), Wide Area Networks (WANs), and the Internet.
The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server with a combined blockchain.
It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.
The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.
Claims (15)
1. A method of chip verification, the method comprising:
constructing a corresponding test sequence aiming at the current test interface based on a default sequence constructed in advance;
testing a chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operations until obtaining the test result returned by the chip to be tested aiming at each test interface;
and judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface.
2. The method of claim 1, wherein constructing a corresponding test sequence for a current test interface based on a pre-constructed default sequence comprises:
receiving test configuration parameters input by a user aiming at the current test interface; wherein the test configuration parameters at least comprise interface number identification;
acquiring a general basic task corresponding to the current test interface in the default sequence based on the test configuration parameters; wherein the default sequence includes at least one generic base task; the generic basic tasks include, but are not limited to: a read operation task, a write operation task, an initialization program and an interrupt processing program; the read operation task comprises the following steps: a read register and a read memory; the write operation task comprises the following steps: a write register and a write memory;
and constructing a corresponding test sequence aiming at the current test interface based on the general basic task corresponding to the current test interface.
3. The method of claim 2, wherein the obtaining a generic base task corresponding to the current test interface in the default sequence based on the test configuration parameters comprises:
determining at least one virtual sequencer member corresponding to the current test interface in a pre-designated virtual sequencer based on the test configuration parameters;
and acquiring a universal basic task corresponding to the current test interface in the default sequence through the at least one virtual sequencer member and a verification component connected with each virtual sequencer member in advance.
4. The method of claim 2, wherein constructing a corresponding test sequence for the current test interface based on the common base task corresponding to the current test interface comprises:
obtaining at least one test sequence consisting of a plurality of read operation tasks and a plurality of write operation tasks based on a general basic task corresponding to the current test interface;
obtaining a test sequence corresponding to the current test interface by calling at least one test sequence consisting of a plurality of read operation tasks and a plurality of write operation tasks; wherein the verification component includes a high speed bus protocol and a non-high speed bus protocol.
5. The method according to claim 1, wherein the testing a chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested for the current test interface includes:
respectively sending each data packet in the test sequence corresponding to the current test interface to the chip to be tested, and respectively pressing the serial number of each data packet into a predefined queue;
if the correct response of the data packet is received within the response time length corresponding to each data packet, deleting the number of the data packet in the queue;
if the serial numbers of all the data packets in the queue are deleted, the test result returned by the chip to be tested aiming at the current test interface is verified to be passed; and if the serial numbers of all the data packets in the queue are not deleted, the test result returned by the chip to be tested aiming at the current test interface is unverified and passed.
6. The method of claim 1, wherein the determining that the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested for each test interface comprises:
if the test results returned by the chip to be tested aiming at the test interfaces are all verified, judging that the chip to be tested passes the verification; and if the test result returned by the chip to be tested aiming at any test interface is unverified, judging that the chip to be tested is unverified.
7. A chip verification apparatus, the apparatus comprising: the system comprises a construction module, a test module and a verification module; wherein the content of the first and second substances,
the building module is used for building a corresponding test sequence for the current test interface based on a default sequence built in advance;
the test module is used for testing a chip to be tested on the current test interface based on the test sequence corresponding to the current test interface to obtain a test result returned by the chip to be tested aiming at the current test interface; taking the next test interface of the current test interface as the current test interface, and repeatedly executing the operations until obtaining the test result returned by the chip to be tested aiming at each test interface;
and the verification module is used for judging whether the chip to be tested passes verification or fails verification based on the test result returned by the chip to be tested aiming at each test interface.
8. The apparatus of claim 7, wherein the building module is specifically configured to receive test configuration parameters input by a user for the current test interface; wherein the test configuration parameters at least comprise interface number identification; acquiring a general basic task corresponding to the current test interface in the default sequence based on the test configuration parameters; wherein the default sequence includes at least one generic base task; the generic basic tasks include, but are not limited to: a read operation task, a write operation task, an initialization program and an interrupt processing program; the read operation task comprises the following steps: a read register and a read memory; the write operation task comprises the following steps: a write register and a write memory; and constructing a corresponding test sequence aiming at the current test interface based on the general basic task corresponding to the current test interface.
9. The apparatus according to claim 8, wherein the building module is specifically configured to determine, based on the test configuration parameters, at least one virtual sequencer member corresponding to the current test interface in a pre-specified virtual sequencer; and acquiring a universal basic task corresponding to the current test interface in the default sequence through the at least one virtual sequencer member and a verification component connected with each virtual sequencer member in advance.
10. The apparatus according to claim 8, wherein the building module is specifically configured to obtain at least one test sequence composed of a plurality of the read operation tasks and a plurality of the write operation tasks based on a general basic task corresponding to the current test interface; obtaining a test sequence corresponding to the current test interface by calling at least one test sequence consisting of a plurality of read operation tasks and a plurality of write operation tasks; wherein the verification component includes a high speed bus protocol and a non-high speed bus protocol.
11. The apparatus according to claim 7, wherein the test module is specifically configured to send each data packet in the test sequence corresponding to the current test interface to the chip to be tested, and press the serial number of each data packet into a predefined queue; if the correct response of the data packet is received within the response time length corresponding to each data packet, deleting the number of the data packet in the queue; if the serial numbers of all the data packets in the queue are deleted, the test result returned by the chip to be tested aiming at the current test interface is verified to be passed; and if the serial numbers of all the data packets in the queue are not deleted, the test result returned by the chip to be tested aiming at the current test interface is unverified and passed.
12. The apparatus according to claim 7, wherein the verification module is specifically configured to determine that the chip to be tested passes verification if the test results returned by the chip to be tested for each test interface are verification passed; and if the test result returned by the chip to be tested aiming at any test interface is unverified, judging that the chip to be tested is unverified.
13. An electronic device, comprising:
at least one processor; and
a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.
14. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-6.
15. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110932656.7A CN113656227A (en) | 2021-08-13 | 2021-08-13 | Chip verification method and device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110932656.7A CN113656227A (en) | 2021-08-13 | 2021-08-13 | Chip verification method and device, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113656227A true CN113656227A (en) | 2021-11-16 |
Family
ID=78491601
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110932656.7A Pending CN113656227A (en) | 2021-08-13 | 2021-08-13 | Chip verification method and device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113656227A (en) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114338540A (en) * | 2022-03-17 | 2022-04-12 | 上海国微思尔芯技术股份有限公司 | Signal shunting method and device, electronic equipment and storage medium |
| CN114386366A (en) * | 2021-12-31 | 2022-04-22 | 北京得瑞领新科技有限公司 | Automatic detection system and method for chip read-write performance in IC verification environment |
| CN114386365A (en) * | 2021-12-29 | 2022-04-22 | 北京得瑞领新科技有限公司 | Data verification method and system based on verification platform and electronic equipment |
| CN115629991A (en) * | 2022-12-12 | 2023-01-20 | 摩尔线程智能科技(北京)有限责任公司 | Reset method, device, equipment, storage medium and program product for verification environment |
| CN115794503A (en) * | 2022-09-30 | 2023-03-14 | 湖南智存合壹信息科技有限公司 | High-performance testing device and method based on domestic CPU mainboard |
| CN116132186A (en) * | 2023-02-22 | 2023-05-16 | 广州万协通信息技术有限公司 | Verification method and verification device of security algorithm module and electronic equipment |
| CN117234831A (en) * | 2023-11-14 | 2023-12-15 | 鹏钛存储技术(南京)有限公司 | Chip function test method and system based on multi-core CPU |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050086565A1 (en) * | 2003-10-01 | 2005-04-21 | Thompson Ryan C. | System and method for generating a test case |
| CN110275818A (en) * | 2018-03-13 | 2019-09-24 | 龙芯中科技术有限公司 | Method of generating test program, device and storage medium |
| CN110659199A (en) * | 2018-06-29 | 2020-01-07 | 中国矿业大学 | Class integration test sequence generation method based on transfer dependence |
-
2021
- 2021-08-13 CN CN202110932656.7A patent/CN113656227A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050086565A1 (en) * | 2003-10-01 | 2005-04-21 | Thompson Ryan C. | System and method for generating a test case |
| CN110275818A (en) * | 2018-03-13 | 2019-09-24 | 龙芯中科技术有限公司 | Method of generating test program, device and storage medium |
| CN110659199A (en) * | 2018-06-29 | 2020-01-07 | 中国矿业大学 | Class integration test sequence generation method based on transfer dependence |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114386365A (en) * | 2021-12-29 | 2022-04-22 | 北京得瑞领新科技有限公司 | Data verification method and system based on verification platform and electronic equipment |
| CN114386366A (en) * | 2021-12-31 | 2022-04-22 | 北京得瑞领新科技有限公司 | Automatic detection system and method for chip read-write performance in IC verification environment |
| CN114338540A (en) * | 2022-03-17 | 2022-04-12 | 上海国微思尔芯技术股份有限公司 | Signal shunting method and device, electronic equipment and storage medium |
| CN114338540B (en) * | 2022-03-17 | 2022-07-15 | 上海国微思尔芯技术股份有限公司 | Signal shunting method and device, electronic equipment and storage medium |
| CN115794503A (en) * | 2022-09-30 | 2023-03-14 | 湖南智存合壹信息科技有限公司 | High-performance testing device and method based on domestic CPU mainboard |
| CN115629991A (en) * | 2022-12-12 | 2023-01-20 | 摩尔线程智能科技(北京)有限责任公司 | Reset method, device, equipment, storage medium and program product for verification environment |
| CN116132186A (en) * | 2023-02-22 | 2023-05-16 | 广州万协通信息技术有限公司 | Verification method and verification device of security algorithm module and electronic equipment |
| CN116132186B (en) * | 2023-02-22 | 2024-02-27 | 广州万协通信息技术有限公司 | Verification method and device of security algorithm module, electronic equipment and storage medium |
| CN117234831A (en) * | 2023-11-14 | 2023-12-15 | 鹏钛存储技术(南京)有限公司 | Chip function test method and system based on multi-core CPU |
| CN117234831B (en) * | 2023-11-14 | 2024-01-26 | 鹏钛存储技术(南京)有限公司 | Chip function test method and system based on multi-core CPU |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113656227A (en) | Chip verification method and device, electronic equipment and storage medium | |
| US9317637B2 (en) | Distributed hardware device simulation | |
| US5390320A (en) | Automatically converting structured analysis tool database outputs into an integrated simulation model via transportable standardized metafile | |
| US10180850B1 (en) | Emulating applications that use hardware acceleration | |
| JP6600011B2 (en) | Efficient waveform generation for emulation | |
| CN115657553A (en) | PCIE topology and PCIE equipment simulation method, device, equipment and medium | |
| CN113568821A (en) | Method, device, equipment and medium for testing computation performance of AI chip | |
| CN110569154B (en) | Chip interface function testing method, system, terminal and storage medium | |
| US9501591B2 (en) | Dynamically modifiable component model | |
| CN115168130A (en) | Chip testing method and device, electronic equipment and storage medium | |
| CN116909639B (en) | Mounting system, method, cluster and storage medium | |
| CN113919158A (en) | Simulation method and device for flight control panel and storage medium | |
| CN116681013B (en) | Simulation verification method, platform, device, equipment and medium of network chip | |
| US7231334B2 (en) | Coupler interface for facilitating distributed simulation of a partitioned logic design | |
| US7945418B2 (en) | Stream based stimulus definition and delivery via interworking | |
| CN114743586B (en) | Mirror image storage implementation method and device of storage model and storage medium | |
| US11475199B1 (en) | Parallelizing simulation and hardware co-simulation of circuit designs through partitioning | |
| US20150154038A1 (en) | Scriptable hierarchical emulation engine | |
| US11630935B1 (en) | Data traffic injection for simulation of circuit designs | |
| US20230289500A1 (en) | Method and system for building hardware images from heterogeneous designs for eletronic systems | |
| US20220382942A1 (en) | Non-functional loopback-paths removal from io-pads using logic replication | |
| TWI837026B (en) | Verification system, verification method, electronic device and storage medium | |
| CN116795605B (en) | Automatic recovery system and method for abnormality of peripheral device interconnection extension equipment | |
| US20230114858A1 (en) | Circuit design simulation and clock event reduction | |
| US20240111694A1 (en) | Node identification allocation in a multi-tile system with multiple derivatives |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20211111 Address after: Baidu building, No. 10, Shangdi 10th Street, Haidian District, Beijing 100086 Applicant after: Kunlun core (Beijing) Technology Co., Ltd Address before: 2 / F, baidu building, No. 10, Shangdi 10th Street, Haidian District, Beijing 100085 Applicant before: Beijing Baidu Netcom Science Technology Co., Ltd. |
|
| TA01 | Transfer of patent application right | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |