CN116578449A - Test equipment supporting hot standby and recovery in chip verification and related method - Google Patents

Abstract

The embodiment of the invention provides test equipment supporting hot standby and recovery in chip verification and a related method, wherein the test equipment comprises a hot standby module, a recovery module and a functional module; the hot standby module is configured to acquire a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determine a plurality of register operation codes based on the register configuration sequence, and store the register operation codes into an operation code backup file; the recovery module is configured to receive a recovery instruction issued by the chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points; and sequentially acquiring a first number of register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired register operation codes. The recovery time of the verification environment can be reduced, and the verification efficiency of the chip prototype can be improved.

Description

Test equipment supporting hot standby and recovery in chip verification and related method

Technical Field

The invention relates to the technical field of semiconductors, in particular to test equipment supporting hot standby and recovery in chip verification and a related method.

Background

In the process of chip design, prototype verification of a chip is a very important link, and the prototype verification can find problems in the design before chip manufacture and plays a vital role in the success of the chip. Different verification platforms may be employed for prototype verification at different modules and overall system level, with EDA (Electronic Design Automation ), simulation (EMU, hardware simulation) being the primary verification platform.

Because of the small scale of simulation that EDA can simulate and the slow frequency of simulation, EDA is mainly used for module-level or small system-level verification, and the complete-level verification is mainly performed by adopting an integration platform. The scale of the integration supporting chip is large, the positioning means are mature, the reliability and the stability are high, and the integration supporting chip is a necessary device for verifying a large chip. In the verification of a 20-million-gate large network chip, various functions are generally configured in an assembly through software, and the verification of the system function of the chip is performed.

On the verification platform, the simulation rate of the chip can only achieve 1/1000 of the actual rate, and hundreds of thousands of registers need to be configured when the chip is initialized, hundreds of specifications need to be verified, so that the verification time of each specification is up to several hours, and the debug time is added, so that the verification time is up to more than one year.

One of the main bottlenecks of the efficiency of system verification of a large chip is that when a bug exists in a DUT (Device Under Test, test equipment), analysis positioning and regression are required to be repeatedly executed for the use case with the bug, that is, the process of configuration issuing and verification is required to be repeatedly executed, which is more time-consuming and results in lower efficiency of chip prototype verification.

Disclosure of Invention

The embodiment of the invention aims to provide test equipment supporting hot standby and recovery in chip verification and a related method, so as to reduce the recovery time of a verification environment and improve the verification efficiency of a chip prototype. The specific technical scheme is as follows:

in a first aspect, an embodiment of the present invention provides a test device for supporting hot standby and recovery in chip verification, where the test device includes a hot standby module, a recovery module and a functional module;

the hot standby module is configured to acquire a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determine a plurality of register operation codes based on the register configuration sequence, and store the register operation codes into an operation code backup file; the register configuration sequence is used for configuring the functional module; the register opcode includes: address bits for characterizing register addresses, data bits for characterizing register operation values, and operation type bits for characterizing read and write operation types;

The recovery module is configured to receive a recovery instruction issued by the chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points; and sequentially acquiring the first number of register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired register operation codes.

Optionally, the hot standby module includes an operation code generator, a first buffer of a first-in first-out FIFO structure, and an operation code memory;

the opcode generator is configured to sequentially determine a plurality of register opcodes based on the register configuration sequence and write the register opcodes to a write port of the first buffer;

the first buffer is configured to buffer the register opcode;

the operation code memory is configured to read the register operation code from the read port of the first buffer and store the read register operation code to the operation code backup file.

Optionally, the hot standby module further includes an operation code counter;

The opcode counter is configured to record a second number of register opcodes written to the first buffer, the second number in the opcode counter being readable by the chip configuration software over the configuration bus; the second quantity read by the chip configuration software after one or more groups of register configuration sequences are issued is used for representing backup points; the restore point is predetermined from the backup point.

Optionally, the recovery module includes an operation code recovery register, an operation code reader, a second buffer of the FIFO structure, and an operation code executor;

the operation code recovery register is configured to obtain the first quantity contained in a recovery instruction issued by the chip configuration software;

the operation code reader is configured to read the first number from the operation code recovery register, sequentially read the first number of register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and sequentially write the read register operation codes into a write port of the second buffer;

The second buffer is configured to buffer the register opcode;

the operation code executor is configured to sequentially read the register operation codes from the read port of the second buffer, and reconfigure the functional module based on the read register operation codes.

Optionally, the opcode reader is further configured to zero out the first number in the opcode recovery register after the reading of the first number of register opcodes is completed.

Optionally, the operation code generator is configured to parse a read-write operation timing on the configuration bus and translate the parsed register read-write operation into the register operation code.

Optionally, the test device further includes an initialization module;

the initialization module is configured to respond to the initialization instruction issued by the chip configuration software to clear the register of the functional module before receiving the recovery instruction issued by the chip configuration software.

In a second aspect, an embodiment of the present invention provides a method for testing a DUT, where the method is used for supporting hot standby and recovery in chip verification, and the method includes:

Acquiring a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determining a plurality of register operation codes based on the register configuration sequence, and storing the register operation codes; wherein the register configuration sequence is used to configure one or more functional modules within the DUT; the register opcode includes: address bits for characterizing register addresses, data bits for characterizing register operation values, and operation type bits for characterizing read and write operation types;

