Chip verification method, test equipment and chip verification system

Abstract

The present application relates to the field of chip verification technology, and discloses a chip verification method, test equipment and chip verification system. The method constructs a template file to generate a verification environment and test cases based on the template file, obtains a configuration file, updates the parameters in the verification environment and test cases through the parameters in the configuration file, obtains an updated verification environment and an updated test case, performs regression testing on the chip based on the updated verification environment and the updated test case, and obtains test results. The method can quickly generate a verification environment based on the template file, and quickly replace parameters to improve the efficiency of chip testing.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of chip verification technology, and in particular to a chip verification method, testing equipment, and a chip verification system. Background Art

[0002] In the field of chip verification technology, as chip integration continues to increase and functions become increasingly complex, memory, as an important component of the chip, has different parameters for the memory used in different projects or modules. Therefore, when verifying the chip, it is necessary to rely on manual construction of the verification environment and manual modification of various parameters. At the same time, it is also necessary to manually adjust file paths and write test cases. The above method often leads to errors due to human negligence, thereby reducing the efficiency of chip verification. Summary of the Invention

[0003] In order to solve the above technical problems, the embodiments of the present application provide a chip verification method, a test device and a chip verification system, which can quickly generate a verification environment based on a template file and quickly replace parameters to improve the efficiency of chip testing.

[0004] In order to solve the above technical problems, the embodiments of the present application provide the following technical solutions:

[0005] In a first aspect, an embodiment of the present application provides a chip verification method, the method comprising:

[0006] Build template files;

[0007] Generate verification environment and test cases based on template files;

[0008] Obtaining a configuration file, and based on the configuration file, updating parameters in the verification environment and parameters in the test case to obtain an updated verification environment and an updated test case;

[0009] Based on the updated verification environment and updated test cases, regression testing is performed on the chip to obtain test results;

[0010] Based on the configuration file, update the parameters of the verification environment and the parameters in the test case to obtain the updated verification environment and updated test case, including:

[0011] Parse the configuration file to obtain several first parameters and second parameters;

[0012] Based on the first parameters and the second parameters, updating the parameters of the verification environment and the parameters in the test case through an automated script to obtain an updated verification environment and an updated test case;

[0013] Based on the first parameters and the second parameters, the parameters of the verification environment and the parameters in the test case are updated by an automated script to obtain an updated verification environment and an updated test case, including:

[0014] Replacing the third parameters in the verification environment with the first parameters in the configuration file to obtain an updated verification environment, wherein the parameter names of the first parameters and the third parameters are the same;

[0015] Replace the fourth parameters in the verification environment with the second parameters in the configuration file to obtain an updated test case, wherein the parameter names of the second parameters and the fourth parameters are the same;

[0016] Replace the third parameters in the verification environment with the first parameters in the configuration file to obtain the updated verification environment, including:

[0017] Obtaining a specific value of the first parameter from the configuration file, assigning the specific value of the first parameter to a third parameter in the verification environment, and obtaining an updated verification environment;

[0018] Replace the second parameters in the configuration file with the fourth parameters in the verification environment to obtain updated test cases, including:

[0019] The specific value of the second parameter is obtained from the configuration file, and the specific value of the second parameter is assigned to the fourth parameter in the verification environment to obtain an updated test case.

[0020] In some embodiments, the template file includes at least one of an environment component, a test case, a test interface, an environment parameter, and a file list;

[0021] The configuration file includes at least one of a module name, an address bit width, a read / write data bit width, an ECC check data bit width, a check function judgment flag, an error injection function judgment flag, a memory type, and a number of memory banks;

[0022] The test cases include at least one of a basic case, a read and write data case, an error injection case, and a low power consumption function case.

[0023] In some embodiments, performing regression testing on the chip based on the updated verification environment and updated test cases to obtain test results includes:

[0024] Generate several transactions based on the updated test cases, where each updated test case corresponds to one transaction;

[0025] Input several transactions into the chip to obtain data from the chip;

[0026] Input the chip data into the updated verification environment to parse the chip data and obtain the parsing results;

[0027] Compare the chip data and analysis results to obtain the test results.

[0028] In some embodiments, the updated verification environment includes a reference model, the reference model is used to simulate the logic function of the chip to output the parsing result, and the data of the chip includes read data;

[0029] Analyze the chip data and obtain the analysis results, including:

[0030] Parse the read data to obtain the read address;

[0031] Based on the read address, data corresponding to the read address is acquired to obtain a parsing result, wherein the parsing result includes the data corresponding to the read address.

[0032] In some embodiments, the test results include test pass and test fail, and the chip data and analysis results are compared to obtain the test results, including:

[0033] If the parsing result is the same as the chip data, the test result is determined to be passed;

[0034] If the analysis result is different from the chip data, the test result is determined to be a test failure.

[0035] In a second aspect, an embodiment of the present application provides a testing device, comprising:

