Disclosure of Invention
In order to solve the technical problems, the embodiment of the application provides a chip verification method, test equipment and a chip verification system, which can quickly generate verification environments and quickly replace parameters based on template files so as to improve the efficiency of chip test.
In order to solve the technical problems, the embodiment of the application provides the following technical scheme:
in a first aspect, an embodiment of the present application provides a chip verification method, including:
constructing a template file;
generating a verification environment and a test case based on the template file;
acquiring a configuration file, and updating parameters in the verification environment and parameters in the test cases based on the configuration file to obtain an updated verification environment and an updated test case;
based on the updated verification environment and the updated test cases, carrying out regression testing on the chip to obtain a test result;
Based on the configuration file, updating parameters of the verification environment and parameters in the test case to obtain an updated verification environment and an updated test case, including:
analyzing the configuration file to obtain a plurality of first parameters and second parameters;
based on a plurality of first parameters and second parameters, updating parameters of the verification environment and parameters in the test cases through an automatic script to obtain updated verification environment and updated test cases;
Based on a plurality of first parameters and second parameters, updating parameters of the verification environment and parameters in the test cases through an automation script to obtain updated verification environment and updated test cases, wherein the method comprises the following steps:
Replacing a third parameter in the verification environment with a plurality of 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;
replacing a fourth parameter in the verification environment with a 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;
replacing a third parameter in the verification environment with a plurality of first parameters in the configuration file to obtain an updated verification environment, including:
acquiring a specific value of the first parameter from the configuration file, and assigning the specific value of the first parameter to a third parameter in the verification environment to obtain an updated verification environment;
Replacing a fourth parameter in the verification environment with a plurality of second parameters in the configuration file to obtain an updated test case, including:
and acquiring a specific value of the second parameter from the configuration file, and assigning the specific value of the second parameter to a fourth parameter in the verification environment to obtain an updated test case.
In some embodiments, the template file includes at least one of an environment component, a test case, a test interface, an environment parameter, a file list;
The configuration file comprises 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 mark, an error injection function judgment mark, a memory type and the number of memory banks of the memory;
The test cases comprise at least one of basic cases, read-write data cases, error injection cases and low-power-consumption functional cases.
In some embodiments, based on the updated verification environment and the updated test case, performing a regression test on the chip to obtain a test result, including:
Generating a plurality of transactions based on the updated test cases, wherein each updated test case corresponds to one transaction;
inputting a plurality of transactions to a chip to acquire data of the chip;
Inputting the data of the chip into the updated verification environment to analyze the data of the chip to obtain an analysis result;
and comparing the data and the analysis result of the chip to obtain a test result.
In some embodiments, the updated verification environment includes a reference model for simulating a logic function of the chip to output the parsing result, the data of the chip including read data;
analyzing the data of the chip to obtain an analysis result, including:
Analyzing the read data to obtain a read address;
based on the read address, obtaining data corresponding to the read address to obtain an analysis result, wherein the analysis result comprises the data corresponding to the read address.
In some embodiments, the test results include test passing and test failing, and comparing the data and the analysis result of the chip to obtain the test results, including:
if the analysis result is the same as the data of the chip, determining that the test result is the passing of the test;
if the analysis result is different from the data of the chip, determining that the test result is a test failure.
In a second aspect, an embodiment of the present application provides a test apparatus, including:
At least one processor, and
A memory communicatively coupled to the at least one processor, wherein,
The memory stores instructions executable by the at least one processor to enable the at least one processor to perform a method as in the first aspect.
In a third aspect, an embodiment of the present application provides a chip verification system, including:
a memory to be tested;
The test device according to the second aspect is communicatively connected to the memory to be tested, and is configured to simulate a logic function of the memory to be tested to obtain a simulation result, and compare the simulation result with data of the memory to be tested to obtain a test result.
In some embodiments, the test equipment comprises a proxy module and a scoring board, wherein the proxy module comprises a sequencer, a driver and a monitor, and the scoring board comprises a fixed-width array simulation module and a data comparison module;
the sequencer is connected with the driver and used for generating a transaction corresponding to the test case;
the driver is connected with the sequencer and the memory to be tested and is used for sending the transaction corresponding to the test case to the memory to be tested;
The monitor is connected with the memory to be tested, the fixed-width array simulation module and the data comparison module and is used for acquiring 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 with the monitor and the data comparison module and is used for receiving input data of the memory to be tested or outputting read data based on output data of the memory to be tested;
the data comparison module is connected with the fixed-width array simulation module and the monitor and is used for comparing whether the output data of the memory to be tested is the same as the read data in the fixed-width array simulation module or not so as to obtain a test result.
The chip verification method has the advantages that the method is different from the situation in the prior art, the verification environment and the test cases are generated based on the template file by constructing the template file, the configuration file is obtained, the verification environment and the test cases are updated through parameters in the configuration file, the updated verification environment and the updated test cases are obtained, regression testing is conducted on the chip based on the updated verification environment and the updated test cases, a test result is obtained, the verification environment can be quickly generated based on the template file, and the parameters can be quickly replaced, so that the efficiency of chip testing is improved.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
It should be noted that, if not in conflict, the features of the embodiments of the present application may be combined with each other, which is within the protection scope of the present application. In addition, the words "first", "second", etc. used in the present application do not limit data, but merely divide the same items or similar items having substantially the same functions and actions.
Before describing the embodiments of the present application, a chip verification method known to the present inventors is first described briefly, so that the embodiments of the present application will be convenient to understand later.
Currently, UVM verification environments are developed separately for different chips, or the code is manually modified after inheriting the verification environments from previous projects.
Or setting up a One-time programmable verification environment (One-Time Programmable, OTP) based on a general verification method (universal verification methodology, UVM), testing the top layer as a memory to be tested, acquiring OTP programming, reading register information and mapping logic of the OTP in the memory to be tested, applying closing excitation to a high-speed signal which is irrelevant to OTP programming and reading in the memory to be tested, constructing test cases according to different scenes, applying excitation to the memory to be tested, and completing quick verification of OTP programming and reading logic and mapping logic through data comparison.
Drawbacks of the above solution include:
(1) The verification environment needs to be manually built or modified, the time is long, the debugging period is long, and the environmental stability is poor.
(2) The building efficiency is low, the error rate is high because of the lack of a unified template, and the quick multiplexing is difficult.
(3) The environment is required to be built independently for different memories, the parameter adjustment is complicated, and errors are easy to introduce.
(4) The manual operation results in a plurality of repeated steps and poor accuracy, and the testing efficiency of the chip is reduced.
In order to solve the problems, the application provides a chip verification method, which comprises the steps of constructing a template file to generate a verification environment and a test case based on the template file, acquiring a configuration file, updating parameters in the verification environment and the test case through parameters in the configuration file to obtain an updated verification environment and an updated test case, carrying out regression test on a chip based on the updated verification environment and the updated test case to obtain a test result, and rapidly generating the verification environment and rapidly replacing parameters based on the template file to improve the efficiency of chip test.
The technical scheme of the application is specifically described below with reference to the accompanying drawings of the specification:
Referring to fig. 1, fig. 1 is a flowchart of a chip verification method according to an embodiment of the application.
The chip verification method is applied to the test equipment, and specifically, the execution subject of the chip verification method is one or at least two processors of the test equipment.
Wherein the test equipment is in communication with the chip. Test equipment includes, but is not limited to, computer terminals, computers, and the like.
As shown in fig. 1, the chip verification method includes:
And S101, constructing a template file.
In the embodiment of the application, the template file is used for creating a test environment and a test case corresponding to the chip, the test environment is a hardware verification platform built based on UVM, the test environment is used for simulating the working scene of a Memory (Memory) of the chip in an actual chip, and the test case is a verification scene designed aiming at different functional points of the Memory.
In the embodiment of the application, UVM prescribes interfaces and functions of standard components such as a drive agent (agent), a driver (driver), a monitor (monitor), a score board (scoreboard) and the like, and ensures the unified verification environment structure of different projects.
The Memory is a functional module for reading and writing data and storing data.
The template file comprises at least one of an environment component, a test case, a test interface, environment parameters and a file list.
The environment components include a driving agent (mem_wr_agent), a test sequence (sequence), a driver (driver), a monitor (monitor), a scoreboard (scoreboard), an environment (env), a macro definition file (mem_wrapper_definition), wherein the driving agent is used for accommodating the driver and the monitor, instantiating and connecting the components, the test sequence is used for generating a random test sequence, the test sequence comprises a plurality of transactions (transactions), the driver is used for driving the transactions of the test sequence to an interface according to a protocol to realize the read-write operation of data, the monitor is used for collecting interface data in real time, sending the interface data to the scoreboard for comparison, the scoreboard is used for storing the write data into a reference model and comparing the read data to verify the correctness of functions, the environment is used for instantiating and connecting all the components, a complete verification framework is constructed, and the macro definition file (mem_wrapper_definition) is used for defining key parameters (such as address bit width and back gate path) and is dynamically replaced by configuration parameters.
The test interface comprises a data read-write interface, an ECC (Error-correction Code) interface, an EIM (EIM) Error injection interface (Error Injection Module, EIM), a low-power interface and a testability design interface (Design for Testability, DFT), and various interfaces are provided to enable the test environment to support multi-dimensional functional verification.
The test cases include at least one of a base case (base_test), a read-write data case (mem_wrapper_ sanity _test), an error injection case, and a low-power function case (mem_wrapper_power_mode), the error injection case includes an ECC and an EIM 1bit error injection case (mem_wrapper_ecc) and an ECC 1bit back gate path error injection case (mem_wrapper_back_path), the base case is used for checking an environment, configuration parameters are transmitted for other cases, the read-write data case is used for testing whether read-write data is normal (for example, random numbers are written to all addresses, after read-out, to verify whether read-write is consistent, then random addresses are read-write-in, to confirm whether any position data processing is correct), the ECC and the EIM 1bit error injection case are used for performing all-address read-write verification, the EIM injection function is started, and the error injection function is used for checking whether the error 1bit is correct, and simultaneously, after the error 1bit error injection system is switched back to the Memory 1bit error case, and the error function is used for checking whether the error 1bit error is correct, and the error is used for checking the error of the error 1bit system is correct, and the error is used for checking whether the error is correct by the error in the Memory 1bit system, and the error correction function is used for checking the error (for checking the error 1) after the error has been written to the error, and the error has been written to the error data is written at all addresses, and the Memory has been written at the address, and the error has been checked.
The environment parameters are stored in a parameter file, and the parameter file is used for storing configuration parameters of the Memory, such as bit width and Bank number.
The file list comprises design files and environment files, wherein the design files are RTL files (Register-TRANSFER LEVEL), the RTL files are logic circuit files in the chip development process, the RTL files are files realized by using Verilog language, and the format of the RTL files comprises v.
The template file comprises an automation script, wherein the automation script comprises a regression script, and the regression script is used for automatically executing batch test cases and generating a verification report.
In the embodiment of the application, in a System-on-Chip (SOC) of a Chip, a plurality of functional modules need to use a Memory (Memory), and main functions of the Memory include data Read-write, data storage, error checking and correction (Error Correcting Code, ECC), error injection management (Error Injection Management, EIM), low power consumption, etc., in different projects or different modules, parameters of the Memory need to be adjusted according to specifications of a specific Chip, when the parameters are inconsistent, the specifications and functions of the Memory are different, corresponding verification environments and test cases are also different, and then the corresponding verification environments need to be built again, wherein main parameters of the Memory include types, depths, address bit widths, data bit widths, ECC enabling, EIM enabling, physical Memory names (phy_mem), memory bank numbers, memory types are also divided into Single-Port, dual-Port, memory (Dual-Port, dpad) and Memory (Memory), and the Memory types need to be Read-on, and whether the verification environments of the Memory need to be affected by the name of the Memory are different from the Memory, and whether the verification environments need to be affected by the verification environments are affected by the name of the Memory.
Although Memory has many parameters, in practice, the variety of parameters is limited, and the functions, verification environments, and test cases are limited. Therefore, the standard verification environment and templates of the test cases can be developed in advance, repeated construction of the environment can be avoided, success of manpower is reduced, and verification speed is improved.
Step S102, generating a verification environment and a test case based on the template file.
Specifically, an automation script is executed based on the template file to generate a verification environment and test cases.
In the embodiment of the application, as the memory types of different chips are different and the parameters of the memory are also different, the specific content of the template file is configured according to specific conditions.
In the embodiment of the application, the test environment and the test case are generated through the template file, so that the test environment and the test case are standardized and have better readability, and human errors can be reduced through automatically generating the test environment and the test case, so that the efficiency of chip test is improved.
Step S103, acquiring a configuration file, and updating parameters in the verification environment and parameters in the test cases based on the configuration file to obtain updated verification environment and updated test cases.
Specifically, after the verification environment and the test case are generated, a configuration file is obtained, and parameters in the verification environment and parameters in the test case are updated based on the configuration file, so that the updated verification environment and the updated test case are obtained. The specific process of updating parameters in the verification environment and parameters in the test cases is shown in FIG. 2.
In the embodiment of the application, the configuration file comprises key parameters of a memory of the chip, wherein the key parameters comprise a module name (criterion_name), a read-write data bit width (awidth), a read-write data bit width (dwidth), an ECC check data bit width (cwidth), an ECC function judging mark (ECC), an eim function judging mark (eim_en), a Mem type (phy_name) and a Bank number (bank_num).
Referring to fig. 2, fig. 2 is a schematic diagram of a refinement flow of step S103 in fig. 1.
As shown in fig. 2, this step S103 includes:
And step S1301, analyzing the configuration file to obtain a plurality of first parameters and second parameters.
In the embodiment of the application, the parameters of the configuration file are set according to the actual situation, and the parameters in the configuration file are set in advance, so that the parameters in the configuration file can be directly acquired when the configuration file is analyzed later, for example, the read-write address bit width awidth =32, the read-write data bit width dwidth =32 and the ECC check code data bit width is 7.
Specifically, the configuration file is parsed to obtain a plurality of first parameters and second parameters, wherein the first parameters are used for replacing parameters in the verification environment, and the second parameters are used for replacing parameters in the test case.
The first parameter includes a module name (standard_name), a read-write address bit width (awidth), a read-write data bit width (dwidth), an ECC check data bit width (cwidth), and the second parameter includes a module name (standard_name), an ECC function judging flag (ECC), and the like.
Step S1302, based on the first parameters and the second parameters, updating parameters of the verification environment and parameters in the test cases through an automatic script to obtain updated verification environments and updated test cases.
Specifically, based on a plurality of first parameters and second parameters, parameters of the verification environment and parameters in the test cases are updated through an automatic script, and the updated verification environment and the updated test cases are obtained. The specific process of updating parameters is shown in fig. 3.
In the embodiment of the application, the parameters of the verification environment and the test case are updated through the automatic script, so that the manual parameter replacement is avoided, the uncertainty of manual operation is eliminated, and the parameter updating efficiency is improved.
Referring to fig. 3, fig. 3 is a schematic diagram of a refinement flow chart of step S1302 in fig. 2.
As shown in fig. 3, this step S1302 includes:
and step S1321, replacing a third parameter in the verification environment with a plurality of 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.
Specifically, after the automation script is executed, replacing a third parameter in the verification environment with a plurality of 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.
For example, the name of the first parameter is awidth, the same parameter name awidth exists for the third parameter in the verification environment, and after the specific value of awidth is obtained 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.
In an embodiment of the application, when an automation script is executed to perform parameter replacement, a system function is automatically executed to replace a parameter, e.g., to replace awidth parameters, and a system function system is executed ("sed-i's/dwidth/$ dwidth/g' '-GREP DWIDTH-rl./'").
In the embodiment of the application, the generated verification environment is ensured to be matched with the specification of the memory of the chip by adapting the parameters in the verification environment.
And S1322, replacing a fourth parameter in the verification environment with a 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.
Specifically, after the automation script is executed, replacing a fourth parameter in the verification environment with a 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.
For example, the name of the second parameter is phy_name, the same parameter name phy_name exists in the fourth parameter in the verification environment, and after a specific value of phy_name is obtained 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.
In the embodiment of the application, the parameter values are obtained by analyzing the configuration file, the automatic script is executed to replace the parameters in the verification environment and the test case, and the parameter replacement is not needed to be manually executed, so that the repeated work and human errors of manually developing the verification environment and the test case are avoided.
And step S104, carrying out regression testing on the chip based on the updated verification environment and the updated test case to obtain a test result.
Specifically, the parameters in the verification environment and the test cases are replaced, after the updated verification environment and the updated test cases are obtained, regression testing is conducted on the chip based on the updated verification environment and the updated test cases, and a test result is obtained. The specific steps of the regression test are shown in FIG. 4.
Referring to fig. 4, fig. 4 is a schematic diagram of a refinement flow of step S104 in fig. 1.
As shown in fig. 4, this step S104 includes:
Step S1401, generating a plurality of transactions based on the updated test cases, wherein each updated test case corresponds to one transaction.
Specifically, the function and the parameter of each updated test case are analyzed, a transaction class is defined for each updated test case, the transaction is instantiated in the test sequence and configured for each updated test case, so as to generate a plurality of transactions, wherein each updated test case corresponds to one transaction.
In an embodiment of the present application, a Transaction (Transaction) is a logical unit that encapsulates test data, stores parameters required for testing (e.g., read-write enable, address, error injection configuration, etc.) in Class (Class) form, and is used to transfer data between components of a verification environment.
Step S1402, several transactions are input to the chip to obtain data of the chip.
Specifically, a plurality of transactions are converted into time sequence signals of a test interface of a memory, then the time sequence signals are input into a chip through the test interface, and after the plurality of transactions are input into the chip, data of the chip are obtained, wherein the data of the chip comprise read data or write data.
Step S1403, inputting the data of the chip into the updated verification environment to analyze the data of the chip to obtain an analysis result.
In the implementation of the application, the updated verification environment comprises a reference model, and the reference model is used for simulating the logic function of the chip to output the analysis result.
In the implementation of the application, the input data of the chip and the reference model are the same in the process of testing the chip.
Specifically, the data of the chip is input into the updated verification environment, and the data of the chip is analyzed through a reference model in the updated verification environment to obtain an analysis result.
In the embodiment of the application, when the data of the chip is write data, the write data is written into the simulated memory in the verification environment.
In the embodiment of the application, when the data of the chip is the read data, the analysis result output by the reference model comprises the first read data.
Referring to fig. 5, fig. 5 is a schematic diagram of the refinement flow of step S1403 in fig. 4.
As shown in fig. 5, this step S1403 includes:
In step S1431, the read data is parsed to obtain a read address.
Specifically, the data of the chip includes read data, and the read data is parsed to obtain a read address.
In the embodiment of the application, in the process of testing the chip, if the chip is subjected to read operation, the read data of the chip is obtained, the read data corresponds to a read address, and after the read address is obtained through analysis, the read operation of the chip is simulated in a verification environment.
Step S1432, based on the read address, obtaining the data corresponding to the read address to obtain an analysis result, wherein the analysis result comprises the data corresponding to the read address.
Specifically, based on the read address, data corresponding to the read address is obtained to obtain an analysis result, wherein the analysis result comprises the data corresponding to the read address.
And step S1404, comparing the data of the chip with the analysis result to obtain a test result.
Specifically, after the analysis result output by the reference model is obtained, the data of the chip and the analysis result are compared to obtain a test result. The specific process of comparison is shown in fig. 6.
Referring to fig. 6, fig. 6 is a schematic diagram of a refinement flow of step S1404 in fig. 4.
As shown in fig. 6, this step S1404 includes:
And S1441, acquiring data and analysis results of the chip.
Step S1442, determining whether the analysis result is the same as the data of the chip.
Specifically, it is determined whether the analysis result is the same as the data of the chip, if the analysis result is the same as the data of the chip, the process goes to step S1443, and if the analysis result is not the same as the data of the chip, the process goes to step S1444.
And S1443, determining that the test result is that the test passes.
Specifically, if the analysis result is the same as the data of the chip, determining that the test result is that the test passes
Step S1444, determining the test result as a test failure.
Specifically, if the analysis result is different from the data of the chip, determining that the test result is a test failure.
In the embodiment of the application, the failure of the test indicates that the chip has functional or performance defects in the current test scene, and if the data processing result is inconsistent with the design expectation, the chip needs to be optimized and then the test is carried out again.
In the embodiment of the application, the chip verification method is a logic function verification method in the front-end design stage of the chip, the verification environment and the test case are quickly generated by constructing the template file, and the parameters in the verification environment and the test case are quickly replaced by the configuration file, so that errors caused by manual operation can be avoided, and the efficiency of chip test is improved.
Referring to fig. 7, fig. 7 is a general flow chart of a chip verification method according to an embodiment of the application.
As shown in fig. 7, the overall flow of the chip verification method includes:
and step 701, constructing a verification environment template and a test case.
The verification environment template comprises at least one of a module name, an address bit width, a read-write data bit width, an inspection and correction data bit width, a verification function judgment mark, an error injection function judgment mark, a memory type and the number of memory banks of the memory.
The test cases comprise at least one of a basic case, a read-write data case, an error injection case and a low-power-consumption functional case.
And step S702, acquiring an automation script.
Wherein the language of the automation script comprises a Perl language or a Python language.
Step S703, configuring parameters in the verification environment.
Specifically, a configuration file is obtained, the configuration file is analyzed through an automation script to obtain parameters of the configuration file, and parameters in a verification environment are configured based on the parameters of the configuration file, namely, the parameters of the configuration file replace the parameters in the verification environment.
Step S704, generating a new verification environment.
Specifically, a new verification environment is generated, a test case is generated based on the template file, and parameters in the test case are configured based on the configuration file, so that a new test case is generated.
Step S705, executing regression testing.
Specifically, based on the new verification environment and the new test case, a regression test is performed to obtain a test result.
Specifically, based on the new test cases, generating a plurality of transactions corresponding to the test cases, sending the transactions to the chip, acquiring data of the chip, inputting the data of the chip into the reference model to obtain an analysis result, comparing whether the data of the chip and the analysis result are the same, if so, determining that the test is passed, and if not, failing, and optimizing the chip.
In the embodiment of the application, the chip comprises three branches, namely a Field Programmable gate array (Field-Programmable GATE ARRAY, FPGA), electronic design automation (Electronic Design Automation, EDA) and an intellectual property core (Intellectual Property, IP), wherein the FPGA is used for hardware-level verification of chip functions, the EDA is used for verifying multiple dimensions such as logic, time sequence and the like of the design, the IP is a reusable functional module, the chip can be rapidly integrated into a system to improve the design efficiency, and the comprehensiveness of chip test can be ensured by testing the chip from the three branches.
Referring to fig. 8, fig. 8 is a schematic structural diagram of a chip verification system according to an embodiment of the application.
As shown in fig. 8, the chip authentication system 8000 includes a test device 8001, a memory under test 8002, and the memory under test 8002 includes a test interface 8201. The test apparatus 8001 includes a computer terminal, a tablet, and the like.
In the embodiment of the present application, the test device 8001 is communicatively connected to the memory to be tested 8002, and the test device 8001 is configured to simulate a logic function of the memory to be tested 8002 to obtain a simulation result, and compare the simulation result with data of the memory to be tested 8002 to obtain a test result, where the simulation result includes an analysis result, and the analysis result is an analysis result output by a reference model in the test device 8001.
Specifically, the test apparatus 8001 includes a proxy module 8101, a scoreboard 8102, the proxy 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, and the fixed-width array simulation module 8121 includes a reference model.
The sequencer 8111 is connected to the driver 8112, and the sequencer 8111 is configured to generate a transaction corresponding to a test case.
The driver 8112 is connected to the sequencer 8111 and the memory under test 8002, and the driver 8112 is configured to send a transaction corresponding to a test case to the memory under test 8002.
The monitor 8113 is connected to the memory 8002 to be measured, the fixed-width array simulation module 8121, and the data comparison module 8122, and the monitor 8103 is configured to acquire input data of the memory 8002 to be measured or output data of the memory 8002 to be measured.
The fixed-width array simulation module 8121 is connected with the monitor 8113 and the data comparison module 8122, and the fixed-width array simulation module 8121 is used for receiving input data of the memory 8002 to be tested, or outputting read data based on output data of the memory 8002 to be tested;
The data comparison module 8122 is connected with the fixed-width array simulation module 8121 and the monitor 8113, and is used for comparing whether the output data of the memory 8002 to be tested is the same as the read data in the reference model, so as to obtain a test result.
Specifically, a random sequence corresponding to the test case is obtained, the random sequence includes transactions, the transactions corresponding to the test case are input to the sequencer 8111, the sequencer 8111 sends the transactions to the driver 8112, the driver 8112 sends the transactions to the test interface 8201 of the memory 8002 to be tested, the monitor 8113 virtually monitors input and output data of the test interface 8201 of the memory 8002 to be tested to obtain data of the memory 8002 to be tested, the monitor 8113 respectively sends the data of the memory 8002 to be tested to the fixed-width array simulation module 8121 and the data comparison module 8122, the fixed-width array simulation module 8121 analyzes the data of the memory 8002 to be tested to obtain an analysis result, and sends the analysis result to the data comparison module 8122, the data comparison module 8122 compares the data of the memory 8002 to be tested with the analysis result to determine a test result, the test result includes a test pass and a test fail, if the data of the memory 8002 to be tested and the analysis result are the same, and the test result is a test fail.
Referring to fig. 9, fig. 9 is a schematic structural diagram of a chip verification device according to an embodiment of the application.
As shown in fig. 9, the chip authentication apparatus 900 includes:
A construction module 901, configured to construct a template file.
A generating module 902, configured to generate a verification environment and a test case based on the template file.
The updating module 903 is configured to obtain a configuration file, update parameters in the verification environment and parameters in the test case based on the configuration file, and obtain an updated verification environment and an updated test case.
And the test module 904 is used for carrying out regression test on the chip based on the updated verification environment and the updated test case to obtain a test result.
In the embodiment of the application, the chip verification device may be a software module, and the software module includes a plurality of instructions, which are stored in a memory, and the processor may access the memory and call the instructions to execute, so as to complete the chip verification method of each embodiment.
In the embodiment of the application, the chip verification device may also be built by hardware devices, for example, the chip verification device may be built by one or more than two chips, and each chip may work in coordination with each other to complete the chip verification method described in each embodiment above. For another example, the chip authentication apparatus may also be built from various types of logic devices, such as general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSPs), application Specific Integrated Circuits (ASICs), field programmable gate arrays (Field Programmable GATEARRAY, FPGA), single chip computers, ARM (Acorn RISC MACHINE) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these components.
The chip verification device in the embodiment of the application can be a device, and can also be a component, an integrated circuit or a chip in a terminal. The system may be a mobile electronic device or a non-mobile electronic device. By way of example, the mobile electronic device may be a mobile phone, a tablet computer, a notebook computer, a palm computer, a vehicle-mounted electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a Personal Digital Assistant (PDA), etc., and the non-mobile electronic device may be a server, a network attached storage (Network Attached Storage, NAS), a personal computer (personal computer, PC), a Television (TV), a teller machine, a self-service machine, etc., and the embodiments of the present application are not limited in particular.
The chip verification device in the embodiment of the application can be a device with an operating system. The operating system may be an Android operating system, an ios operating system, or other possible operating systems, and the embodiment of the present application is not limited specifically.
The chip verification device provided by the embodiment of the present application can implement each process implemented by the method embodiment of fig. 1, and in order to avoid repetition, a description thereof will not be repeated here.
It should be noted that, the device can execute the chip verification method provided by the embodiment of the application, and has the corresponding functional modules and beneficial effects of the execution method. Technical details not described in detail in the device embodiments may be referred to the chip verification method provided in the embodiments of the present application.
In the embodiment of the application, the verification environment and the quick replacement parameters can be quickly generated based on the template file by mutually matching the modules of the chip verification device so as to improve the efficiency of chip test.
Referring to fig. 10, fig. 10 is a schematic structural diagram of a test apparatus according to an embodiment of the application.
As shown in fig. 10, the test apparatus 8001 includes one or more processors 8103 and a memory 8104. In fig. 10, a processor 8103 is taken as an example.
The processor 8103 and the memory 8104 may be connected by a bus or otherwise, for example in fig. 10.
The processor 8103 is configured to execute the chip verification method according to any embodiment of the present application, where a template file is constructed to generate a verification environment and a test case based on the template file, and a configuration file is obtained to update parameters in the verification environment and the test case by using parameters in the configuration file, so as to obtain an updated verification environment and an updated test case, and perform a regression test on a chip based on the updated verification environment and the updated test case, so as to obtain a test result, and enable the verification environment to be quickly generated based on the template file, and the parameters to be quickly replaced, so as to improve the efficiency of the chip test.
The verification environment is quickly generated based on the template file, and parameters are quickly replaced, so that the efficiency of chip testing is improved.
The memory 8104 serves as a non-volatile computer-readable storage medium, and may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions/modules corresponding to the chip verification method in the embodiment of the present invention. The processor 8103 executes various functional applications of the server and data processing, that is, implements the chip authentication method of the above-described method embodiment, by running nonvolatile software programs, instructions, and modules stored in the memory 8104.
The memory 8104 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 8104 optionally includes memory located remotely from processor 8103. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
One or more modules are stored in the memory 8104 that, when executed by the one or more processors 8103, perform the chip authentication method in any of the method embodiments described above, e.g., perform the various steps shown in fig. 1 described above.
Embodiments of the present application also provide a computer program product including one or more program codes stored in a non-volatile computer-readable storage medium, which is read from the non-volatile computer-readable storage medium by a processor of a server, the processor executing the program codes to accomplish the steps of the chip authentication method provided in the above embodiments.
Those of ordinary skill in the art will appreciate from the foregoing description of the embodiments that all or a portion of the steps of implementing the embodiments may be implemented by hardware, or may be implemented by program code related hardware, where the program may be stored in a non-volatile computer readable storage medium, where the non-volatile computer readable storage medium may be a read only memory, a magnetic disk, or an optical disk.
From the above description of embodiments, it will be apparent to those skilled in the art that the embodiments may be implemented by means of software plus a general purpose hardware platform, or may be implemented by hardware. Those skilled in the art will appreciate that all or part of the processes implementing the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, and the program may be stored in a non-volatile computer readable storage medium, and the program may include processes of the embodiments of the methods as above when executed. The non-volatile computer readable storage medium may be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), or the like.
It should finally be noted that the above embodiments are only intended to illustrate the technical solution of the present application and not to limit it, that the technical features of the above embodiments or of the different embodiments may be combined in any order, and that many other variations in the different aspects of the present application as described above exist, which are not provided in details for the sake of brevity, and that although the application has been described in the detailed description with reference to the foregoing embodiments, it should be understood by those skilled in the art that it may still make modifications to the technical solution described in the foregoing embodiments or equivalent to some of the technical features thereof, where these modifications or substitutions do not depart from the essence of the corresponding technical solution from the scope of the technical solution of the embodiments of the present application.