receiving a recovery instruction issued by the chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points;

and sequentially acquiring the first number of register operation codes from the stored register operation codes according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired register operation codes.

Optionally, before the receiving the recovery instruction issued by the chip configuration software, the method further includes:

recording a second number of stored register opcodes;

responding to a backup point acquisition request issued by the chip configuration software, and sending the second number used for representing the backup points to the chip configuration software; and the backup point acquisition request is sent by the chip configuration software after one or more groups of register configuration sequences are issued, and the recovery point is preset from the backup point.

Optionally, before the receiving the recovery instruction issued by the chip configuration software, the method further includes:

and resetting a register of the functional module in response to an initialization instruction issued by the chip configuration software.

The embodiment of the invention has the beneficial effects that:

by applying the test equipment and the related method provided by the embodiment of the invention, when the chip configuration software issues the register configuration sequence, the hot standby module can sequentially determine a plurality of register operation codes based on the register configuration sequence and store the register operation codes into the operation code backup file, so that the register operation codes corresponding to the register configuration sequence are backed up in the chip verification platform. In the chip verification process, if a bug occurs in part of use cases, when the functional module needs to be configured again, the register configuration sequence does not need to be repeatedly issued through the chip configuration software, but the first number of register operation codes can be acquired from the operation code backup file by the recovery module based on the first number of recovery instructions issued by the chip configuration software, the functional module is reconfigured based on the acquired register operation codes, the register configuration sequence is loaded from the inside of the chip verification platform through the cooperation of the chip configuration software and the DUT, the verification environment is quickly recovered, and the problem that the efficiency of issuing the register configuration sequence through a configuration bus and a rate matching bridge by the chip configuration software is low is avoided.

The test equipment provided by the embodiment of the invention is used for problem reproduction or regression test, the recovery time of the verification environment can be reduced by more than 1/2, and the efficiency of prototype verification is improved, so that the coverage of chip verification can be improved, and the quality of chips is ensured.

Of course, it is not necessary for any one product or method of practicing the invention to achieve all of the advantages set forth above at the same time.

Drawings

In order to more clearly illustrate the embodiments of the invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the invention, and other embodiments may be obtained according to these drawings to those skilled in the art.

Fig. 1 is an exemplary diagram of a chip authentication system in the related art;

FIG. 2 is a schematic diagram of a chip verification system provided by an embodiment of the present invention;

FIG. 3 is another schematic diagram of a chip verification system according to an embodiment of the present invention;

FIG. 4 is a schematic diagram of a chip verification system according to an embodiment of the present invention;

FIG. 5 is a schematic diagram of the write timing of the APB bus;

FIG. 6 is a schematic diagram of the read timing of the APB bus;

FIG. 7 is a schematic diagram of an opcode generator according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a state machine provided by an embodiment of the present application;

fig. 9 is a flowchart of a test method supporting hot standby and recovery in chip verification according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. Based on the embodiments of the present application, all other embodiments obtained by the person skilled in the art based on the present application are included in the scope of protection of the present application.

In the process of chip design, prototype verification of a chip is a very important link, and the prototype verification can find problems in the design before chip manufacture and plays a vital role in the success of the chip. Different verification platforms may be employed for prototype verification at different modules and overall system levels, with EDA, emulation being the primary verification platform.

Because of the small scale of simulation that EDA can simulate and the slow frequency of simulation, EDA is mainly used for module-level or small system-level verification, and the complete-level verification is mainly performed by adopting an integration platform. The scale of the integration supporting chip is large, the positioning means are mature, the reliability and the stability are high, and the integration supporting chip is a necessary device for verifying a large chip. In the verification of a 20-million-gate large network chip, various functions are generally configured in an assembly through software, and the verification of the system function of the chip is performed.

On the verification platform, the simulation rate of the chip can only achieve 1/1000 of the actual rate, hundreds of thousands of registers need to be configured when the chip is initialized, hundreds of specifications need to be verified, so that the verification time of each specification is up to several hours, and the debug time is added, so that the verification time is up to more than one year.

In order to facilitate understanding of the technical solution provided by the embodiments of the present invention, an exemplary description of a chip verification process in a simulation environment is first provided, and fig. 1 is an exemplary diagram of a chip verification system in the related art, where the chip verification system shown in fig. 1 includes chip configuration software, an EMU and a network tester.

Wherein the EMU is a chip verification platform, the DUT is operated on the EMU, the DUT is a test device, and the DUT is also understood as a device under test, and the DUT is an analog chip and not an actual chip.

Specifically, after the chip design is completed, the chip to be verified can be mapped to the EMU platform according to the chip design to obtain the simulated chip to be tested, i.e. DUT. Thus, the DUT referred to in the embodiments of the present invention may be understood as an analog chip to be verified that is run in an emulation environment, and the chip is verified, that is, each functional module in the DUT is verified.

Among these, a plurality of functional blocks, namely, functional block 1, functional block 2, and functional block … shown in fig. 1, are specifically included in the DUT, and each functional block can be understood as a set of registers and combinational logic circuits.