[0036] at least one processor; and,

[0037] a memory communicatively connected to at least one processor; wherein,

[0038] The memory stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to the first aspect.

[0039] In a third aspect, an embodiment of the present application provides a chip verification system, the system comprising:

[0040] Memory to be tested;

[0041] The test device of the second aspect is in communication with the memory to be tested, and is used to simulate the logical function of the memory to be tested, obtain simulation results, and compare the simulation results with the data of the memory to be tested to obtain test results.

[0042] In some embodiments, the test device includes an agent module and a scoreboard, the agent module includes a sequencer, a driver, and a monitor, and the scoreboard includes a fixed-width array simulation module and a data comparison module;

[0043] Sequencer, connected to the driver, is used to generate transactions corresponding to test cases;

[0044] A driver, connected to the sequencer and the memory under test, and configured to send transactions corresponding to the test case to the memory under test;

[0045] A monitor connected to the memory under test, the fixed-width array simulation module, and the data comparison module, and configured to obtain input data of the memory under test or output data of the memory under test;

[0046] A fixed-width array simulation module is connected to the monitor and the data comparison module, and is used to receive input data of the memory under test, or output read data based on output data of the memory under test;

[0047] The data comparison module is connected to the fixed-width array simulation module and the monitor, and is used to compare the output data of the memory to be tested with the read data in the fixed-width array simulation module to see if they are the same, so as to obtain the test result.

[0048] The beneficial effects of the embodiments of the present application are: different from the existing technology, the embodiments of the present application provide a chip verification method, which constructs a template file to generate a verification environment and test cases based on the template file, obtains a configuration file, updates the parameters in the verification environment and test cases through the parameters in the configuration file, obtains an updated verification environment and an updated test case, and performs regression testing on the chip based on the updated verification environment and the updated test case to obtain test results. It can quickly generate a verification environment based on the template file and quickly replace parameters to improve the efficiency of chip testing. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] One or more embodiments are exemplarily illustrated by corresponding drawings, which do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0050] Figure 1 This is a flow chart of a chip verification method provided in an embodiment of the present application;

[0051] Figure 2 yes Figure 1 Detailed flow chart of step S103;

[0052] Figure 3 yes Figure 2 A detailed flowchart of step S1302 in FIG.

[0053] Figure 4 yes Figure 1 A detailed flowchart of step S104 in FIG.

[0054] Figure 5 yes Figure 4 A detailed flowchart of step S1403 in FIG.

[0055] Figure 6 yes Figure 4 A detailed flowchart of step S1404 in FIG.

[0056] Figure 7 This is a schematic diagram of the overall process of a chip verification method provided in an embodiment of the present application;

[0057] Figure 8 This is a schematic diagram of the structure of a chip verification system provided in an embodiment of the present application;

[0058] Figure 9 This is a schematic structural diagram of a chip verification device provided in an embodiment of the present application;

[0059] Figure 10 It is a structural diagram of a testing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] To make the purpose, technical solutions, and advantages of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0061] It should be noted that, if there is no conflict, the various features in the embodiments of this application can be combined with each other and are all within the scope of protection of this application. In addition, the words "first" and "second" used in this application do not limit the data, but only divide the same or similar items with basically the same functions and effects.

[0062] Before introducing the embodiments of the present application, a chip verification method known to the inventors of the present application is briefly introduced to facilitate subsequent understanding of the embodiments of the present application.

[0063] Currently, UVM verification environments are developed separately for different chips, or the verification environment is inherited from the previous project and the code is manually modified.

[0064] Alternatively, a one-time programmable (OTP) verification environment is built based on the universal verification methodology (UVM). The top level of the test is the memory under test, and the OTP programming, register information, and OTP mapping logic in the memory under test are obtained. High-speed signals in the memory under test that are not related to OTP programming and reading are turned off. Test cases are constructed according to different scenarios to apply stimulation to the memory under test. The OTP programming and reading logic and mapping logic are quickly verified through data comparison.

[0065] The disadvantages of the above solution include:

[0066] (1) The verification environment needs to be manually built or modified, which is time-consuming and has a long debugging cycle, and the environment stability is poor.

[0067] (2) There is no unified template, which leads to low construction efficiency, high error rate, and difficulty in rapid reuse.

[0068] (3) Separate environments need to be built for different memories, parameter adjustment is cumbersome, and errors are easily introduced.

[0069] (4) Manual operation results in many repetitive steps and poor accuracy, which reduces the testing efficiency of the chip.

[0070] In order to solve the above problems, the present application provides a chip verification method, which constructs a template file to generate a verification environment and test cases based on the template file, obtains a configuration file, updates the parameters in the verification environment and test cases through the parameters in the configuration file, obtains an updated verification environment and an updated test case, and performs regression testing on the chip based on the updated verification environment and the updated test case to obtain test results. It can quickly generate a verification environment based on the template file and quickly replace parameters to improve the efficiency of chip testing.

