CN117131821A - Chip verification method and device, electronic equipment and storage medium - Google Patents

Chip verification method and device, electronic equipment and storage medium Download PDF

Info

Publication number
CN117131821A
CN117131821A CN202311387994.2A CN202311387994A CN117131821A CN 117131821 A CN117131821 A CN 117131821A CN 202311387994 A CN202311387994 A CN 202311387994A CN 117131821 A CN117131821 A CN 117131821A
Authority
CN
China
Prior art keywords
tested
simulation
simulation module
target
module
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.)
Granted
Application number
CN202311387994.2A
Other languages
Chinese (zh)
Other versions
CN117131821B (en
Inventor
朱永启
刘冠豪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nanjing Semidrive Technology Co Ltd
Original Assignee
Nanjing Semidrive Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Nanjing Semidrive Technology Co Ltd filed Critical Nanjing Semidrive Technology Co Ltd
Priority to CN202311387994.2A priority Critical patent/CN117131821B/en
Publication of CN117131821A publication Critical patent/CN117131821A/en
Application granted granted Critical
Publication of CN117131821B publication Critical patent/CN117131821B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/33—Design verification, e.g. functional simulation or model checking
    • G06F30/3308—Design verification, e.g. functional simulation or model checking using simulation
    • G06F30/331—Design verification, e.g. functional simulation or model checking using simulation with hardware acceleration, e.g. by using field programmable gate array [FPGA] or emulation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2115/00—Details relating to the type of the circuit
    • G06F2115/02—System on chip [SoC] design
    • 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

Abstract

The application discloses a chip verification method, a chip verification device, electronic equipment and a storage medium. The method comprises the following steps: executing a first test case through a first simulation hardware domain, sending a handshake signal to a verification platform, and controlling a simulation module to be tested to execute a target operation process in a first running state; responding to the handshake signal through the verification platform, executing a second test case in parallel with the first test case, sending a first input signal to the simulation module to be tested in a random delay time length, and triggering the simulation module to be tested to switch to a second running state at a random time node in a target operation process; and acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal through the verification platform. The method can meet the verification requirement of the functional module to be tested of the target chip under various use scenes.

Description

Chip verification method and device, electronic equipment and storage medium
Technical Field
The present application relates to the field of chip design technologies, and in particular, to a chip verification method, a device, an electronic apparatus, and a storage medium.
Background
In the verification process of a System On Chip (SOC), a test case (case) is generally written in a C language, and a processor in the SOC sequentially executes the test case, sends a signal to an IP core to be tested, and controls the IP core to be tested to verify a certain function. However, such a verification method cannot meet the flexible setting of the time sequence relationship among the plurality of state jumps of the IP core to be tested, and cannot meet the verification requirement of diversified use scenes of the IP core to be tested in the SOC.
Disclosure of Invention
In view of the foregoing problems in the prior art, the present application provides a chip verification method, a chip verification device, an electronic device, and a computer readable storage medium, and the technical solutions adopted by the embodiments of the present application are as follows.
The application provides a chip verification method, which is used for verifying a simulation chip in a simulation environment formed by a verification platform, wherein the simulation chip is formed based on the design scheme simulation of a target chip, the simulation chip comprises a first simulation hardware domain and a to-be-tested simulation module, the first simulation hardware domain is used for simulating the first hardware domain of the target chip, and the to-be-tested simulation module is used for simulating the to-be-tested functional module of the target chip;
The method comprises the following steps:
executing a first test case through the first simulation hardware domain, sending a handshake signal to the verification platform, and controlling the simulation module to be tested to execute a target operation process in a first running state; the target operational procedure includes at least one target operation;
responding to the handshake signal through the verification platform, executing a second test case in parallel with the first test case, sending a first input signal to the simulation module to be tested in a random delay time length, and triggering the simulation module to be tested to switch to a second running state at a random time node in the target operation process;
and acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal through the verification platform.
In some embodiments, the simulation chip further comprises a second simulation hardware domain for simulating a second hardware domain of the target chip, the to-be-tested simulation module is connected with the first simulation pin group of the simulation chip, and the second simulation hardware domain is connected with the second simulation pin group of the simulation chip;
the verification platform is provided with an auxiliary circuit which is respectively connected with the first simulation pin group and the second simulation pin group so as to form a simulation communication path between the simulation module to be tested and the second simulation hardware domain;
Controlling the to-be-tested simulation module to execute a target operation process in a first running state, wherein the to-be-tested simulation module comprises the following components:
and controlling the simulation module to be tested to send target data to the second simulation hardware domain based on the simulation communication path in the first running state.
In some embodiments, the random delay time length sends a first input signal to the to-be-tested simulation module, and the random time node in the target operation process triggers the to-be-tested simulation module to switch to a second running state, including:
and the random delay time length transmits a first input signal to the simulation module to be tested, and when the target data is transmitted to a random data bit, the simulation module to be tested is triggered to switch to the second running state.
In some embodiments, the random delay time length sends a first input signal to the to-be-tested simulation module, and the random time node in the target operation process triggers the to-be-tested simulation module to switch to a second running state, including:
before the simulation module to be tested executes the sending operation of the target data, a first input signal is sent to the simulation module to be tested, the simulation module to be tested is controlled to be switched to the second running state, and the sending operation of the target data is stopped; or alternatively
In the process that the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state after the to-be-tested simulation module completes the sending operation of the target data; or alternatively
After the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state so as to prohibit the to-be-tested simulation module from executing the data sending operation.
In some embodiments, the target operational procedure includes a send operation of a plurality of target data; the method further comprises the steps of:
sending a second input signal to the simulation module to be tested, triggering the simulation module to be tested to switch back to the first running state from the second running state, and enabling the simulation module to be tested to continuously execute the sending operation of the target data;
correspondingly, obtaining, by the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested for the first input signal, including:
And acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal and the second input signal through the verification platform.
In some embodiments, the obtaining, by the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested for the first input signal includes:
acquiring first state information through the second simulation hardware domain, wherein the first state information is used for identifying the operation state of the sending operation of the target data;
acquiring second state information through the verification platform, wherein the second state information is used for identifying the running state of the simulation module to be tested;
and acquiring the verification result based on the first state information and the second state information.
In some embodiments, sending handshake signals to the authentication platform includes:
and adding the handshake signal to a target register with access rights of the verification platform through the first simulation hardware domain.
In some embodiments, the random delay time length sends a first input signal to the to-be-tested simulation module, and the random time node in the target operation process triggers the to-be-tested simulation module to switch to a second running state, including:
And sending a first input signal to the simulation module to be tested at random time within the range of the target delay time length, and triggering the simulation module to be tested to switch to a second running state by a random time node of specific target operation in the target operation process.
The application provides a chip verification device, which is used for verifying a simulation chip in a simulation environment formed by a verification platform, wherein the simulation chip is formed based on the design scheme simulation of a target chip, the simulation chip comprises a first simulation hardware domain and a to-be-tested simulation module, the first simulation hardware domain is used for simulating the first hardware domain of the target chip, and the to-be-tested simulation module is used for simulating the to-be-tested functional module of the target chip;
the device comprises:
the control module is used for executing a first test case through the first simulation hardware domain, sending a handshake signal to the verification platform and controlling the simulation module to be tested to execute a target operation process in a first running state; the target operational procedure includes at least one target operation;
the sending module is used for responding to the handshake signal through the verification platform, executing a second test case in parallel with the first test case, sending a first input signal to the simulation module to be tested in a random delay time length, and triggering the simulation module to be tested to switch to a second running state at a random time node in the target operation process;
And the acquisition module is used for acquiring the verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal through the verification platform.
A third aspect of the application provides an electronic device comprising at least a memory having an application stored thereon and a processor which when executing the application on the memory implements a method as described above.
A fourth aspect of the application provides a computer readable storage medium having stored therein computer executable instructions which when executed implement a method as described above.
According to the chip verification method, the first simulation hardware domain is used for executing the first test case so as to control the to-be-tested simulation module to execute the target operation process, the verification platform is controlled to execute the second test case in parallel by sending the handshake signals to the verification platform, the first input signals are sent to the to-be-tested simulation module in random delay time, and the to-be-tested simulation module is triggered to switch to the second operation state at a random time node for executing the target operation process. Therefore, whether the functionality and the correctness of the functional module to be tested meet design expectations or not can be verified under the random time sequence relation between the target operation process and the state switching process from the first operation state to the second operation state, the functional module to be tested has higher flexibility, and the verification requirement of the functional module to be tested of the target chip under diversified use scenes can be met.
Drawings
FIG. 1 is an exemplary system architecture of a chip authentication method or chip authentication apparatus to which embodiments of the present application are applied;
FIG. 2 is a flow chart of a chip verification method according to an embodiment of the application;
FIG. 3 is a flowchart of step S230 in a chip verification method according to an embodiment of the present application;
FIG. 4 is a block diagram of a chip authentication device according to an embodiment of the present application;
fig. 5 is a block diagram of an electronic device according to an embodiment of the present application.
Detailed Description
Various aspects and features of the present application are described herein with reference to the accompanying drawings.
It should be understood that various modifications may be made to the embodiments of the application herein. Therefore, the above description should not be taken as limiting, but merely as exemplification of the embodiments. Other modifications within the scope and spirit of the application will occur to persons of ordinary skill in the art.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the application and, together with a general description of the application given above, and the detailed description of the embodiments given below, serve to explain the principles of the application.
These and other characteristics of the application will become apparent from the following description of a preferred form of embodiment, given as a non-limiting example, with reference to the accompanying drawings.
It is also to be understood that, although the application has been described with reference to some specific examples, many other equivalent forms of implementing the application can be made by those skilled in the art, which are intended to be within the scope of the application as defined in the claims.
The above and other aspects, features and advantages of the present application will become more apparent in light of the following detailed description when taken in conjunction with the accompanying drawings.
Specific embodiments of the present application will be described hereinafter with reference to the accompanying drawings; however, it is to be understood that the disclosed embodiments are merely exemplary of the application, which can be embodied in various forms. Well-known and/or repeated functions and constructions are not described in detail to avoid obscuring the application in unnecessary or unnecessary detail. Therefore, specific structural and functional details disclosed herein are not intended to be limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present application in virtually any appropriately detailed structure.
The specification may use the word "in one embodiment," "in another embodiment," "in yet another embodiment," or "in other embodiments," which may each refer to one or more of the same or different embodiments in accordance with the application.
Fig. 1 illustrates an exemplary system architecture to which the chip authentication method or chip authentication apparatus of the embodiment of the present application may be applied, and referring to fig. 1, the system architecture includes an authentication platform 100. The verification platform 100 is used for forming a simulation environment, in which a simulation chip 110 can be formed based on a design scheme of a target chip in a simulation manner, and the simulation chip 110 includes a first simulation hardware domain 111 and a simulation module to be tested 112.
Alternatively, the verification platform 100 may include a software verification tool and an electronic device supporting the operation of the software verification tool, the electronic device operating the software verification tool to form the simulation environment. Including but not limited to servers, workstations, desktop computers, notebook computers, and the like. Optionally, the target chip includes, but is not limited to, a system on a chip (SOC).
The first emulation hardware domain 111 is used to emulate a first hardware domain of a target chip. Optionally, the first hardware domain may include any hardware domain in the target chip. For example, the first hardware domain may be a security domain in the target chip, or may be an application domain in the target chip.
The to-be-tested simulation module 112 is used for simulating the to-be-tested functional module of the target chip. Optionally, the functional module to be tested may include a hardware domain in the target chip, and may also include a computing unit, a graphics processing unit, or other hardware resource modules in the target chip.
Optionally, the emulation chip 110 may further include a second emulation hardware domain 113, and the second emulation hardware domain 113 may be used to emulate a second hardware domain of the target chip. The to-be-tested simulation module 112 may be connected to a first simulation pin set 114 of the simulation chip 110, and the second simulation hardware domain 113 may be connected to a second simulation pin set 115 of the simulation chip 110. The verification platform 100 is provided with an auxiliary circuit 120, and the auxiliary circuit 120 is respectively connected with the first simulation pin group 114 and the second simulation pin group 115 to form a simulation communication path between the to-be-tested simulation module 112 and the second simulation hardware domain 113.
Optionally, each of the first dummy pin group 114 and the second dummy pin group 115 may include one or more dummy pins. Optionally, the auxiliary circuit 120 may include a connection line connected between the first emulation pin group 114 and the second emulation pin group, and may also include an intermediate component, such as a controller, a processor, a hardware domain, etc., connected between the first emulation pin group 114 and the second emulation pin group 115.
Optionally, a verification host 130 may be further disposed in the emulation environment of the verification platform 100, and the verification host 130 may be connected to the emulation chip through, for example, an advanced peripheral BUS (APB BUS).
The embodiment of the application provides a chip verification method which is used for verifying a simulation chip in a simulation environment formed by a verification platform. Fig. 2 shows a flowchart of a chip verification method according to an embodiment of the present application, and referring to fig. 2, the chip verification method according to an embodiment of the present application may specifically include the following steps.
S210, executing a first test case through the first simulation hardware domain, sending a handshake signal to the verification platform, and controlling the simulation module to be tested to execute a target operation process in a first running state; the target operational procedure includes at least one target operation.
Optionally, the first test case may include a test step performed by the first emulated hardware domain. For example, the first test case may include a test program compiled using a C language, the test program may include one or more test instructions, and the first emulation hardware domain may execute each of the test instructions. When the method is actually applied, the first test case can be compiled in advance, the first simulation hardware domain is imported, the first simulation hardware domain is triggered to execute each test instruction in the first test case, handshake signals are sent to the verification platform based on the test instructions, and instructions are sent to the simulation module to be tested to instruct the simulation module to be tested to execute a target operation process in a first running state. Optionally, the first test case may further include, but is not limited to, test purposes, input data, expected results, and the like.
Optionally, the first emulation hardware domain may add the handshake signal to a target register, which may be a register of the verification platform having access rights. The verification platform may periodically detect the value of the target register to obtain the handshake signal. For example, the first emulated hardware domain may write the handshake signals into a common register, and the verification platform may obtain the handshake signals by accessing the common register. Alternatively, the target register may be a physical register on the verification platform, or may be a virtual register located in the emulation chip or in the emulation environment.
It will be appreciated that the first emulated hardware domain may send handshake signals to the authentication platform in other ways as well. For example, the first emulated hardware domain may send handshake signals to the authentication platform based on the manner of inter-process communication or inter-thread communication. For example, a virtual daemon connected to the pins of the emulation chip may be provided in the emulation environment, and the first emulation hardware domain may send the handshake signal to the virtual daemon through the pins of the emulation chip, and transmit the handshake signal to the verification platform through the virtual daemon.
Alternatively, the target operation process may be an operation process that the functional module to be tested of the target chip must be able to perform correctly in order to implement its design function. The target operation procedure may include a single target operation, or may include a plurality of target operations that are performed synchronously or sequentially. For example, the target operation procedure may include a plurality of target operations performed in a preset logical relationship.
Optionally, the first operation state may be an operation state in which the to-be-tested simulation module is capable of executing the target operation process. For example, taking the to-be-tested simulation module as a hardware domain, the first operation state may be a normal operation state of the hardware domain, so that the hardware domain can execute the target operation process. Of course, when the to-be-tested simulation module is another hardware resource module, the first operation state may be another state, as long as the to-be-tested simulation module can execute the target operation process in the first operation state.
S220, responding to the handshake signal through the verification platform, executing a second test case in parallel with the first test case, sending a first input signal to the simulation module to be tested by random delay time, and triggering the simulation module to be tested to switch to a second running state at a random time node in the target operation process.
Optionally, the second test case may include a test step performed by the verification platform. For example, the second test case may include a test program compiled using SV (SystemVerilog) language, which may include one or more test instructions. Of course, the second test case is not limited to be edited by using the SV language, the first test case is also not limited to be edited by using the C language, and the programming language can be selected according to the actual requirement when in actual application.
Optionally, the verification host in the simulation environment may respond to the handshake signal, execute the second test case in parallel with the first test case, randomly determine a delay time length, and start timing. And when the timing result reaches the delay time length, sending a first input signal to the simulation module to be tested based on the APB BUS, so that the simulation module to be tested is triggered to be switched to a second running state at a random time node when the simulation module to be tested executes the target operation process. It can be understood that the second test case may also be executed by a virtual machine on the verification platform or an electronic device forming the verification platform, so long as the first input signal can be sent to the to-be-tested simulation module based on the second test case.
Optionally, the second operation state may be an operation state in which the to-be-detected simulation module cannot execute the target operation process, or the second operation state may be an operation state in which the to-be-detected simulation module executes the target operation process under a conditional condition. For example, the second running state may be a sleep state (DEBUG) of the simulation module under test. And if the to-be-tested simulation module receives the first input signal before executing a certain target operation in the target operation process, stopping executing the target operation by the to-be-tested simulation module and switching to a DEBUG state. And if the to-be-tested simulation module receives the first input signal in the process of executing a certain target operation, the to-be-tested simulation module is switched to a DEBUG state after executing the current target operation. If the to-be-tested simulation module receives the first input signal after executing a certain target operation, the to-be-tested simulation module is immediately switched to a DEBUG state, and the to-be-tested simulation module stops executing other target operations in the target operation process.
Optionally, the random time node in the target operation process triggers the to-be-tested simulation module to switch to the second running state, which may include triggering the to-be-tested simulation module to switch to the second running state before any one of the target operations is executed in the target operation process, or triggering the to-be-tested simulation module to switch to the second running state in any one of the target operations is executed, or triggering the to-be-tested simulation module to switch to the second running state after any one of the target operations is executed.
Optionally, a first input signal may be sent to the to-be-tested simulation module at a random time within a target delay duration range, and a random time node of a specific target operation in the target operation process triggers the to-be-tested simulation module to switch to the second running state. Thus, the random time node in the execution process of the specific target operation can control the simulation module to be tested to perform state switching so as to realize randomness verification in the execution process of the specific target operation. For example, the time range for executing the specific target operation may be determined in advance based on the time consumption of the operation of each target operation, the time range is taken as the target delay duration range, and the target delay duration range is written into the second test case, so that the verification platform can send the first input signal to the to-be-tested simulation module at random time within the target delay duration range based on the second test case.
S230, acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal through the verification platform.
Alternatively, the output information may include, but is not limited to, first state information and second state information. The first status information may be used to identify an operational status of the target operational procedure. For example, the first state information may be used to identify an operation state of a data transmission operation, an operation state of a data reception operation, an operation state of a data processing operation, and the like of the simulation module to be tested. The second state information may be used to identify an operating state of the simulation module to be tested. For example, the second state information may be used to identify the running states of the simulation module under test at different time nodes during the entire verification process. For example, the second state information may be used to identify an operational state of the simulation module under test after receiving the first input signal.
Optionally, based on the first state information and the second state information, it may be determined whether the to-be-tested simulation module is switched from the first operation state to the second operation state, and an operation state of the to-be-tested simulation module executing the target operation process is determined, and further it is determined whether an operation process of the to-be-tested simulation module, in which the to-be-tested simulation module is switched from the first operation state to the second operation state in executing the target operation process, meets an expected result, and a verification result capable of representing whether a to-be-tested function module of the target chip meets a design expectation is obtained. The simulation module to be tested is used for simulating the functional module to be tested of the target chip, so that the verification result can directly reflect whether the functional module to be tested of the target chip accords with design expectations or not and whether the design function can be correctly realized or not.
According to the chip verification method, the first simulation hardware domain is used for executing the first test case so as to control the to-be-tested simulation module to execute the target operation process, the verification platform is controlled to execute the second test case in parallel by sending the handshake signals to the verification platform, the first input signals are sent to the to-be-tested simulation module in random delay time, and the random time node of the to-be-tested simulation module in the process of executing the target operation is triggered to switch to the second operation state. Therefore, whether the functionality and the correctness of the functional module to be tested meet design expectations or not can be verified under the random time sequence relation between the target operation process and the state switching process from the first operation state to the second operation state, the functional module to be tested has higher flexibility, and the verification requirement of the functional module to be tested of the target chip under diversified use scenes can be met.
In some embodiments, step S210, controlling the simulation module under test to execute the target operation process in the first running state may include the following steps.
And controlling the simulation module to be tested to execute the sending operation of the target data in the first running state. Alternatively, the target operation procedure may include a single target data transmission operation, and may also include multiple target data transmission operations.
Optionally, the to-be-tested simulation module can be controlled to send target data to the second simulation hardware domain based on the simulation communication path in the first running state. The simulation module to be tested is configured to be connected with a first simulation pin group of the simulation chip, the second simulation hardware domain is connected with a second simulation pin group of the simulation chip, and the first simulation pin group and the second simulation pin group are connected through an auxiliary circuit, so that a simulation communication channel is formed between the simulation module to be tested and the second simulation hardware domain. And controlling the simulation module to be tested to send target data to the second simulation hardware domain based on the simulation communication path, and verifying the execution condition of the simulation module to be tested for executing the target data sending operation by detecting whether the second simulation hardware domain receives the target data. That is, it can be verified whether the simulation module to be tested successfully transmits the target data. Therefore, whether the target data sending operation of the simulation module to be tested meets the design expectation or not can be verified, and the data receiving object is not required to be arranged outside the simulation chip, so that the system architecture of the verification platform is simplified, and the verification cost is reduced.
It should be noted that, in practical application, the second simulation hardware domain in the simulation chip is not limited to be used as a data receiving object to verify that the to-be-tested simulation module executes the sending operation of the target data. And a verification host can also be arranged in the simulation environment, and is connected with the simulation chip through the verification host, and the verification host is used as a data receiving object.
In some embodiments, step S220, sending a first input signal to the to-be-tested simulation module during a random delay time, and triggering the to-be-tested simulation module to switch to the second running state at a random time node of the target operation process may include the following steps.
And the random delay time length transmits a first input signal to the simulation module to be tested, and when the target data is transmitted to a random data bit, the simulation module to be tested is triggered to switch to the second running state.
Alternatively, the target operation procedure may include a transmission operation of a single target data, which may include a plurality of data bits. The emulation communication path can be configured to communicate based on a target communication protocol and the emulation module under test can be configured to send a plurality of data bits of the target data based on an order specified by the target communication protocol. The verification platform can be configured to send a first input signal to the to-be-tested simulation module in a random delay time length, trigger the to-be-tested simulation module to switch to the second running state when the target data is sent to a random data bit, and verify the functionality and the correctness of the to-be-tested simulation module.
Alternatively, the target operation procedure may also include a transmission operation of a plurality of target data, and each of the target data may include a plurality of data bits. The verification platform can be configured to send a first input signal to the to-be-tested simulation module at random time within a target delay duration range, so that when one specific target data in a plurality of target data is sent to a random data bit, the to-be-tested simulation module is triggered to switch to the second running state, and thus the to-be-tested simulation module performs randomness verification on executing state switching in a specific target data sending process, so that the functionality and the correctness of the to-be-tested simulation module in the scene are verified.
Optionally, the second operation state may be configured such that when the to-be-tested simulation module is switched to the second operation state, the to-be-tested simulation module cannot execute the sending operation of the target data, but the sending operation of the target data that has been started to be executed before the to-be-tested simulation module is switched to the second operation state may be normally executed. On the basis, when the target data is sent to the random data bit, a first input signal is sent to the simulation module to be tested, whether the simulation module to be tested can continuously complete the sending operation of the target data or not can be verified, and whether the simulation module to be tested can be correctly switched to the second running state after the sending operation of the target data is completed or not can be verified.
In some embodiments, step S220, the random delay period sends a first input signal to the to-be-tested simulation module, and the to-be-tested simulation module is triggered to switch to the second running state at the random time node of the target operation process, which may include any one of the following three steps.
Before the simulation module to be tested executes the sending operation of the target data, a first input signal is sent to the simulation module to be tested, the simulation module to be tested is controlled to be switched to the second running state, and the sending operation of the target data is stopped.
And in the process that the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state after the to-be-tested simulation module completes the sending operation of the target data.
After the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state so as to prohibit the to-be-tested simulation module from executing the data sending operation.
Optionally, the first operation state may be configured such that, when the to-be-tested simulation module is in the first operation state, the to-be-tested simulation module can execute a sending operation of the target data. The second operation state may be configured such that when the to-be-tested simulation module is switched to the second operation state, the to-be-tested simulation module cannot perform the transmission operation of the target data, but the transmission operation of the target data that has been started to be performed before the to-be-tested simulation module is switched to the second operation state may be normally performed and completed.
After the verification platform acquires the handshake signals, a delay time length can be randomly determined, and timing is started. And after the timing result reaches the delay time, sending a first input signal to the simulation module to be tested, and triggering the simulation module to be tested to switch to a second running state. Since the delay period is random, there are mainly three cases.
In the first case, before the to-be-tested simulation module starts to execute the sending operation of the target data, the verification platform sends a first input signal to the to-be-tested simulation module, and triggers the to-be-tested simulation module to switch to the second running state. According to the design expectation of the functional module to be tested of the target chip, the simulation module to be tested should stop executing the sending operation of the target data and switch to the second running state.
In the second case, in the process that the to-be-tested simulation module is executing the sending operation of the target data, the verification platform sends a first input signal to the to-be-tested simulation module, and triggers the to-be-tested simulation module to switch to a second running state. According to the design expectation of the functional module to be tested of the target chip, the simulation module to be tested should continue to execute the current sending operation of the target data, and switch to the second running state after the sending operation of the target data is completed.
In the third case, after the to-be-tested simulation module has executed the sending operation of the target data, the verification platform sends a first input signal to the to-be-tested simulation module, and triggers the to-be-tested simulation module to switch to the second running state. According to the design expectation of the functional module to be tested of the target chip, the simulation module to be tested should be switched to the second running state, and no other data sending operation is executed. Therefore, the state switching of the simulation module to be tested under three different scenes can be randomly verified through the cooperation of the first simulation hardware domain and the verification platform.
In some embodiments, the target operational procedure includes a send operation of a plurality of target data. The method further comprises the following steps.
S220', a second input signal is sent to the simulation module to be tested, and the simulation module to be tested is triggered to switch from the second running state to the first running state, so that the simulation module to be tested continues to execute the sending operation of the target data.
Correspondingly, step S230, obtaining, by the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the to-be-tested simulation module for the first input signal, may include the following steps.
And acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal and the second input signal through the verification platform.
Optionally, a second input signal may be sent to the to-be-tested simulation module through the first simulation hardware domain based on the first test case. And the second input signal can be sent to the simulation module to be tested based on the second test case through the verification platform. For example, the second test case may be executed by a verification host in the simulation environment, and the second input signal may be sent to the simulation module under test for a certain delay period after the first input signal is sent to the simulation module under test. And after the simulation module to be tested is switched to the second running state, controlling the simulation module to be tested to be switched from the second running state back to the first running state. And verifying that the simulation module to be tested can be exactly changed back to the first running state, and also verifying whether the transmission operation of the target data can be continuously executed after the simulation module to be tested is switched back to the first running state.
Optionally, the verification platform may determine, based on the output information of the to-be-tested simulation module for the first input signal, whether the functionality and the correctness of the to-be-tested simulation module for switching the random time node to the second running state in the target data transmission process meet design expectations. The verification platform can also determine whether the functionality and the correctness of the to-be-tested simulation module after being switched from the second running state back to the first running state meet design expectations based on the output information of the to-be-tested simulation module aiming at the second input signal.
Referring to fig. 3, in some embodiments, step S230, obtaining, by the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested for the first input signal may include the following steps.
S231, acquiring first state information through the second simulation hardware domain, wherein the first state information is used for identifying the operation state of the sending operation of the target data.
S232, acquiring second state information through the verification platform, wherein the second state information is used for identifying the running state of the simulation module to be tested;
S233, acquiring the verification result based on the first state information and the second state information.
Optionally, the first state information may be used to identify whether the second emulation hardware domain receives the target data, and may be capable of characterizing whether the sending operation of the target data executed by the emulation module to be tested is completed. For example, it may be detected whether a target storage location of the second emulated hardware domain stores the target data, and it is determined whether the second emulated hardware domain receives the target data, thereby obtaining the first state information. Also for example, a data interface of the second emulated hardware domain connected to the emulated communication pathway may hold a data transfer record. Based on this, a data transmission record of the data interface can be obtained to determine whether the second emulation hardware domain receives the target data, thereby obtaining the first state information. Of course, in implementation, it may be determined whether the second emulation hardware domain receives the target data by other methods, and the method of determining whether the second emulation hardware domain receives the target data is not limited herein.
Optionally, the running state of the simulation module to be tested under different time nodes in the whole verification process can be determined through the verification platform, and second state information is generated. The verification platform can also be used for determining the running state of the simulation module to be tested after receiving the first input signal and the running state of the simulation module to be tested after receiving the second input signal, and generating the second state information. For example, the running state of the simulation module to be tested can be determined by detecting the state of a specific pin of the simulation chip. Or the running state of the simulation module to be tested can be determined by interacting with the simulation module to be tested, the first hardware domain or other functional modules in the simulation chip.
Optionally, in the case that the first state information and the second state information are acquired, it may be determined, based on the first state information and the second state information, whether a state switching process of the simulation module to be tested from the first operation state to the second operation state and from the second operation state to the first operation state accords with design expectations. And determining whether the operation state of the sending operation of the target data accords with the design expectation or not when the state switching is carried out on the random time node of the sending operation of the target data, and further generating a verification result which can be used for representing whether the function module to be tested of the target chip accords with the design expectation or not. For example, in the case that the to-be-tested simulation module is triggered to perform state switching before the target data is sent, whether the to-be-tested simulation module stops executing the sending operation of the target data is determined. For example, when the to-be-detected simulation module is triggered to perform state switching in the process of sending the target data, whether the to-be-detected simulation module completes the sending operation of the target data is determined.
The embodiment of the application provides a chip verification device which is used for verifying a simulation chip in a simulation environment formed by a verification platform. Fig. 4 is a block diagram of a chip authentication device according to an embodiment of the present application, and referring to fig. 4, the chip authentication device according to an embodiment of the present application may include:
The control module 301 is configured to execute a first test case through the first simulation hardware domain, send a handshake signal to the verification platform, and control the to-be-tested simulation module to execute a target operation process in a first running state; the target operational procedure includes at least one target operation;
the sending module 302 is configured to respond to the handshake signal through the verification platform, execute a second test case in parallel with the first test case, send a first input signal to the to-be-tested simulation module during a random delay period, and trigger the to-be-tested simulation module to switch to a second running state at a random time node of the target operation process through the first input signal;
and the obtaining module 303 is configured to obtain, by using the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested for the first input signal.
In some embodiments, the control module 301 is specifically configured to:
and controlling the simulation module to be tested to send target data to the second simulation hardware domain based on the simulation communication path in the first running state.
In some embodiments, the sending module 302 is specifically configured to:
And the random delay time length transmits a first input signal to the simulation module to be tested, and when the target data is transmitted to a random data bit, the simulation module to be tested is triggered to switch to the second running state.
In some embodiments, the sending module 302 is specifically configured to:
before the simulation module to be tested executes the sending operation of the target data, a first input signal is sent to the simulation module to be tested, the simulation module to be tested is controlled to be switched to the second running state, and the sending operation of the target data is stopped; or alternatively
In the process that the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state after the to-be-tested simulation module completes the sending operation of the target data; or alternatively
After the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state so as to prohibit the to-be-tested simulation module from executing the data sending operation.
In some embodiments, the target operational procedure includes a send operation of a plurality of target data; the sending module 302 is further configured to:
sending a second input signal to the simulation module to be tested, triggering the simulation module to be tested to switch back to the first running state from the second running state, and enabling the simulation module to be tested to continuously execute the sending operation of the target data;
correspondingly, the obtaining module 303 is specifically configured to:
and acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal and the second input signal through the verification platform.
In some embodiments, the obtaining module 303 is specifically configured to:
acquiring first state information through the second simulation hardware domain, wherein the first state information is used for identifying the operation state of the sending operation of the target data;
acquiring second state information through the verification platform, wherein the second state information is used for identifying the running state of the simulation module to be tested;
and acquiring the verification result based on the first state information and the second state information.
In some embodiments, the control module 301 is specifically configured to:
And adding the handshake signal to a target register with access rights of the verification platform through the first simulation hardware domain.
In some embodiments, the sending module 302 is specifically configured to:
and sending a first input signal to the simulation module to be tested at random time within the range of the target delay time length, and triggering the simulation module to be tested to switch to a second running state by a random time node of specific target operation in the target operation process.
Referring to fig. 5, an embodiment of the present application provides an electronic device, at least including a memory 401 and a processor 402, where the memory 401 stores an application program, and the processor 402 implements the method described in any of the embodiments above when executing the application program on the memory 401.
Embodiments of the present application provide a computer-readable storage medium having stored therein computer-executable instructions that when executed implement a method as in any of the embodiments above.
It will be appreciated by those skilled in the art that embodiments of the application may be provided as a method, an electronic device, a computer-readable storage medium, or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media having computer-usable program code embodied therein. When implemented in software, these functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The processor may be a general purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL) or any combination thereof. The general purpose processor may be a microprocessor or any conventional processor or the like.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
The readable storage medium may be a magnetic disk, an optical disk, a DVD, a USB, a read-only memory (ROM), a random-access memory (RAM), etc., and the present application is not limited to a specific storage medium format.
The above embodiments are only exemplary embodiments of the present application and are not intended to limit the present application, the scope of which is defined by the claims. Various modifications and equivalent arrangements of this application will occur to those skilled in the art, and are intended to be within the spirit and scope of the application.