In the chip verification link, the chip configuration software is used for configuring various functions of the chip and initially verifying the environment. Specifically, before verifying the chip, a corresponding register configuration flow needs to be written according to the verified function. In the process of configuring the chip, a register configuration module in the chip configuration software issues register configuration or register configuration sequences to each functional module according to a flow. When the function verification is carried out on the chip, the configuration issuing process generally occupies more than 1/2 of the total verification duration.

The network tester is used for sending an excitation signal to the DUT and receiving a feedback signal in the DUT, so that the function verification of the chip is realized, and a SpeedBridge (speed matching bridge) is arranged between the network tester and the DUT, so that the speed matching between the network tester and the DUT is realized.

However, when the system shown in fig. 1 is used for chip verification, the efficiency of issuing the register configuration is low. The main reason is that the chip simulation rate on the test equipment is lower than the actual rate, the register configuration sequence after the speed reduction processing needs to be issued to the test equipment when the register configuration is issued, so that a channel for issuing the register configuration also needs to be connected to the DUT after logic conversion by adopting a hardware rate matching bridge, and the conversion process has lower efficiency.

Therefore, when positioning analysis and regression are performed for use cases with bug, a large amount of EMU opportunities are consumed in the process of issuing register configuration for many times, so that the verification time of the chip is longer and the efficiency is lower.

In order to solve the above-mentioned problems, an embodiment of the present invention provides a test device supporting hot standby and recovery in chip verification, and fig. 2 is a schematic diagram of a chip verification system provided by the embodiment of the present invention, in which a specific structure of the test device provided by the embodiment of the present invention is shown, and referring to fig. 2, the test device provided by the embodiment of the present invention specifically includes a hot standby module, a recovery module and a functional module.

As shown in fig. 2, the test device is connected with the chip configuration software through a configuration bus, and receives the register configuration information issued by the chip configuration software. The test equipment is also connected with the network tester, and rate matching is carried out between the test equipment and the network tester through SpeedBridge. For a specific description of the chip configuration software and the network tester, reference may be made to the foregoing description.

The hot standby module is configured to acquire a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determine a plurality of register operation codes based on the register configuration sequence, and store the register operation codes into an operation code backup file; the register configuration sequence is used for configuring the functional module; the register opcode includes: address bits for characterizing register addresses, data bits for characterizing register operation values, and operation type bits for characterizing read and write operation types.

As described above, before chip verification, corresponding register configuration flows can be written according to the functions to be verified, and the chip configuration software issues register configuration information to the functional modules in the DUT according to the flows, so that the DUT is configured as a verification environment, and development of subsequent verification is facilitated.

In the embodiment of the invention, the hot standby module can acquire a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determine a plurality of register operation codes based on the register configuration sequence, store the register operation codes into an operation code backup file and backup the register operation codes corresponding to the register configuration sequence.

The operation code backup file is specifically configured inside the chip verification platform.

Specifically, the configuration of the functional module in the DUT may be understood as performing read-write operations on registers in the functional module. Therefore, the register operation code obtained based on the register configuration sequence in the embodiment of the present invention may specifically include address bits for characterizing a register address, data bits for characterizing a register operation value, and operation type bits for characterizing a read-write operation type.

Wherein each register stripe opcode is used to characterize a read or write operation to a register, address bits are used to characterize the address of the register, data bits are used to characterize a particular read or write value to the register, operation type bits are used to identify whether the operation to the register is a particular read or write operation, e.g., an operation type bit to read a register may be written to 0 and an operation type bit to write a register may be written to 1.

The specific format of the register operation code can be set according to actual requirements, and the embodiment of the invention is not limited to this. As an example, the format of the register opcode provided in the embodiment of the present invention may be as shown in table 1:

TABLE 1

Bus operation	Operation type (1 bit)	Address (32 bit)	Value (32 bit)
				Reading registers	0	0x0-0xFFFFFFFF	0x0-0xFFFFFFFF
Write register	1	0x0-0xFFFFFFFF	0x0-0xFFFFFFFF

According to the register opcode format shown in Table 1, each register opcode has a length of 65 bits, as an example, 65 bits are operation type bits, an operation type bit of 0 representing a read register operation and a 1 representing a write register operation; 64 th to 33 th bits are address bits; 32 th to 1 st bits are data bits.

The specific manner of determining the plurality of register opcodes based on the register configuration sequence may be selected according to actual requirements, which is not limited in the embodiment of the present invention.

It should be noted that the register op codes should be determined and stored in order based on the order of issue of the register configuration sequence. As an example, to facilitate distinguishing between register opcodes and subsequent retrieval of register opcodes from the opcode backup file, one register opcode may be stored in each row of the opcode backup file.

As an example, the above-mentioned process of backing up the register operation code by the hot standby module may be specifically performed in the process of configuring the functional module in the DUT for the first time after writing the corresponding register configuration process according to the tested function.

The recovery module is configured to receive a recovery instruction issued by the chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points; and sequentially acquiring a first number of register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired operation codes.

In the embodiment of the invention, a certain number of register operation codes are stored in the operation code backup file, and after receiving the recovery instruction issued by the chip configuration software, the recovery module can acquire the first number of register operation codes from the operation code backup file according to the first number in the recovery instruction, and reconfigure the functional module based on the part of the register operation codes backed up in advance, so that the issuing of the register configuration sequence is not required to be performed again by the chip configuration software.