[0071] The technical solution of this application is described in detail below with reference to the accompanying drawings:

[0072] See also Figure 1 , Figure 1 This is a flow chart of a chip verification method provided in an embodiment of the present application.

[0073] The chip verification method is applied to a test device. Specifically, the execution subject of the chip verification method is one or at least two processors of the test device.

[0074] The test equipment is connected to the chip for communication, and the test equipment includes but is not limited to a computer terminal, a computer, etc.

[0075] like Figure 1As shown, the chip verification method includes:

[0076] Step S101: construct a template file.

[0077] In an embodiment of the present application, a template file is used to create a test environment and test cases corresponding to the chip. The test environment is a hardware verification platform built based on UVM. The test environment is used to simulate the working scenario of the chip's memory in the actual chip. The test cases are verification scenarios designed for different functional points of the memory.

[0078] In the embodiment of the present application, UVM specifies the interfaces and functions of standard components such as the driver agent, driver, monitor, and scoreboard to ensure a unified verification environment structure for different projects.

[0079] Among them, Memory is a functional module used to read, write and store data.

[0080] The template file includes at least one of an environment component, a test case, a test interface, an environment parameter, and a file list.

[0081] Among them, the environment components include the driver agent (mem_wr_agent), test sequence (sequence), driver (driver), monitor (monitor), scoreboard (scoreboard), environment (env), and macro definition file (mem_wrapper_define). The driver agent is used to accommodate the driver and monitor, instantiate and connect components, the test sequence is used to generate random test sequences, and the test sequence includes multiple transactions (transaction). The driver is used to drive the transactions of the test sequence to the interface according to the protocol to realize data reading and writing operations. The monitor is used to collect interface data in real time and send it to the scoreboard for comparison. The scoreboard is used to store the write data in the reference model and compare it with the read data to verify the correctness of the function. The environment is used to uniformly instantiate and connect all components to build a complete verification framework. The macro definition file (mem_wrapper_define) is used to define key parameters (such as address bit width and backdoor path) and dynamically replace them through configuration parameters.

[0082] Among them, the test interfaces include data read and write interface, ECC verification interface (Error-Correcting Code, ECC), EIM error injection module interface (Error Injection Module, EIM), low-power interface, and Design for Testability interface (Design for Testability, DFT). By providing multiple interfaces, the test environment supports multi-dimensional functional verification.

[0083] Among them, the test cases include at least one of the basic use case (base_test), read and write data use case (mem_wrapper_sanity_test), error injection use case, and low power function use case (mem_wrapper_power_mode). The error injection use case includes ECC and eim 1bit error injection use case (mem_wrapper_eim_ecc) and ECC 1bit backdoor path error injection use case (mem_wrapper_ecc_back_path). The basic use case is used to instantiate the verification environment, pass configuration parameters, and provide a basic framework for other use cases. The read and write data use case is used to test whether the read and write data are normal (for example, write random numbers to all addresses, compare them after reading to verify whether the read and write are consistent, and then perform read and write operations on random addresses to confirm whether the data processing at any position is correct). The ECC and eim 1bit error injection use case is used to perform full-address read and write verification, then turn on the EIM error injection function, inject 1bit error, and enable ECC check at the same time to check whether the system reports the error correctly. The 1-bit backdoor path error injection use case is used to modify memory data from the backdoor path through system functions (such as $readmemb() and $writememb()), flip 1 bit, and write it back to the memory to verify whether ECC can detect and correct errors. The low-power function use case is used to randomly configure the low-power interface during the data reading and writing process to verify the functional stability of the memory in energy-saving mode.

[0084] Among them, the environment parameters are stored in the parameter file, which is used to store the configuration parameters of the memory, such as the bit width and the number of banks.

[0085] Among them, the file list includes design files and environment files. The design file is the RTL file (Register-Transfer Level). The RTL file is the logic circuit file in the chip development process. The RTL file is a file implemented in the Verilog language. The format of the RTL file includes .v.

[0086] The template file includes an automation script, and the automation script includes a regression script. The regression script is used to automatically execute batch test cases and generate a verification report.

[0087] In the embodiment of the present application, in the system-on-chip (SOC) of the chip, many functional modules need to use memory. The main functions of memory include data reading and writing, data storage, error correction code (ECC), error injection management (EIM) and low power consumption. In different projects or different modules, the parameters of memory need to be adjusted according to the specifications of the specific chip. When the parameters are inconsistent, the specifications and functions of memory will be different, and the corresponding verification environment and test cases will also be different, and the corresponding verification environment needs to be rebuilt. Among them, the main parameters of memory include: type, depth, address bit width, data bit width, ECC enable, EIM enable, physical memory name (phy_mem), number of storage banks, etc. Memory types are divided into single-port (sp), dual-port (dp) and read-only memory (dp). Whether ECC is enabled determines whether the verification environment needs to include ECC-related test cases. The phy_mem name affects the naming of the backdoor path in the verification environment. Different memory types also affect the number of interfaces in the verification environment.