Claims (11)

1. The chip verification method is characterized by being used for verifying a simulation chip in a simulation environment formed by a verification platform, wherein the simulation chip is formed based on the design scheme simulation of a target chip, the simulation chip comprises a first simulation hardware domain and a to-be-tested simulation module, the first simulation hardware domain is used for simulating the first hardware domain of the target chip, and the to-be-tested simulation module is used for simulating a to-be-tested functional module of the target chip;
the method comprises the following steps:
executing a first test case through the first simulation hardware domain, sending a handshake signal to the verification platform, and controlling the simulation module to be tested to execute a target operation process in a first running state; the target operational procedure includes at least one target operation;
responding to the handshake signal through the verification platform, executing a second test case in parallel with the first test case, sending a first input signal to the simulation module to be tested in a random delay time length, and triggering the simulation module to be tested to switch to a second running state at a random time node in the target operation process;
and acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal through the verification platform.
2. The method of claim 1, wherein the emulation chip further comprises a second emulation hardware domain for emulating a second hardware domain of the target chip, the emulation module to be tested being connected to a first emulation pin group of the emulation chip, the second emulation hardware domain being connected to a second emulation pin group of the emulation chip;
the verification platform is provided with an auxiliary circuit which is respectively connected with the first simulation pin group and the second simulation pin group so as to form a simulation communication path between the simulation module to be tested and the second simulation hardware domain;
controlling the to-be-tested simulation module to execute a target operation process in a first running state, wherein the to-be-tested simulation module comprises the following components:
and controlling the simulation module to be tested to send target data to the second simulation hardware domain based on the simulation communication path in the first running state.
3. The method of claim 2, wherein the randomly delayed time period transmits a first input signal to the simulation module under test, and wherein the triggering of the simulation module under test to switch to the second operational state at the random time node of the target operational process comprises:
and the random delay time length transmits a first input signal to the simulation module to be tested, and when the target data is transmitted to a random data bit, the simulation module to be tested is triggered to switch to the second running state.
4. The method of claim 2, wherein the randomly delayed time period transmits a first input signal to the simulation module under test, and wherein the triggering of the simulation module under test to switch to the second operational state at the random time node of the target operational process comprises:
before the simulation module to be tested executes the sending operation of the target data, a first input signal is sent to the simulation module to be tested, the simulation module to be tested is controlled to be switched to the second running state, and the sending operation of the target data is stopped; or alternatively
In the process that the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state after the to-be-tested simulation module completes the sending operation of the target data; or alternatively
After the to-be-tested simulation module executes the sending operation of the target data, a first input signal is sent to the to-be-tested simulation module, and the to-be-tested simulation module is controlled to be switched to the second running state so as to prohibit the to-be-tested simulation module from executing the data sending operation.
5. The method of claim 4, wherein the target operational procedure comprises a send operation of a plurality of target data; the method further comprises the steps of:
sending a second input signal to the simulation module to be tested, triggering the simulation module to be tested to switch back to the first running state from the second running state, and enabling the simulation module to be tested to continuously execute the sending operation of the target data;
correspondingly, obtaining, by the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested for the first input signal, including:
and acquiring a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal and the second input signal through the verification platform.
6. The method according to any one of claims 3 to 5, wherein obtaining, by the verification platform, a verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested for the first input signal, includes:
acquiring first state information through the second simulation hardware domain, wherein the first state information is used for identifying the operation state of the sending operation of the target data;
Acquiring second state information through the verification platform, wherein the second state information is used for identifying the running state of the simulation module to be tested;
and acquiring the verification result based on the first state information and the second state information.
7. The method of claim 1, wherein sending a handshake signal to the verification platform comprises:
and adding the handshake signal to a target register with access rights of the verification platform through the first simulation hardware domain.
8. The method of claim 1, wherein the randomly delayed time period transmits a first input signal to the simulation module under test, and wherein the triggering of the simulation module under test to switch to the second operational state at the random time node of the target operational process comprises:
and sending a first input signal to the simulation module to be tested at random time within the range of the target delay time length, and triggering the simulation module to be tested to switch to a second running state by a random time node of specific target operation in the target operation process.
9. The chip verification device is characterized by being used for verifying a simulation chip in a simulation environment formed by a verification platform, wherein the simulation chip is formed based on the design scheme simulation of a target chip, the simulation chip comprises a first simulation hardware domain and a to-be-tested simulation module, the first simulation hardware domain is used for simulating the first hardware domain of the target chip, and the to-be-tested simulation module is used for simulating a to-be-tested functional module of the target chip;
The device comprises:
the control module is used for executing a first test case through the first simulation hardware domain, sending a handshake signal to the verification platform and controlling the simulation module to be tested to execute a target operation process in a first running state; the target operational procedure includes at least one target operation;
the sending module is used for responding to the handshake signal through the verification platform, executing a second test case in parallel with the first test case, sending a first input signal to the simulation module to be tested in a random delay time length, and triggering the simulation module to be tested to switch to a second running state at a random time node in the target operation process;
and the acquisition module is used for acquiring the verification result of the functional module to be tested in the target chip based on the output information of the simulation module to be tested aiming at the first input signal through the verification platform.
10. An electronic device comprising at least a memory and a processor, wherein the memory has an application stored thereon, the processor, when executing the application on the memory, implementing the method of any of claims 1 to 8.
11. A computer readable storage medium having stored therein computer executable instructions which when executed implement the method of any of claims 1 to 8.
CN202311387994.2A 2023-10-25 2023-10-25 Chip verification method, device, electronic equipment and storage medium Active CN117131821B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311387994.2A CN117131821B (en) 2023-10-25 2023-10-25 Chip verification method, device, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311387994.2A CN117131821B (en) 2023-10-25 2023-10-25 Chip verification method, device, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN117131821A true CN117131821A (en) 2023-11-28
CN117131821B CN117131821B (en) 2024-01-16