Where the recovery point is the location to which the configuration of the functional module within the DUT needs to be recovered, it can be characterized by the number of register opcodes required to recover the configuration of the functional module to that location.

As an example, if the hot standby module determines m register operation codes based on the register configuration sequence, the m register operation codes are stored in the operation code backup file, and if the first number of the restoration instructions issued by the chip configuration software is n, the restoration module needs to sequentially acquire the first n register operation codes from the m register operation codes according to the storage sequence of the register operation codes, and reconfigure the functional module based on the acquired operation codes.

In the embodiment of the present invention, the manner in which the chip configuration software determines the first number is not specifically limited. As an example, the chip configuration software may parse the issued register configuration sequence to determine the number of register opcodes corresponding to the register configuration sequence, so that when a restoration instruction needs to be issued, the chip configuration software may determine, based on this, the first number of register opcodes used to characterize the restoration point.

As an example, when the functional module is reconfigured based on the register operation code, the recovery module may parse the register operation code and convert it into a bus read-write timing, thereby reconfiguring the functional module. Specifically, based on the format of the register operation code configured in advance, address bits, data bits and operation type bits can be determined, so that a read operation/write operation can be performed on the register of the corresponding address based on the information.

As an example, the above-mentioned process of reconfiguring the functional module by the restoration module based on the stored register operation code may be specifically performed when configuration issuing needs to be repeatedly performed for problematic use cases.

By applying the test equipment provided by the embodiment of the invention, when the chip configuration software issues the register configuration sequence, the hot standby module can sequentially determine a plurality of register operation codes based on the register configuration sequence and store the register operation codes into the operation code backup file, so that the register operation codes corresponding to the register configuration sequence are backed up in the chip verification platform. In the chip verification process, if a bug occurs in part of use cases, when the functional module needs to be configured again, the register configuration sequence does not need to be repeatedly issued through the chip configuration software, but the first number of register operation codes can be acquired from the operation code backup file by the recovery module based on the first number of recovery instructions issued by the chip configuration software, the functional module is reconfigured based on the acquired register operation codes, the register configuration sequence is loaded from the inside of the chip verification platform through the cooperation of the chip configuration software and the DUT, the verification environment is quickly recovered, and the problem that the efficiency of issuing the register configuration sequence through a configuration bus and a rate matching bridge by the chip configuration software is low is avoided.

The test equipment provided by the embodiment of the invention is used for problem reproduction or regression test, the recovery time of the verification environment can be reduced by more than 1/2, and the efficiency of prototype verification is improved, so that the coverage of chip verification can be improved, and the quality of chips is ensured.

Fig. 3 is another schematic diagram of a chip verification system according to an embodiment of the present invention, in which a specific structure of a hot standby module is shown, and a test apparatus according to an embodiment of the present invention is further described below with reference to fig. 3.

In one embodiment of the invention, the hot standby module includes an opcode generator, a first buffer of a FIFO (First In First Out, first-in first-out) structure, and an opcode memory;

the operation code generator is configured to sequentially determine a plurality of register operation codes based on the register configuration sequence and write the register operation codes to a write port of the first buffer;

the first buffer is configured to buffer register opcodes;

the operation code memory is configured to read a register operation code from a read port of the first buffer and store the read register operation code to the operation code backup file.

Specifically, the buffer of the FIFO structure has a write port and a read port, and data can be sequentially written into the buffer from the write port and sequentially read out from the read port in the write order.

The depth of the first buffer can be configured according to actual requirements. The depth of the buffer of the FIFO structure, i.e. how many N bits of data the buffer can buffer, can be understood in the embodiment of the invention as how many register opcodes the buffer can buffer.

In addition, the write clock of the write port and the read clock of the read port of the buffer of the FIFO structure are mutually independent, so that the buffer of the FIFO structure can be arranged between two clock domains for data transmission among different clock domains to buffer data, thereby achieving the aim of data matching.

In the embodiment of the invention, the data transmission rate on the configuration bus is higher, and the data transmission rate in the DUT is lower, and the higher data transmission rate on the configuration bus can cause the register operation code determined by the operation code generator not to be read by the operation code memory in time, so that the register operation code is lost. Therefore, by arranging the first buffer of the FIFO structure between the operation code generator and the operation code memory, the transmission of the register operation code can be buffered, avoiding the loss of the register operation code.

In one embodiment of the invention, the hot standby module further comprises an operation code counter;

The opcode counter is configured to record a second number of register opcodes written to the first buffer, the second number in the opcode counter being readable by the chip configuration software via the configuration bus; the second quantity read by the chip configuration software after completing the issuing of one or more groups of register configuration sequences is used for representing the backup point; the restore point is predetermined from the backup point.

Specifically, the initial value in the opcode counter may be set to 0, and after the opcode buffer receives an opcode, the value in the opcode counter is incremented by 1, thereby obtaining a second number of register opcodes written to the first buffer.

In the chip verification link, one or more sets of register configuration sequences may be issued, and the environment after one or more sets of register configuration issues is completed, which may be used for performing functional verification on the chip. In the embodiment of the invention, after the issuing of a group of register configuration sequences is completed, the chip configuration software can obtain a backup point by reading the second number in the operation code counter through the configuration bus, and if a plurality of groups of register configuration sequences are issued, the chip configuration software can obtain a plurality of backup points.