[0088] Although memory parameters are numerous, their types are limited, as are their functionality, verification environments, and test cases. Therefore, standard verification environments and test case templates can be developed in advance to avoid duplication of environment setup, reduce labor, and speed up verification.

[0089] Step S102: Generate a verification environment and test cases based on the template file.

[0090] Specifically, based on the template file, the automation script is executed to generate the verification environment and test cases.

[0091] In the embodiment of the present application, since different chips have different memory types and different memory parameters, the specific content of the template file is configured according to the specific situation.

[0092] In an embodiment of the present application, a test environment and test cases are generated through a template file, so that the test environment and test cases are standardized and more readable. In addition, by automatically generating the test environment and test cases, human errors can be reduced to improve the efficiency of chip testing.

[0093] Step S103: Obtain a configuration file, and based on the configuration file, update parameters in the verification environment and parameters in the test case to obtain an updated verification environment and updated test case.

[0094] Specifically, after generating the verification environment and test cases, obtain the configuration file, and based on the configuration file, update the parameters in the verification environment and the parameters in the test cases to obtain the updated verification environment and the updated test cases. For the specific process of updating the parameters in the verification environment and the parameters in the test cases, please refer to Figure 2 .

[0095] In an embodiment of the present application, the configuration file includes key parameters of the chip's memory, including module name (bench_name), read and write data bit width (awidth), read and write data bit width (dwidth), ECC check data bit width (cwidth), whether there is an ECC function judgment flag (ecc), whether there is an eim function judgment flag (eim_en), Mem selection (phy_name), and Bank number (bank_num).

[0096] See also Figure 2 , Figure 2 yes Figure 1 Detailed flow chart of step S103 in FIG.

[0097] like Figure 2 As shown, step S103 includes:

[0098] Step S1301: Parse the configuration file to obtain a plurality of first parameters and second parameters.

[0099] In an embodiment of the present application, the parameters of the configuration file are set according to actual conditions. By setting the parameters in the configuration file in advance, it is convenient to directly obtain the parameters in the configuration file when parsing the configuration file later, for example, setting the read and write address bit width awidth=32, the read and write data bit width dwidth=32, and the ECC check code data bit width to 7.

[0100] Specifically, the configuration file is parsed to obtain a plurality of first parameters and second parameters, wherein the first parameters are used to replace parameters in the verification environment, and the second parameters are used to replace parameters in the test case.

[0101] Among them, the first parameter includes the module name (bench_name), read and write address width (awidth), read and write data width (dwidth), ECC check data width (cwidth), etc. The second parameter includes the module name (bench_name), whether there is an ECC function judgment flag (ecc), etc.

[0102] Step S1302: Based on the first parameters and the second parameters, the parameters of the verification environment and the parameters in the test case are updated by an automated script to obtain an updated verification environment and an updated test case.

[0103] Specifically, based on a number of first parameters and second parameters, the parameters of the verification environment and the parameters in the test case are updated through an automated script to obtain an updated verification environment and an updated test case. For the specific process of updating parameters, please refer to Figure 3 .

[0104] In the embodiment of the present application, the parameters of the verification environment and test cases are updated through automated scripts, thereby avoiding manual parameter replacement and eliminating the uncertainty of human operation to improve the efficiency of parameter updating.

[0105] See also Figure 3 , Figure 3 yes Figure 2 Detailed flowchart of step S1302 in .

[0106] like Figure 3 As shown, step S1302 includes:

[0107] Step S1321: several first parameters in the configuration file are substituted for the third parameters in the verification environment to obtain an updated verification environment, wherein the parameter names of the first parameters and the third parameters are the same.

[0108] Specifically, after executing the automation script, several first parameters in the configuration file are substituted for the third parameters in the verification environment to obtain an updated verification environment, wherein the parameter names of the first parameters and the third parameters are the same.

[0109] For example, the name of the first parameter is awidth, and the third parameter in the verification environment has the same parameter name awidth. After obtaining the specific value of awidth from the configuration file, the specific value of the first parameter awidth in the configuration file is assigned to the third parameter awidth in the verification environment.

[0110] In an embodiment of the present application, when executing an automated script to replace parameters, a system function is automatically executed to replace the parameters. For example, when replacing the awidth parameter, the system function system("sed -i's / dwidth / $dwidth / g''grep dwidth-rl. / '") is executed.

[0111] In the embodiment of the present application, the parameters in the verification environment are adapted to ensure that the generated verification environment is adapted to the specifications of the chip's memory.

[0112] Step S1322: Replace the fourth parameters in the verification environment with the plurality of second parameters in the configuration file to obtain an updated test case, wherein the parameter names of the second parameters and the fourth parameters are the same.