Family

ID=88858514

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311387994.2A Active CN117131821B (en) 2023-10-25 2023-10-25 Chip verification method, device, electronic equipment and storage medium

Country Status (1)

Country Link
CN (1) CN117131821B (en)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050210179A1 (en) * 2002-12-02 2005-09-22 Walmsley Simon R Integrated circuit having random clock or random delay
CN102411535A (en) * 2011-08-02 2012-04-11 上海交通大学 Navigating-SoC (System On Chip) simulating, verifying and debugging platform
CN207096986U (en) * 2017-08-24 2018-03-13 航天中认软件测评科技（北京）有限责任公司 The system of software and hardware cooperating simulation
CN113312879A (en) * 2021-07-28 2021-08-27 北京燧原智能科技有限公司 Chip circuit function verification system, method, device and storage medium
US20210406443A1 (en) * 2020-06-30 2021-12-30 Montage Lz Technologies (Chengdu) Co., Ltd. Verification platform for system on chip and verification method thereof
CN114500146A (en) * 2021-12-30 2022-05-13 南京捷澳芯微科技有限公司 Test verification environment building system and verification method based on model design
CN116796673A (en) * 2023-08-22 2023-09-22 北京芯驰半导体科技有限公司 Test method, test device, electronic equipment and storage medium

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050210179A1 (en) * 2002-12-02 2005-09-22 Walmsley Simon R Integrated circuit having random clock or random delay
CN102411535A (en) * 2011-08-02 2012-04-11 上海交通大学 Navigating-SoC (System On Chip) simulating, verifying and debugging platform
CN207096986U (en) * 2017-08-24 2018-03-13 航天中认软件测评科技（北京）有限责任公司 The system of software and hardware cooperating simulation
US20210406443A1 (en) * 2020-06-30 2021-12-30 Montage Lz Technologies (Chengdu) Co., Ltd. Verification platform for system on chip and verification method thereof
CN113312879A (en) * 2021-07-28 2021-08-27 北京燧原智能科技有限公司 Chip circuit function verification system, method, device and storage medium
CN114500146A (en) * 2021-12-30 2022-05-13 南京捷澳芯微科技有限公司 Test verification environment building system and verification method based on model design
CN116796673A (en) * 2023-08-22 2023-09-22 北京芯驰半导体科技有限公司 Test method, test device, electronic equipment and storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
刘雨欣: "高精度低功耗的RTC子系统...其UVM和Python验证", 《中国优秀硕士学位论文全文数据库 信息科技辑》, pages 135 - 576 *