As an example, if the chip configuration software translates the first set of register configuration sequences into m opcodes after the first set of register configuration sequences has been issued, the chip configuration software may read the value m in the opcode counter via the configuration bus as the first backup point. If the second set of register configuration sequences issued by the chip configuration software is translated into n opcodes, then the register configuration software may read the value m+n in the opcode counter via the configuration bus, as a second backup point, and so on.

When the process of configuration issuing needs to be re-executed aiming at the problematic use case, a specific backup point can be selected from backup points obtained by the chip configuration software according to actual requirements to serve as a recovery point, and a recovery instruction is issued based on the specific backup point to reconfigure the functional module.

As one example, a second number of backup points may be displayed in a log of the chip configuration software to characterize the backup point to facilitate subsequent confirmation of which backup point to restore the configuration of the functional module of the DUT.

In the embodiment of the invention, because the recovery module needs to acquire the specified number of register operation codes from the operation code backup file when recovering the verification environment, the functional module is reconfigured based on the acquired register operation codes, and the DUT itself has the requirement of counting the stored register operation codes. Therefore, the operation code counter can be read by the chip configuration software to obtain the second quantity used for representing the backup points, so that the quantity of the register operation codes corresponding to the register configuration sequence does not need to be additionally determined, the calculation resource can be saved, and the efficiency of recovering the verification environment can be improved.

Fig. 4 is a schematic diagram of a chip verification system according to an embodiment of the present invention, in which a specific structure of a recovery module is shown, and a test apparatus according to an embodiment of the present invention is further described below with reference to fig. 4.

In one embodiment of the invention, the recovery module includes an opcode recovery register, an opcode reader, a second buffer of FIFO structure, and an opcode executor;

the operation code recovery register is configured to acquire a first quantity contained in a recovery instruction issued by the chip configuration software;

the operation code reader is configured to read a first number from the operation code recovery register, sequentially read the first number of the register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and sequentially write the read register operation codes into a write port of the second buffer;

the second buffer is configured to buffer register opcodes;

the opcode executor is configured to sequentially read the register opcodes from the read ports of the second buffer and reconfigure the functional module based on the read register opcodes.

The second buffer and the first buffer are both in FIFO structure, and the depth of the second buffer can be configured according to actual requirements. For a specific description of the second buffer, reference may be made to the description of the first buffer hereinbefore.

In the embodiment of the invention, the transmission of the register operation code can be buffered by arranging the second buffer with the FIFO structure between the operation code reader and the operation code executor, so that the register operation code read by the operation code reader can be effectively used for reconfiguring the functional module.

In one embodiment of the invention, the opcode reader is further configured to zero out the first number in the opcode restoration register after the reading of the first number of register opcodes is completed.

Specifically, the chip configuration software may read the first number into the opcode restoration register via the configuration bus.

After the operation code reader reads the first number of register operation codes from the operation code backup file, that is, the first number of register operation codes corresponding to the recovery points in the recovery instruction issued by the chip configuration software, the operation code reader may zero the first number of operation code recovery registers.

Therefore, after the chip configuration software issues the recovery instruction, if the chip configuration software detects that the value in the operation code recovery register is not zero, the chip configuration software waits for the recovery to be completed.

If the chip configuration software detects that the value in the operation code recovery register is zero, the characterization recovery module has completed the reconfiguration of the functional module, and the subsequent chip verification can be continued.

In one embodiment of the invention, the opcode generator is configured to parse the timing of read and write operations on the configuration bus and translate the parsed register read and write operations into register opcodes.

Specifically, the register configuration sequence on the configuration bus may be specifically understood as a timing signal, so that the opcode generator may parse the timing of the read/write operations on the configuration bus and translate the parsed read/write operations into the register opcode.

As one example, the opcode generator may obtain the register opcode by parsing a signal on an address bus to obtain address bits, parsing a signal on a data bus to obtain data bits, and parsing a bus direction signal to obtain operation type bits, combining the address bits, the data bits, and the operation type bits.

Taking the configuration bus as an APB (Advanced Peripheral Bus, advanced peripheral interface) bus as an example, the operation code generator can obtain address bits by parsing signals on a PADDR (address bus); analyzing a signal on PWRITE (write enable bus) to obtain an operation type bit, wherein the PWRITE represents write register operation when the PWRITE is at a high level and represents read register operation when the PWRITE is at a low level; analyzing the signal on PWDA (write data bus) to obtain the data bit of the register writing operation, analyzing the signal on PRDATA (read data bus) to obtain the data bit of the register reading operation, and then combining the address bit, the data bit and the operation type bit to obtain the register operation code.

The following describes an exemplary procedure of resolving the timing of the read/write operation on the configuration bus according to the embodiment of the present invention with reference to fig. 5 and 6.

FIG. 5 is a schematic diagram of the write timing of the APB bus, wherein PCLK is the clock signal, and the signals on the bus are all valid on the rising edge of PCLK. It can be seen that PWRITE in fig. 5 is at a high level during signal transmission, which characterizes the write register operation, where PADDR carries address Data Addr 1, and pwdata carries write Data 1, so that the operation code generator can determine an operation type bit based on the level of PWRITE, determine an address bit based on Addr 1, determine a Data bit based on Data 1, and combine the address bit, the Data bit, and the operation type bit to obtain the register operation code.