[0113] Specifically, after executing the automation script, several second parameters in the configuration file are replaced with fourth parameters in the verification environment to obtain updated test cases, wherein the parameter names of the second parameters and the fourth parameters are the same.

[0114] For example, the name of the second parameter is phy_name, and the fourth parameter in the verification environment has the same parameter name phy_name. After obtaining the specific value of phy_name from the configuration file, the specific value of the second parameter phy_name in the configuration file is assigned to the fourth parameter phy_name in the verification environment.

[0115] In an embodiment of the present application, parameter values ​​are obtained by parsing the configuration file, and automated scripts are executed to replace the parameters in the verification environment and test cases. There is no need for manual parameter replacement, thereby avoiding repetitive work and human errors in manually developing the verification environment and test cases.

[0116] Step S104: Based on the updated verification environment and the updated test cases, regression testing is performed on the chip to obtain test results.

[0117] Specifically, replace the parameters in the verification environment and test cases to obtain the updated verification environment and updated test cases. Then, based on the updated verification environment and updated test cases, perform regression testing on the chip to obtain the test results. For the specific steps of regression testing, please refer to Figure 4 .

[0118] See also Figure 4 , Figure 4 yes Figure 1 Detailed flowchart of step S104 in .

[0119] like Figure 4 As shown, step S104 includes:

[0120] Step S1401: Generate several transactions based on the updated test case, wherein each updated test case corresponds to one transaction.

[0121] Specifically, the function and parameters of each updated test case are analyzed, a transaction class is defined for each updated test case, and a transaction is instantiated and configured for each updated test case in a test sequence to generate a plurality of transactions, wherein each updated test case corresponds to one transaction.

[0122] In an embodiment of the present application, a transaction is a logical unit that encapsulates test data and stores the parameters required for the test (such as read and write enable, address, error injection configuration, etc.) in the form of a class. The transaction is used to transfer data between verification environment components.

[0123] Step S1402: Input several transactions into the chip to obtain chip data.

[0124] Specifically, several transactions are converted into timing signals of the test interface of the memory, and then the timing signals are input into the chip through the test interface. After the several transactions are input into the chip, the chip data is obtained, where the chip data includes read data or write data.

[0125] Step S1403: Input the chip data into the updated verification environment to parse the chip data and obtain a parsing result.

[0126] In the implementation of this application, the updated verification environment includes a reference model, which is used to simulate the logical function of the chip to output the analysis results.

[0127] In the implementation of this application, during the chip testing process, the input data of the chip and the reference model are the same.

[0128] Specifically, the chip data is input into the updated verification environment, and the chip data is parsed using the reference model in the updated verification environment to obtain a parsing result.

[0129] In an embodiment of the present application, when the data of the chip is write data, the write data will be written into a memory simulated in a verification environment.

[0130] In the embodiment of the present application, when the data of the chip is read data, the analysis result output by the reference model includes the first read data.

[0131] See also Figure 5 , Figure 5 yes Figure 4 Detailed flowchart of step S1403 in .

[0132] like Figure 5 As shown, step S1403 includes:

[0133] Step S1431: parse the read data to obtain the read address.

[0134] Specifically, the chip data includes read data, and the read data is parsed to obtain a read address.

[0135] In an embodiment of the present application, during the test of the chip, if there is a read operation on the chip, the read data of the chip is obtained. The read data corresponds to a read address. After the read address is parsed, the read operation of the chip is simulated in a verification environment.

[0136] Step S1432: Based on the read address, obtain data corresponding to the read address to obtain a parsing result, wherein the parsing result includes the data corresponding to the read address.

[0137] Specifically, based on the read address, data corresponding to the read address is acquired to obtain a parsing result, wherein the parsing result includes the data corresponding to the read address.

[0138] Step S1404: Compare the chip data and analysis results to obtain the test results.

[0139] Specifically, after obtaining the analytical results output by the reference model, the chip data and analytical results are compared to obtain the test results. For the specific comparison process, please refer to Figure 6 .

[0140] See also Figure 6 , Figure 6 yes Figure 4 Detailed flowchart of step S1404 in .

[0141] like Figure 6 As shown, step S1404 includes:

[0142] Step S1441: Obtain chip data and analysis results.

[0143] Step S1442: Determine whether the parsing result is the same as the chip data.

[0144] Specifically, determine whether the analysis result is the same as the chip data. If the analysis result is the same as the chip data, jump to step S1443; if the analysis result is different from the chip data, jump to step S1444.

[0145] Step S1443: Determine that the test result is test passed.

[0146] Specifically, if the analysis result is the same as the chip data, the test result is determined to be passed.

[0147] Step S1444: Determine that the test result is a test failure.

[0148] Specifically, if the analysis result is different from the chip data, the test result is determined to be a test failure.

[0149] In the embodiment of the present application, test failure indicates that the chip has functional or performance defects in the current test scenario, and the data processing results do not meet the design expectations. In this case, the chip needs to be optimized and retested.

