Detailed Description
The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
It should be noted that the terms "first," "second," and the like in the description and the claims of the present invention and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the invention described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
The chip verification method is to randomly select excitation to carry out expected maximized verification coverage on the excitation range according to the excitation constraint range of the verification object when all the excitation ranges cannot be traversed so as to find out deeper design defects. All cases are compiled together, the reloading of the constraint of the parent class in one case affects other cases, and the reloading of the same constraint in a plurality of cases can conflict and mutually cover and cannot be used. All constraints are concentrated in the same base class and reused to multiple modules or scenarios, resulting in geometrically increasing constraint complexity and even conflicting. If generated using an automated approach, writing constraints can be very difficult to implement, and even maintenance and iteration of the implementation, given the context of the various constraints that are considered in the automated process. In order to solve the above-mentioned problems, an embodiment of the present invention proposes a chip verification method for achieving uniformly distributed excitation, which can be applied to a server side executing a program.
Fig. 1 shows a flowchart of a chip verification method 100 according to an exemplary embodiment of the invention, according to an exemplary embodiment of the invention. The chip verification method is applicable to the scene of chip verification. The method may be performed by a chip authentication device, which may be implemented in hardware and/or software, and may be generally integrated in a system such as a computer having data computing capabilities, including:
step 102: a first stimulus class is generated, i.e. a first stimulus class is generated that contains all globally generic constraint terms.
In some exemplary embodiments of the present invention, the first stimulus class finds a globally generic constraint, and all verification modules using this stimulus should be compatible. These random constraints are then implemented in the global base class, such as: the constraint data amount is greater than 0, and the data types comprise INT8, INT4, FP32, FP16 and FP8. Additionally, for constraints where abnormal excitation may occur, the constraint may be formulated using soft keywords, such as: the constraint data size is greater than 0, but in an abnormal situation, an excitation with data size equal to 0 needs to be issued. At this time, the constraint data amount by soft is larger than 0, and the constraint data amount is equal to 0 in the abnormal test case; eventually, the stimulus will be generated with a data amount equal to 0 and no errors will be compiled.
In some exemplary embodiments of the present invention, an automated approach may be used to generate global base classes, with automatic generation of classes and random constraints therein being accomplished through Excel, python, TCL or the like tools.
Step 104: generating a second excitation class, namely dividing the first excitation class based on each module of the tested chip, generating the corresponding second excitation class, so that the second excitation class aiming at a specific module in the modules comprises a global general constraint item for the specific module, and expanding part or all of the global general constraint items in the specific module.
In some exemplary embodiments of the present invention, modules should be reusable in their verification. And then expanding the global base class to realize the module base class. And then in the module base class, the general constraint of the module level is realized. For example, the maximum data size that module a can process is 2048, and the data type only supports FP16. The data size is less than or equal to 2048 and a data type FP16 is a module level generic constraint for the module. Soft constraints may also be planned for a particular scenario. The constraint implementation method can be to write a constraint, and randomly constraint is carried out in the constraint; in this way, constraints on the same variables must be compatible, if a new constraint is to be generated that conflicts with an upper constraint, such as an exception scene, the upper constraint is required to be constrained by soft, otherwise a fault may be compiled. The method of implementing the constraint may also be a reload_random or pre_random function, in which the control of the variables is implemented. Since post_random and pre_random are functions. Thus, implementing random writing can be more complex than writing in constraint. In addition, the execution sequence is fixed, and post_random is operated after constraint is random. pre_random is an operation performed before constraint and it is necessary to avoid that random results are overridden. Further, the validation position is fixed and a syntax such as the software before cannot be used to control the random order between the different variables.
In some exemplary embodiments of the present invention, a module-specific random variable may be added to the module base class. In the verification environment of the module, the module base class is used as an operation class, and if the sequence and fifo use uvm _sequence_item as pointers of the delivery class, the data type is required to be forcedly converted by using a $cast command at a use position, such as rm, and then used.
Step 106: a third stimulus class is generated, i.e., a test case template is generated based on the second stimulus class of the particular module, and a constraint file of the stimulus is input based on the constraint term, and the third stimulus class is generated. The third excitation class includes: and for any function coverage point, filling the item to be filled corresponding to the input excitation in the test case template based on constraint information of the input excitation extracted from the constraint file, so as to obtain the test case corresponding to the function coverage point.
FIG. 2 illustrates a flowchart of a method 200 of generating a first incentive class comprising all globally unique constraint items in accordance with an exemplary embodiment of the present invention. The method comprises the following steps: as shown in block 202, a preset functional coverage point plan of a chip to be tested is obtained; extracting the function coverage points and constraint items corresponding to the function coverage points in the function coverage point schedule as shown in a block 204; and, as indicated by the block 204, the global generic functional coverage points and the constraint terms corresponding to each functional coverage point are filtered out.
In some exemplary embodiments of the present invention, the functional coverage point refers to a verification point designed by an IC chip designer to verify a chip function (feature) during the design process of a chip under test, and determines that the basic function of the chip has been implemented. In the development process of the chip, a designer can acquire the information from a preset functional coverage point plan. Optionally, a designer may first obtain a preset functional coverage point plan of the tested chip, and extract all functional coverage points in the functional coverage point plan and input excitation corresponding to each functional coverage point; and extracting constraint information of the input excitation from the constraint file for any functional coverage point. The functional coverage point plan can be formulated by a verifier according to a chip design specification provided by a chip designer. During manufacturing, a design characteristic list can be analyzed and arranged according to the design specification, and then a functional coverage point plan is formulated according to the design characteristic list. In particular, an item in the list of chip characteristics may be a characteristic that embodies the function of the chip, such as a characteristic of the chip having logical operations such as "and", "or", "not", "same or", etc., then the characteristic may embody the function of the chip as a logical operation function. Based on the chip characteristic list, each item can be formulated as a functional coverage point, and then corresponding input excitation is formulated for each functional coverage point, so that the functional coverage point planning is obtained.
In some exemplary embodiments of the present invention, test case templates are pre-written for the verifier, since in the chip verification process, it is often necessary to define input stimuli, i.e., define input values and input interfaces. Therefore, the basic framework of the test case template can adopt the same framework, and then the items to be filled are set for filling when the test case is generated subsequently. Specifically, for any functional coverage point, filling items to be filled corresponding to input excitation in the test case template based on constraint information to obtain a test case corresponding to the functional coverage point. When a test case corresponding to any function coverage point is generated, firstly determining input excitation required by the function coverage point, wherein the input excitation is the excitation signal type required to be input and a corresponding input interface, and then extracting constraint information of the input excitation from a constraint file. The constraint information can indicate the specific contents that the excitation signal is viable according to the kind of the excitation signal. Therefore, the method can fill the items to be filled corresponding to the input excitation in the test case template based on the constraint information. When the type of the excitation signal is a numerical value type, the constraint file constrains a numerical value range, and a plurality of numerical values can be randomly generated in the numerical value range to serve as specific contents of the excitation signal.
Step 108: and generating test codes, namely generating the test codes of the functional coverage points based on the test cases.
In some exemplary embodiments of the present invention, generating test code for a functional coverage point based on the test case includes: acquiring the test cases, and adding the test cases into a preset set to obtain a test sequence set; based on the test sequence set, determining input signals of the tested chip interfaces corresponding to each test case; and inputting the input signal to the input end of the tested chip to finish the test of the tested chip.
As an exemplary embodiment, pseudo code is shown below:
there is a data base class tr_base containing a variable 4bit vld,8bit data_q queue. Implementing constraint c_base { vld >0 in c_base; soft data_q.size >0; }
Excitation base class of module A
class tr_mA_base extensions tr_base. Wherein constraint c_a_base { vld [0] = 1 is implemented; data_q.size dist {1:/1, [2:1518]:/1,2048:/1}; }
In use case 1 of module a, constraints are implemented by expanding the excitation class.
class tr_ma_tc1_base extensions tr_ma_base; wherein the constraint tc_a_tc1{ data_q.size <64 is implemented; }
In the build_phase of tc, the factor_type_override_by_type (tr_mA_base:: get_type ()), tr_mA_tc1_base::: get_type ());
thereby completing the constraint, the finally issued excitation constraint is { vld [0] = 1; data_q.size >0; data_q.size <64; data_q.size dist {1:/1, [2:63]:/1}; }
One possible embodiment is that in use case 2 of module a, the constraint is implemented using a sequence approach. seq_mA_tc2extensions uvm_sequence; constraints are then implemented on the body functions therein
uvm_do_with(item,{item.vld[1]＝＝1；item.data_q.size＝＝1518；})
Then in use case, instantiate the sequence and use start to generate stimulus: seq_ma_tc2m_seq; m_seq=new (); m_seq.start (tc_sqr);
an alternative embodiment is that the base class of module B extends from tr_base. class tr_mb_base extensions tr_base; function void post _random (); code is implemented in the function:
foreach (data_q [ i ]) data_q [ i ] =8' hff; the use case of the module B does not reload constraint, and finally the excitation constraint sent out is { item.vld >0; item.data_q.size >0; and all data in data_q is 8' hff.
In some exemplary embodiments of the present invention, the constraint item input excitation constraint file includes at least: the boundary of the current test scenario for a particular module inputs constraint information for the stimulus. For example: the scene of the longest data stream is verified, and the constraint data amount is equal to 2048 in the use case. The final constraint is the sum of three layers of constraints, the stimulus produced is the data amount equal to 2048 and the data type is FP16.
In some exemplary embodiments of the present invention, the use case incentive class may be obtained in the form of an extension module base class, and then constraints are implemented in the use case incentive class using either constraint or post_random. This approach does not modify the trigger-excited sequence and is compatible with environments that do not use sequences. However, since the final class needs to be replaced, an override instruction is required for use case, and the use case excitation class is copied to the module base class, that is, the module base class name is kept unchanged, and the content is changed to the content of the use case excitation class. Because class names are unique, the name of each use case incentive class must be unique. In some exemplary embodiments, one way of optimizing a use case incentive class may be to define the name of the use case incentive class using a macro definition with parameters. By using the case name as a parameter, the name of the case excitation class can be generated in the same format. Each use case only uses the control use case name, and the name of the corresponding use case excitation class is automatically controlled.
In some exemplary embodiments of the invention, the method further comprises: detecting an input signal of an input end of the chip to be tested and an output signal of an output end of the chip to be tested; predicting output according to the input signal by using a preset result prediction component to obtain a predicted output signal; comparing whether the predicted output signal and the output signal are matched or not, and carrying out error warning under the condition of no match.
In some exemplary embodiments of the invention, the first stimulus class includes: a chip version constraint item, a current test scene constraint item and a register configuration constraint item of the tested chip functional point.
In some exemplary embodiments of the present invention, in expanding the constraint that is partially or fully globally generic within the specific module, the expanded constraint includes at least: user register configuration information and configuration information of non-relevant chip function points.
In some exemplary embodiments of the invention, the current test scenario constraints include: clock source, clock frequency, communication interface type, frequency and timing, supply voltage, analog signal input, and chip connection method.
Fig. 3 shows a schematic diagram of a terminal device 300 according to an exemplary embodiment of the invention. The communication terminal device 300 may include: at least one processor 302; and at least one memory 304 including computer program code, the at least one memory 304 and the computer program code 306 configured to, with the at least one processor 302, cause the communication terminal device 300 to perform: the terminal device may implement the steps of the chip authentication method in the above embodiment of the present invention.
The invention also discloses a computer readable storage medium storing a computer program, which can implement the steps of the chip verification method in the above embodiment of the invention.
The invention also discloses an electronic device, comprising: a memory for storing a computer program product; a processor for executing the computer program product stored in the memory, and when the computer program product is executed, the electronic device can implement the steps of the chip verification method in the above embodiment of the present invention.
The processor may be a CPU or other form of processing unit having data processing and/or instruction execution capabilities, and may control other components in the electronic device to perform the desired functions.
The memory may include one or more computer program products that may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory. The volatile memory may include, for example, random Access Memory (RAM) and/or cache memory (cache), and the like. The non-volatile memory may include, for example, read Only Memory (ROM), hard disk, flash memory, and the like. One or more computer program instructions may be stored on the computer readable storage medium that can be executed by a processor to implement the task generating methods and/or other desired functions of the various embodiments of the present invention described above.
In one example, the electronic device may further include: input devices and output devices, which are interconnected by a bus system and/or other forms of connection mechanisms (not shown).
In addition, the input device may include, for example, a keyboard, a mouse, and the like.
The output device may output various information including the determined distance information, direction information, etc., to the outside. The output devices may include, for example, a display, speakers, a printer, and a communication network and remote output devices connected thereto, etc.
Of course, the present invention shows only some of the components of the electronic device that are relevant to the present invention, omitting components such as buses, input/output interfaces, etc., for simplicity. In addition, the electronic device may include any other suitable components depending on the particular application.
In addition to the methods and apparatus described above, embodiments of the invention may also be computer program products comprising computer program instructions which, when executed by a processor, cause the processor to perform steps in a task generating method according to various embodiments of the invention described in the above section of the specification.
In the foregoing embodiments of the present invention, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.
In several embodiments provided by the present invention, it should be understood that the disclosed client may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and are merely a logical functional division, and there may be other manners of dividing the apparatus in actual implementation, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution provided in the present embodiment.
In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
Furthermore, embodiments of the present invention may also be a computer-readable storage medium, on which computer program instructions are stored, which, when being executed by a processor, cause the processor to perform the steps in a task generating method according to various embodiments of the present invention described in the above section of the present specification.
The computer readable storage medium may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may include, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium would include the following: an electrical connection having one or more wires, a portable disk, a hard disk, random Access Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
Those of ordinary skill in the art will appreciate that: all or part of the steps for implementing the above method embodiments may be implemented by hardware associated with program instructions, where the foregoing program may be stored in a computer readable storage medium, and when executed, the program performs steps including the above method embodiments; and the aforementioned storage medium includes: various media that can store program code, such as ROM, RAM, magnetic or optical disks.
The basic principles of the present invention have been described above in connection with specific embodiments, however, it should be noted that the advantages, benefits, effects, etc. mentioned in the present invention are merely examples and not intended to be limiting, and these advantages, benefits, effects, etc. are not to be considered as essential to the various embodiments of the present invention. Furthermore, the specific details disclosed herein are for purposes of illustration and understanding only, and are not intended to be limiting, as the invention is not necessarily limited to practice with the above described specific details.
The above description is only of the preferred embodiments of the present invention and is not intended to limit the present invention, but various modifications and variations can be made to the present invention by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.