In addition, PSEL (bus select signal), penble (bus enable signal) and PREADY (ready signal) are also shown in fig. 5. Specifically, as shown in fig. 5, at time T2, during signal transmission, PSEL will be set to a high level, where PSEL is high to indicate that PADDR, PWRITE and PWDATA are both active at the current time, PENABLE will be set to a high level at the next clock rising edge where PSEL is set to a high level, i.e., at time T3 shown in fig. 5, PREADY is set to a high level according to actual requirements, at time T3 shown in fig. 5, PREADY is set to a high level, indicating that data to be transmitted will be received at time T3, and PSEL and PENABLE both recover to a low level after data transmission is completed. Therefore, based on the write timing shown in fig. 5, the opcode generator specifically may parse the signal on the configuration bus at time T3 to obtain a register opcode, and output the register opcode at time T4.

Fig. 6 is a schematic diagram of the read timing of the APB bus, and it can be seen that PWRITE in fig. 6 is low during signal transmission, indicating read register operation, and the other signals shown in fig. 6 are the same as those in fig. 5, and reference is made to the description of fig. 5. Similarly, based on the read timing shown in fig. 6, the opcode generator may specifically parse the signal on the configuration bus at time T3 to obtain a register opcode, and output the register opcode at time T4.

Fig. 7 is a schematic structural diagram of an opcode generator according to an embodiment of the present invention, and a possible structure of the opcode generator according to an embodiment of the present invention is described below with reference to fig. 7.

The operation code generator specifically may include three register caches and logic control, register a, register B and register C.

Wherein the logic control is configured to determine ctrl_b and ctrl_c at the rising edge of clock CLK based on PREADY, penble and PSEL on the configuration bus;

the register A is used for analyzing signals on PWRITE, PADR and PWDATA/PRDATA, combining the analyzed signals, and storing the obtained code into a temporary register which is pre-configured in the register A; the size of the temporary register is specifically the size of a register operation code, and the size of the temporary register is 65 bits by way of example;

A register B for sampling the data of the register a to the register B when ctrl_b is at a high level;

and the register C is used for sampling the data of the register B to the register C when Ctrl_C is at a high level and inputting the acquired data to the first buffer.

The logic control may be specifically implemented by a state machine, and fig. 8 is a schematic diagram of the state machine provided by the embodiment of the present invention, referring to fig. 8, the state machine may include 3 states: IDLE, STATE a and STATE B. Specifically, in fig. 8, a high level is represented by 1 and a low level is represented by 0.

When no signal is on the configuration bus, the state machine is in an IDLE state, and at this time, ctrl_B, ctrl_C and valid are all low.

In the IDLE STATE, at the clock rising edge (bridge CLK), if PREADY is found, PENABLE and PSEL are both high, the STATE machine switches to STATE B.

After entering STATE B, ctrl_b goes high.

In STATE B, at the rising edge of the clock, if PREADY, PENABLE and PSEL are both low, the STATE machine switches to STATE C.

After entering STATE C, ctrl_b goes low and ctrl_c and valid go high.

In STATE B, the next clock rising edge, the opcode generator inputs the register opcode into the first buffer while the STATE machine switches to IDLE.

Taking the write timing shown in fig. 5 as an example, there is no signal on the configuration bus at time T1, and the state machine is in IDLE state, and ctrl_b, ctrl_c, and valid are all low. At time T3 shown in fig. 5, PREADY, PENABLE and PSEL are all high, the STATE machine is switched to STATE B, ctrl_b becomes high, and therefore, the code obtained by analyzing the signals on PADDR, PWRITE and PWDATA at time T3 can be collected into register B.

In STATE B, PREADY, PENABLE and PSEL are all low when time T4 is reached, the STATE machine is switched to STATE C, ctrl_b is low, ctrl_c and valid are high, and therefore the code obtained by register a at time T3 is collected by register B at time T4.

Specifically, in STATE B, the next clock rising edge, the operation code generator inputs the register operation code into the first buffer, that is, the code obtained by parsing the signals on PADDR, PWRITE, and PWDATA by the register a at time T3, that is, the register operation code, is input into the first buffer at time T4.

In combination with the read timing shown in fig. 5 and the write timing shown in fig. 6, it can be seen that the data within the code obtained based on parsing the signals on PADDR, PWRITE and PWDATA/PRDATA is not valid at any time, but the code obtained only at time T3 as illustrated is the register opcode required by an embodiment of the present invention. Therefore, the embodiment of the invention determines the state of the state machine according to PSEL, PENABLE and PREADY, and realizes the logic control of the operation code generator through the state machine, so that the operation code generator can screen out effective register operation codes, and the effective register operation codes are input into the first buffer, so that the hot standby module can backup the effective register operation codes.

In one embodiment of the invention, the test apparatus further comprises an initialization module;

the initialization module is configured to clear a register of the functional module in response to an initialization instruction issued by the chip configuration software before receiving the recovery instruction issued by the chip configuration software.