[0150] In an embodiment of the present application, the chip verification method is a logic function verification method in the chip front-end design stage. By constructing a template file to quickly generate a verification environment and test cases, and quickly replacing the parameters in the verification environment and test cases through a configuration file, it can avoid errors in manual operations and improve the efficiency of chip testing.

[0151] See also Figure 7 , Figure 7 This is a schematic diagram of the overall process of a chip verification method provided in an embodiment of the present application.

[0152] like Figure 7 As shown in FIG, the overall process of the chip verification method includes:

[0153] Step S701: Construct a verification environment template and test cases.

[0154] The verification environment template includes at least one of the module name, address bit width, read and write data bit width, check and correction data bit width, verification function judgment flag, error injection function judgment flag, memory type, and the number of memory banks.

[0155] The test cases include at least one of a basic test case, a read and write data test case, an error injection test case, and a low power consumption function test case.

[0156] Step S702: Obtain an automation script.

[0157] The automation script language includes Perl or Python.

[0158] Step S703: Configure parameters in the verification environment.

[0159] Specifically, a configuration file is obtained, and the configuration file is parsed by an automated script to obtain parameters of the configuration file. Based on the parameters of the configuration file, parameters in the verification environment are configured, that is, the parameters in the configuration file are replaced with parameters in the verification environment.

[0160] Step S704: Generate a new verification environment.

[0161] Specifically, while generating a new verification environment, a test case is generated based on a template file, and parameters in the test case are configured based on a configuration file to generate a new test case.

[0162] Step S705: Execute regression testing.

[0163] Specifically, based on the new verification environment and new test cases, regression testing is performed to obtain test results.

[0164] Specifically, based on the new test case, several transactions corresponding to the test case are generated, the transactions are sent to the chip, and the chip data is obtained. The chip data is input into the reference model to obtain the parsing result, and the chip data and the parsing result are compared to see if they are the same. If they are the same, the test is determined to have passed. If they are not the same, the test fails and the chip needs to be optimized.

[0165] In the embodiment of the present application, the chip includes three branches, namely Field-Programmable Gate Array (FPGA), Electronic Design Automation (EDA), and Intellectual Property (IP). FPGA is used for hardware-level verification of chip functions, EDA is used to verify the design in multiple dimensions such as logic and timing, and IP is a reusable functional module that can be quickly integrated into the system to improve design efficiency. By testing the chip from these three branches, the comprehensiveness of the chip test can be guaranteed.

[0166] See also Figure 8 , Figure 8 This is a schematic diagram of the structure of a chip verification system provided in an embodiment of the present application.

[0167] like Figure 8 As shown, the chip verification system 8000 includes a test device 8001 and a memory to be tested 8002. The memory to be tested 8002 includes a test interface 8201. The test device 8001 includes a computer terminal, a tablet, and the like.

[0168] In an embodiment of the present application, the test device 8001 is communicatively connected to the memory to be tested 8002. The test device 8001 is used to simulate the logical function of the memory to be tested 8002, obtain a simulation result, and compare the simulation result with the data of the memory to be tested 8002 to obtain a test result, wherein the simulation result includes an analysis result, and the analysis result is the analysis result output by the reference model in the test device 8001.

[0169] Specifically, the test device 8001 includes an agent module 8101 and a scoreboard 8102. The agent module 8101 includes a sequencer 8111, a driver 8112, and a monitor 8113. The scoreboard 8102 includes a fixed-width array simulation module 8121 and a data comparison module 8122. The fixed-width array simulation module 8121 includes a reference model.

[0170] The sequencer 8111 is connected to the driver 8112 and is used to generate transactions corresponding to the test cases.

[0171] The driver 8112 is connected to the sequencer 8111 and the memory under test 8002 , and is used to send transactions corresponding to the test case to the memory under test 8002 .

[0172] The monitor 8113 is connected to the memory under test 8002 , the fixed-width array simulation module 8121 , and the data comparison module 8122 . The monitor 8113 is used to obtain input data of the memory under test 8002 or output data of the memory under test 8002 .

[0173] The fixed-width array simulation module 8121 is connected to the monitor 8113 and the data comparison module 8122. The fixed-width array simulation module 8121 is used to receive input data from the memory under test 8002, or output read data based on output data of the memory under test 8002.

[0174] The data comparison module 8122 is connected to the fixed-width array simulation module 8121 and the monitor 8113, and is used to compare whether the output data of the memory under test 8002 is the same as the read data in the reference model to obtain the test result.