Also Published As

Publication number Publication date
CN117131821B (en) 2024-01-16

Similar Documents

Publication Publication Date Title
CN108984389B (en) Application program testing method and terminal equipment
US10289303B2 (en) Flash controller and control method for flash controller
CN113076227A (en) MCU verification method, system and terminal equipment
CN109783340B (en) SoC test code programming method, IP test method and device
CN112612520B (en) Method, system, device and medium for resetting register based on PLD
US8874966B1 (en) Storage device error simulator tool
CN112286750A (en) GPIO (general purpose input/output) verification method and device, electronic equipment and medium
CN110569162B (en) Automatic testing method and device for FPGA in communication field
CN116681013B (en) Simulation verification method, platform, device, equipment and medium of network chip
CN113821898A (en) Random verification method, device, equipment and storage medium of chip subsystem
CN117131821B (en) Chip verification method, device, electronic equipment and storage medium
CN115685785B (en) Universal bus model and simulation test method
CN113760751B (en) Method for generating test case, electronic device and storage medium
CN113177388A (en) Device, system and method for testing and verifying IP (Internet protocol) core
US20170154142A1 (en) Method and apparatus for simulating slow storage disk
CN112860587A (en) UI automatic test method and device
CN111897582A (en) All-in-one machine Ethernet refreshing method and device, storage medium and all-in-one machine equipment
US10922249B2 (en) Input/output control code filter
KR20130032151A (en) Flash memory device capable of verifying reliability using bypass path, and system and method of verifying reliability using that device
CN117236277B (en) Method and device for checking register and electronic equipment
CN114513436B (en) SDIO device transmission rate detection method, system and storage medium
CN117112447B (en) Data transmission method and device, electronic equipment and readable storage medium
CN115495388B (en) Chip verification method, device, equipment and medium for AI reasoning chip
JP4893028B2 (en) Chipset emulation apparatus and method
CN107093408A (en) The control method and device of backlight lightening when smart machine is started shooting

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