Specifically, when a bug occurs in a part of use cases in the chip verification link and the process of configuration issuing and verification needs to be re-executed, before the re-configuration issuing, the chip configuration software may issue an initialization instruction, specifically, a reset or restart instruction, to the DUT. After receiving the instruction, the DUT clears the register of the functional module, avoids the influence on the subsequent verification caused by the configuration issued by the register of the functional module before, and is beneficial to the smooth expansion of the subsequent verification. After completing zero clearing, a recovery instruction can be issued, and the functional module is reconfigured by the recovery module to recover the verification environment.

For easy understanding, a specific flow of the test apparatus provided by the embodiment of the present invention when applied to hot standby and recovery of register configuration is described below in connection with the structure of the hot standby module shown in fig. 2 and the structure of the recovery module shown in fig. 3.

When the register configuration sequence is issued to the functional module through the chip configuration software, the hot standby module is configured to determine and store the operation code according to the register configuration sequence, or to backup the register configuration, and the backup process specifically may include the following steps:

step A1: the chip configuration software issues a set of register configuration sequences to the functional module.

Step A2: when the operation code generator monitors that the read-write operation is carried out on the configuration bus, the operation code generator simultaneously analyzes the time sequence and translates the time sequence into the register operation code, and writes the register operation code into the first buffer.

Step A3: after each first buffer receives a register opcode, the value in the opcode counter is incremented by one.

Step A4: when the operation code generator monitors that the first buffer has the register operation codes, the operation code generator starts to read the register operation codes from the first buffer and records the register operation codes into the operation code backup file, and each register operation code is used as one row.

Step A5: after the chip configuration software completes the issuing of a group of register configuration sequences, the numerical value in the operation code counter is read and used as a backup point.

Step A6: the chip configuration software displays the numerical value used for representing the backup point in the log, so that the backup point can be conveniently restored to the subsequent confirmation.

Based on the steps A1-A6, the hot standby module can realize the backup of the register operation codes, the chip configuration software can obtain one or more backup points, the backup points are characterized by the number of the register operation codes, and then a specific backup point can be selected from the backup points as a recovery point according to actual requirements.

In the process of issuing a register configuration sequence and verifying the functions of the chip by the chip configuration software, if part of use cases have bug and the register configuration needs to be issued again to recover the verification environment, the verification environment can be recovered by a recovery module, and the recovery process specifically comprises the following steps:

step B1: the chip configuration software issues a recovery point to the opcode recovery register.

Step B2: the opcode reader obtains a value from the opcode recovery register that is taken as the maximum value for the read opcode, e.g., X.

Step B3: the operation code reader reads the register operation code from the operation code backup file and writes the read register operation code to the write port of the second buffer.

Step B4: the operation code executor reads the register operation code from the reading port of the operation code buffer, analyzes the read register operation code, converts the read register operation code into a bus reading and writing time sequence, and performs register configuration on the functional module.

Step B5: and B3, repeatedly executing the step until the analysis of the X register operation codes is completed, and completing the configuration of the functional module based on the analyzed total write-read-write time sequence.

Step B6: the opcode reader clears the opcode recovery register.

Step B7: the chip configuration software detects that the value in the operation code recovery register is 0, and the recovery flow is ended.

Through the steps, when the configuration issuing process is required to be re-executed for the problematic use case in the chip verification link, the recovery module determines the register operation codes in advance based on the register configuration sequence issued by the chip configuration software and caches the register operation codes in the operation code backup file, and at this time, the recovery module in the test equipment can directly read the register operation codes from the operation code backup file and reconfigure the functional module based on the read register operation codes, without re-issuing the register configuration sequence through the chip configuration software, thereby recovering the verification environment more quickly.

Based on the same inventive concept, the embodiment of the invention also provides a test method for supporting hot standby and recovery in chip verification, which is specifically applied to test equipment running on a chip verification platform, and fig. 9 is a flow chart of the test method for supporting hot standby and recovery in chip verification provided by the embodiment of the invention, referring to fig. 9, and the method specifically comprises the following steps:

Step S901: acquiring a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determining a plurality of register operation codes based on the register configuration sequence, and storing the register operation codes; wherein the register configuration sequence is used to configure one or more functional modules within the DUT; the register opcode includes: address bits for characterizing register addresses, data bits for characterizing register operation values, and operation type bits for characterizing read and write operation types;

step S902: receiving a recovery instruction issued by chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points;

step S903: sequentially acquiring a first number of register operation codes from the stored register operation codes according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired register operation codes.

By applying the test method for supporting hot standby and recovery in chip verification provided by the embodiment of the invention, when the chip configuration software issues the register configuration sequence, the test equipment can sequentially determine and store a plurality of register operation codes based on the register configuration sequence, so that the register operation codes corresponding to the register configuration sequence are backed up in the chip verification platform. In the chip verification process, if a bug occurs in part of use cases, when the functional module needs to be configured again, the register configuration sequence does not need to be repeatedly issued through the chip configuration software, but the first number of register operation codes can be acquired from the stored register operation codes based on the first number of recovery instructions issued by the chip configuration software, the functional module is reconfigured based on the acquired register operation codes, the register configuration sequence is loaded from the inside of the chip verification platform through the cooperation of the chip configuration software and the test equipment, the verification environment is quickly recovered, and the problem that the efficiency of issuing the register configuration sequence through a configuration bus and a rate matching bridge by the chip configuration software is low is avoided.