[0175] Specifically, a random sequence corresponding to a test case is obtained. The random sequence includes transactions. The transactions corresponding to the test case are input into a sequencer 8111. The sequencer 8111 sends the transactions to a driver 8112. The driver 8112 sends the transactions to a test interface 8201 of the memory under test 8002. The monitor 8113 monitors the input and output data of the test interface 8201 of the memory under test 8002 to obtain data of the memory under test 8002. The monitor 8113 sends the data of the memory under test 8002 to the fixed-width array simulation module 8121. , data comparison module 8122, the fixed-width array simulation module 8121 parses the data of the memory to be tested 8002, obtains the parsing result, and sends the parsing result to the data comparison module 8122, the data comparison module 8122 compares the data of the memory to be tested 8002 and the parsing result to determine the test result, the test result includes test pass and test fail, if the data of the memory to be tested 8002 and the parsing result are the same, the test result is test pass, if the data of the memory to be tested 8002 and the parsing result are different, the test result is test fail.

[0176] See also Figure 9 , Figure 9 This is a schematic diagram of the structure of a chip verification device provided in an embodiment of the present application.

[0177] like Figure 9As shown, the chip verification device 900 includes:

[0178] The construction module 901 is used to construct a template file.

[0179] The generation module 902 is used to generate a verification environment and test cases based on the template file.

[0180] The updating module 903 is used to obtain a configuration file and update parameters in the verification environment and parameters in the test case based on the configuration file to obtain an updated verification environment and updated test case.

[0181] The testing module 904 is used to perform regression testing on the chip based on the updated verification environment and updated test cases to obtain test results.

[0182] In an embodiment of the present application, the chip verification device can be a software module, which includes several instructions stored in a memory. The processor can access the memory and call the instructions for execution to complete the chip verification method of each of the above embodiments.

[0183] In the embodiments of the present application, the chip verification device can also be constructed by hardware devices. For example, the chip verification device can be constructed by one or more chips, and the chips can work in coordination with each other to complete the chip verification methods described in the above embodiments. For another example, the chip verification device can also be constructed by various logic devices, such as a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a single-chip microcomputer, an ARM (Acorn RISC Machine) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of these components.

[0184] The chip verification device in the embodiments of the present application can be a device, or a component, integrated circuit, or chip in a terminal. The system can be a mobile electronic device or a non-mobile electronic device. For example, the mobile electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. The non-mobile electronic device can be a server, network attached storage (NAS), personal computer (PC), television, ATM, or self-service machine, etc., which are not specifically limited in the embodiments of the present application.

[0185] The chip verification device in the embodiment of the present application may be a device having an operating system. The operating system may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.

[0186] The chip verification device provided in the embodiment of the present application can achieve Figure 1 To avoid repetition, the various processes implemented in the method embodiment are not described here.

[0187] It should be noted that the above device can execute the chip verification method provided in the embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method. For technical details not fully described in the device embodiment, please refer to the chip verification method provided in the embodiment of this application.

[0188] In the embodiment of the present application, the various modules of the chip verification device cooperate with each other to quickly generate a verification environment based on a template file and quickly replace parameters, thereby improving the efficiency of chip testing.

[0189] See also Figure 10 , Figure 10 It is a structural diagram of a testing device provided in an embodiment of the present application.

[0190] like Figure 10 As shown, the test device 8001 includes one or more processors 8103 and a memory 8104. Figure 10 A processor 8103 is taken as an example.

[0191] The processor 8103 and the memory 8104 may be connected via a bus or other means. Figure 10 The bus connection is taken as an example.

[0192] Processor 8103 is used to execute the chip verification method in any embodiment of the present application. The method constructs a template file to generate a verification environment and test cases based on the template file, obtains a configuration file, updates the parameters in the verification environment and test cases through the parameters in the configuration file, obtains an updated verification environment and an updated test case, and performs regression testing on the chip based on the updated verification environment and the updated test case to obtain test results. The method can quickly generate a verification environment based on the template file and quickly replace parameters to improve the efficiency of chip testing.

[0193] By quickly generating a verification environment based on template files and quickly replacing parameters, the efficiency of chip testing can be improved.

[0194] Memory 8104, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the chip verification method in the embodiments of the present invention. Processor 8103 executes the non-volatile software programs, instructions, and modules stored in memory 8104 to execute various server functional applications and data processing, thereby implementing the chip verification method in the above-mentioned method embodiment.

[0195] The memory 8104 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 8104 may optionally include a memory remotely located relative to the processor 8103. Examples of the aforementioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0196] One or more modules are stored in the memory 8104, and when executed by one or more processors 8103, the chip verification method in any of the above method embodiments is executed, for example, the chip verification method described above is executed. Figure 1 The steps shown.

[0197] An embodiment of the present application also provides a computer program product, which includes one or more program codes, which are stored in a non-volatile computer-readable storage medium. The processor of the server reads the program code from the non-volatile computer-readable storage medium, and the processor executes the program code to complete the steps of the chip verification method provided in the above embodiment.

[0198] Through the description of the above implementation methods, ordinary technicians in this field can understand that all or part of the steps of implementing the above embodiments can be completed by hardware, or by hardware related to program code through a program, and the program can be stored in a non-volatile computer-readable storage medium. The above-mentioned non-volatile computer-readable storage medium can be a read-only memory, a disk or an optical disk, etc.