The test method supporting hot standby and recovery in chip verification provided by the embodiment of the invention is used for problem reproduction or regression test, the recovery time of the verification environment can be reduced by more than 1/2, the efficiency of prototype verification is improved, the coverage of chip verification can be improved, and the quality of chips is ensured.

In one embodiment of the present invention, before receiving the recovery instruction issued by the chip configuration software, the method further includes:

recording a second number of stored register opcodes;

responding to a backup point acquisition request issued by the chip configuration software, and transmitting a second number for representing the backup points to the chip configuration software; the backup point acquisition request is sent by the chip configuration software after the issuing of one or more groups of register configuration sequences is completed, and the recovery point is predetermined from the backup points.

In one embodiment of the present invention, before receiving the recovery instruction issued by the chip configuration software, the method further includes:

and resetting a register of the functional module in response to an initialization instruction issued by the chip configuration software.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present invention, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In this specification, each embodiment is described in a related manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for the embodiment of the test method supporting hot standby and recovery in chip verification, since it is substantially similar to the embodiment of the test apparatus supporting hot standby and recovery in chip verification, the description is relatively simple, and the relevant points are referred to in the part of the description of the embodiment of the test apparatus supporting hot standby and recovery in chip verification.

The foregoing description is only of the preferred embodiments of the present invention and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims (10)

1. The test equipment supporting hot standby and recovery in chip verification is characterized by comprising a hot standby module, a recovery module and a functional module;

the hot standby module is configured to acquire a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determine a plurality of register operation codes based on the register configuration sequence, and store the register operation codes into an operation code backup file; the register configuration sequence is used for configuring the functional module; the register opcode includes: address bits for characterizing register addresses, data bits for characterizing register operation values, and operation type bits for characterizing read and write operation types;

the recovery module is configured to receive a recovery instruction issued by the chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points; and sequentially acquiring the first number of register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired register operation codes.

2. The test apparatus of claim 1, wherein the hot standby module comprises an opcode generator, a first buffer of a first-in-first-out FIFO structure, and an opcode memory;

the opcode generator is configured to sequentially determine a plurality of register opcodes based on the register configuration sequence and write the register opcodes to a write port of the first buffer;

the first buffer is configured to buffer the register opcode;

the operation code memory is configured to read the register operation code from the read port of the first buffer and store the read register operation code to the operation code backup file.

3. The test apparatus of claim 2, wherein the hot standby module further comprises an opcode counter;

the opcode counter is configured to record a second number of register opcodes written to the first buffer, the second number in the opcode counter being readable by the chip configuration software over the configuration bus; the second quantity read by the chip configuration software after one or more groups of register configuration sequences are issued is used for representing backup points; the restore point is predetermined from the backup point.

4. The test device of claim 1, wherein the recovery module comprises an opcode recovery register, an opcode reader, a second buffer of FIFO structure, and an opcode executor;

the operation code recovery register is configured to obtain the first quantity contained in a recovery instruction issued by the chip configuration software;

the operation code reader is configured to read the first number from the operation code recovery register, sequentially read the first number of register operation codes from the operation code backup file according to the storage sequence of the register operation codes, and sequentially write the read register operation codes into a write port of the second buffer;

the second buffer is configured to buffer the register opcode;

the operation code executor is configured to sequentially read the register operation codes from the read port of the second buffer, and reconfigure the functional module based on the read register operation codes.

5. The test device of claim 4, wherein the opcode reader is further configured to clear the first number of opcode restoration registers after the reading of the first number of register opcodes is completed.

6. The test apparatus of claim 2, wherein the opcode generator is configured to parse read and write operation timing on the configuration bus and translate parsed register read and write operations into the register opcode.

7. The test device of claim 1, wherein the test device further comprises an initialization module;

the initialization module is configured to respond to the initialization instruction issued by the chip configuration software to clear the register of the functional module before receiving the recovery instruction issued by the chip configuration software.

8. A test method for supporting hot standby and recovery in chip verification, applied to a test device DUT, comprising:

acquiring a register configuration sequence issued by chip configuration software through a configuration bus, sequentially determining a plurality of register operation codes based on the register configuration sequence, and storing the register operation codes; wherein the register configuration sequence is used to configure one or more functional modules within the DUT; the register opcode includes: address bits for characterizing register addresses, data bits for characterizing register operation values, and operation type bits for characterizing read and write operation types;

Receiving a recovery instruction issued by the chip configuration software, wherein the recovery instruction comprises a first number of register operation codes used for representing recovery points;

and sequentially acquiring the first number of register operation codes from the stored register operation codes according to the storage sequence of the register operation codes, and reconfiguring the functional module based on the acquired register operation codes.

9. The method of claim 8, wherein prior to receiving the resume instruction issued by the chip configuration software, the method further comprises:

recording a second number of stored register opcodes;

responding to a backup point acquisition request issued by the chip configuration software, and sending the second number used for representing the backup points to the chip configuration software; and the backup point acquisition request is sent by the chip configuration software after one or more groups of register configuration sequences are issued, and the recovery point is preset from the backup point.

10. The method of claim 8, wherein prior to receiving the resume instruction issued by the chip configuration software, the method further comprises:

And resetting a register of the functional module in response to an initialization instruction issued by the chip configuration software.