[0199] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general hardware platform, or of course, by hardware. Those skilled in the art can understand that all or part of the processes in the above embodiment methods can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the non-volatile computer-readable storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (RAM), etc.

[0200] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Based on the idea of ​​the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the present application as mentioned above. For the sake of simplicity, they are not provided in detail. Although the present application has been described in detail with reference to the aforementioned embodiments, ordinary technicians in this field should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A chip verification method, characterized in that: The method comprises: Build template files; Based on the template file, generate a verification environment and test cases; Obtaining a configuration file, and based on the configuration file, updating parameters in the verification environment and parameters in the test case to obtain an updated verification environment and an updated test case, wherein the configuration file includes at least one of a module name, a read / write address bit width, a read / write data bit width, an ECC check data bit width, a check function judgment flag, an error injection function judgment flag, a memory type, and a number of memory banks; Based on the updated verification environment and the updated test cases, regression testing is performed on the chip to obtain test results; The updating of the parameters of the verification environment and the parameters in the test case based on the configuration file to obtain the updated verification environment and the updated test case includes: Parsing the configuration file to obtain a plurality of first parameters and second parameters; Based on the first parameters and the second parameters, updating the parameters of the verification environment and the parameters in the test case through an automated script to obtain an updated verification environment and an updated test case; The updating of the parameters of the verification environment and the parameters in the test case by an automated script based on the plurality of first parameters and second parameters to obtain an updated verification environment and an updated test case includes: Replacing the third parameters in the verification environment with the first parameters in the configuration file to obtain the updated verification environment, wherein the parameter names of the first parameters and the third parameters are the same; Replacing the fourth parameter in the verification environment with the plurality of second parameters in the configuration file to obtain the updated test case, wherein the parameter names of the second parameter and the fourth parameter are the same; The replacing the third parameter in the verification environment with the plurality of first parameters in the configuration file to obtain the updated verification environment includes: Obtaining a specific value of a first parameter from a configuration file, and assigning the specific value of the first parameter to a third parameter in the verification environment to obtain the updated verification environment; Replacing the fourth parameter in the verification environment with the plurality of second parameters in the configuration file to obtain the updated test case includes: Obtaining a specific value of a second parameter from a configuration file, assigning the specific value of the second parameter to a fourth parameter in the verification environment, and obtaining the updated test case; The step of performing regression testing on the chip based on the updated verification environment and the updated test case to obtain a test result includes: Based on the updated test case, generating a plurality of transactions, wherein each updated test case corresponds to a transaction; inputting a plurality of the transactions into the chip to obtain data from the chip; Inputting the chip data into the updated verification environment to parse the chip data and obtain a parsing result; The chip data and analysis results are compared to obtain the test results.

2. The method according to claim 1, characterized in that The template file includes at least one of an environment component, a test case, a test interface, an environment parameter, and a file list; The test cases include at least one of a basic test case, a read and write data test case, an error injection test case, and a low power consumption function test case.

3. The method according to claim 1, characterized in that The updated verification environment includes a reference model, the reference model is used to simulate the logic function of the chip to output the analysis result, and the data of the chip includes read data; The step of parsing the chip data to obtain parsing results includes: Parsing the read data to obtain a read address; Based on the read address, data corresponding to the read address is acquired to obtain the parsing result, wherein the parsing result includes the data corresponding to the read address.

4. The method according to claim 1, wherein The test results include test pass and test fail, and the comparison of the chip data and the analysis results to obtain the test results includes: If the analysis result is the same as the chip data, the test result is determined to be a pass; If the analysis result is different from the chip data, the test result is determined to be a test failure.

5. A testing device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 4.

6. A chip verification system, characterized in that: The system comprises: Memory to be tested; The test device according to claim 5 is communicatively connected to the memory under test, and is used to simulate the logical function of the memory under test to obtain a simulation result, and compare the simulation result with the data of the memory under test to obtain a test result.

7. The system according to claim 6, characterized in that The test equipment includes an agent module and a scoreboard, wherein the agent module includes a sequencer, a driver, and a monitor, and the scoreboard includes a fixed-width array simulation module and a data comparison module; The sequencer is connected to the driver and is used to generate transactions corresponding to the test case; The driver is connected to the sequencer and the memory under test, and is used to send the transaction corresponding to the test case to the memory under test; The monitor is connected to the memory to be tested, the fixed-width array simulation module, and the data comparison module, and is used to obtain input data of the memory to be tested or output data of the memory to be tested; The fixed-width array simulation module is connected to the monitor and the data comparison module, and is used to receive input data of the memory under test, or output read data based on output data of the memory under test; The data comparison module is connected to the fixed-width array simulation module and the monitor, and is used to compare the output data of the memory to be tested with the read data in the fixed-width array simulation module to see whether they are the same, so as to obtain a test result.

Images