CN119026534A

CN119026534A - SoC test case generation method, device, host and program

Info

Publication number: CN119026534A
Application number: CN202411101716.0A
Authority: CN
Inventors: 张意奇
Original assignee: Shenzhen Aowei Lingxin Technology Co ltd
Current assignee: Shenzhen Aowei Lingxin Technology Co ltd
Priority date: 2024-08-12
Filing date: 2024-08-12
Publication date: 2024-11-26

Abstract

The present invention provides a test case generation method, device, host and program for SoC, wherein the SoC includes at least one digital IP, and the test case method of the SoC includes: obtaining test requirement data, the test requirement data includes at least one digital IP, and at least one test item corresponding to the digital IP; decomposing the test requirement data to form multiple alternative test data, and storing them in a preset database; selecting the digital IP and test items corresponding to the target digital IP from the preset database, and storing them in a verification template; based on the test case script, by calling the verification template, generating a test case corresponding to the target digital IP. The above technical solution can improve the generation efficiency and accuracy of test cases.

Description

SoC test case generation method, device, host and program

Technical Field

Embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method, an apparatus, a host, and a program for generating a test case of an SoC.

Background

With the rapid development of computer technology, a System on Chip (System on Chip) requires a large and reliable digital IP for functional expansion. In these digital IPs, the digital IP functions required to be used are mostly different due to different usage requirements and different usage scenarios required by customers.

With the advanced high integration and miniaturization of modern chips, the number of digital IPs required by the system on chip is also increasing, and for the reliability of the system on chip, the manpower and resources required for verifying the digital IPs are also increasing, for example, a system on chip needs a plurality of scenes of the same or different digital IPs, and more test cases are required.

However, the method for manually completing the test case increases the probability of error occurrence and has low efficiency.

Disclosure of Invention

Aiming at the technical problems, the embodiment of the specification provides a method, a device, a host and a program for generating a test case of an SoC, which can improve the generation efficiency and the accuracy of the test case.

The embodiment of the specification provides a test case generation method of a SoC, wherein the SoC comprises at least one digital IP, and the test case generation method of the SoC comprises the following steps:

Acquiring test requirement data, wherein the test requirement data comprises at least one digital IP and at least one test item corresponding to the digital IP;

Decomposing the test requirement data to form a plurality of alternative test data, and storing the plurality of alternative test data into a preset database;

selecting a digital IP and a test item corresponding to the target digital IP from the preset database, and storing the digital IP and the test item into a verification template;

based on the test case script, generating the test case corresponding to the target digital IP by calling the verification template.

Optionally, the decomposing the test requirement data to form a plurality of candidate test data, and storing the candidate test data in a preset database includes:

Decomposing the test requirement data by adopting a preset test dimension to obtain alternative test data of each test dimension, wherein the test dimension comprises: at least one of a clock dimension, a reset dimension, an interface dimension, a function dimension, and a performance dimension;

And converting the alternative test data of each test dimension according to the data format set by the preset database, and storing the converted alternative test data into the preset database.

Optionally, when the test dimension includes a clock dimension, generating at least one alternative clock test data by calling a user manual and an explanation document of the digital IP, and a frequency of at least one of the alternative clock test data corresponds to the digital IP;

When the test dimension comprises a reset dimension, carrying out repeated reset decomposition on the test demand data to generate a plurality of alternative reset test data, wherein the reset time of each alternative reset test data is different, alternative reset test signals with different reset types exist in the plurality of alternative reset test data, and the reset sequence of the plurality of alternative reset test data is different in each reset decomposition operation;

When the test dimension comprises an interface dimension, generating a plurality of alternative transaction level test data by initiating a transmission request to an interface of the digital IP, wherein delay exists among the alternative transaction level test data;

Generating alternative evaluation data based on the data transmission speed requirement in the unit length of the digital IP when the test dimension comprises a performance dimension;

When the test dimension includes a functional dimension, alternative constraint data for registers of the digital IP is generated based on a test item type of the digital IP.

Optionally, the verification template includes a plurality of sub-verification templates, and one sub-verification template corresponds to one test dimension;

The step of selecting the digital IP and the test item corresponding to the target digital IP from the preset database and storing the digital IP and the test item in a verification template comprises the following steps:

And selecting target test data from a plurality of candidate test data based on the use times of the target digital IP, the test dimensions to be executed for each use time and the test quantity required by each test dimension, and storing the target test data at a preset position of a sub-verification template corresponding to the test dimensions.

Optionally, the acquiring test requirement data includes:

Acquiring the test requirement data in the test process of the SoC;

according to the test requirement of the SoC, the test requirement data are acquired at regular time;

And manually acquiring the test requirement data by a verification engineer.

Optionally, the step of generating the test case corresponding to the target digital IP by calling the verification template based on the test case script further includes:

And checking information configured in the test case script, and/or detecting whether a verification template exists in a call path of the test case script.

Optionally, the method for generating the test case of the SoC further includes: and testing the SoC by adopting the test case.

The embodiment of the specification also provides a test case generating device of the SoC, which comprises:

the SoC includes at least one digital IP, and the test case generating device of the SoC includes:

The data acquisition unit is suitable for acquiring test requirement data, wherein the test requirement data comprises at least one digital IP and at least one test item corresponding to the digital IP;

The decomposing unit is suitable for decomposing the test requirement data to form a plurality of alternative test data, and storing the plurality of alternative test data into a preset database;

The storage unit is suitable for selecting a digital IP and a test item corresponding to the target digital IP from the plurality of alternative test data and storing the digital IP and the test item into the verification template;

and the processing unit is suitable for generating the test case corresponding to the target digital IP by calling the verification template based on the test case script.

The embodiment of the present specification also provides a host, including: at least one processor and at least one memory storing one or more computer-executable instructions that the processor invokes to perform the test case generation method of the SoC of any of the preceding claims.

Embodiments of the present specification also provide a computer program product comprising computer instructions which, when executed by a processor, implement a test case generation method of the SoC of any of the preceding claims.

By adopting the test case generation method of the SoC provided by the embodiment of the specification, on one hand, a plurality of alternative test data can be formed by decomposing the test requirement data so as to meet the test requirement of the digital IP, and the follow-up selection operation is facilitated by storing the plurality of alternative test data into a preset database; on the other hand, the digital IP and the test items corresponding to the target digital IP are selected from the plurality of alternative test data, the current test requirement of the digital IP can be met, the current test requirement of the digital IP can be determined by executing the operation stored in the verification template, and further, the test case corresponding to the target digital IP is generated by calling the verification template based on the test case script without manual processing, so that the generation efficiency and the accuracy of the test case can be improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings can be obtained according to the provided drawings without inventive effort for a person skilled in the art.

FIG. 1 shows a flowchart of a test case generation method for a SoC in an embodiment of the present disclosure;

FIG. 2 is a flow chart illustrating the processing of alternative test data in an embodiment of the present disclosure;

Fig. 3 is a schematic diagram showing a configuration of a test case generating device of an SoC in the embodiment of the present disclosure.

Detailed Description

As described in the background art, in order to make a complete test plan to achieve complete verification convergence, more and more test cases are required, and a system on a chip requires multiple scenes of the same or different digital IPs, so that a great deal of text processing work is generated. The test case is manufactured manually, so that the probability of error occurrence is increased, and the generation and risk of verification loopholes are increased.

In order to solve the technical problems, a method can be introduced to generate corresponding test cases for the specified number of digital IPs and the number of test cases according to the general digital IP characteristics focused by the verification engineer and the requirements and work targets when the verification convergence is completed, so as to reduce the corresponding verification convergence risk and invalid text processing work.

More specifically, the embodiments of the present disclosure provide a method for generating a test case of an SoC, on the one hand, by decomposing test requirement data, a plurality of candidate test data can be formed to satisfy a test requirement of a digital IP, and by storing the plurality of candidate test data into a preset database, a subsequent selection operation is facilitated; on the other hand, the digital IP and the test items corresponding to the target digital IP are selected from the plurality of alternative test data, the current test requirement of the digital IP can be met, the current test requirement of the digital IP can be determined by executing the operation stored in the verification template, and further, the test case corresponding to the target digital IP is generated by calling the verification template based on the test case script without manual processing, so that the generation efficiency and the accuracy of the test case can be improved.

In order to enable those skilled in the art to better understand the inventive concepts, working principles and advantages of the embodiments of the present specification, a test case generation scheme of the SoC in the embodiments of the present specification is described in detail below.

Referring to a flowchart of a test case generation method of an SoC in the embodiment of the present specification shown in fig. 1, in some embodiments of the present specification, the SoC includes at least one digital IP.

The digital IP may refer to a pre-designed and verified digital circuit module used in SoC design, among other things.

In this embodiment, the SoC may include one digital IP, or include a plurality of digital IPs. The present embodiment does not limit the number of digital IPs as long as there are digital IPs in the SoC.

In this case, as shown in fig. 1, specifically, the test case may be generated as follows:

s11, acquiring test requirement data.

In a specific implementation, the test requirement data may refer to data that satisfies the SoC test requirement, which can satisfy performing various tests on the SoC to detect whether the SoC can satisfy the design requirement. By obtaining test requirement data, it is possible to verify all performance requirements of the SoC, as well as performance requirements for a particular process.

For example, the test requirement data may test input functions, data processing functions, etc. of the SoC.

In a specific implementation, the test requirement data may include at least one digital IP, and at least one test item corresponding to the digital IP.

In some alternative examples, the test items of the digital IP may include the number of test cases, the test cases required for each test case (i.e., the operating scenarios required for the digital IP).

In some embodiments, the test requirement data may exist in the form of key-value pairs.

S12, decomposing the test requirement data to form a plurality of alternative test data, and storing the plurality of alternative test data in a preset database.

In a specific implementation, the test requirement data includes test requirements of different digital IPs with different dimensions, and the different digital IPs have respective characteristics, and the required test requirements are not identical, so that the test requirement data can be decomposed, so that a plurality of candidate test data can be formed. Since the plurality of candidate test data can cover the test requirements of all the data IPs, the plurality of candidate test data can satisfy the test requirements of any one digital IP in the SoC.

And the plurality of alternative test data are stored in the preset database, so that the subsequent selection operation is convenient, and the decomposition operation is not needed for any specific digital IP, thereby being capable of reducing the test case generation time.

In an implementation, the preset database may be located in a local server or may be located in a cloud server, and the location of the preset database is not limited in this embodiment of the present disclosure, so long as the preset database can store alternative test data.

As an alternative example, the preset database may be one or more of a distributed database, a data warehouse, a JavaScript object notation (JavaScript Object Notation, JSON) database, and the like.

S13, selecting the digital IP and the test item corresponding to the target digital IP from the preset database, and storing the digital IP and the test item in a verification template.

In a specific implementation, the preset database stores a plurality of candidate test data, and the candidate test data reflects all test data of the SoC, and characteristics of different digital IPs are different, so that a digital IP corresponding to a target digital IP (which may be understood as a digital IP to be subjected to a performance test at this time) and a test item of the digital IP after decomposition may be selected from the plurality of candidate test data to be stored in the verification template.

In some embodiments, the verification template may be used as the alternative test data, and the running environment of the test case generated based on the alternative test data.

S14, based on the test case script, generating the test case corresponding to the target digital IP by calling the verification template.

The test case script refers to a set of automation scripts for executing test case generation, and can be applied to the test of the SoC.

In specific implementation, the test case script can automatically call the verification template, and based on the data stored in the verification template, the test case corresponding to the target digital IP is generated according to logic of the test case script, so that the generation efficiency of the test case can be improved.

Therefore, by adopting the embodiment, on one hand, a plurality of alternative test data can be formed by decomposing the test requirement data so as to meet the test requirement of the digital IP, and the follow-up selection operation is facilitated by storing the plurality of alternative test data into the preset database; on the other hand, the digital IP and the test items corresponding to the target digital IP are selected from the plurality of alternative test data, the current test requirement of the digital IP can be met, the current test requirement of the digital IP can be determined by executing the operation stored in the verification template, and further, the test case corresponding to the target digital IP is generated by calling the verification template based on the test case script without manual processing, so that the generation efficiency and the accuracy of the test case can be improved. For a better understanding and implementation of the embodiments of the present description, those skilled in the art will now make a detailed description, with reference to the accompanying drawings, by way of specific examples.

First, in implementations, the test requirement data may be obtained in a variety of ways.

For example, in the test process of the SoC, the test requirement data is acquired. Namely, a tester performs SoC test and acquires test requirement data, so that the real-time performance of the test requirement data can be improved, and the real-time performance and accuracy of the test case generation process can be improved.

For another example, the test requirement data may be obtained periodically according to the test requirement of the SoC.

Also for example, the test requirement data is manually obtained by a verification engineer. In implementations, the test requirement data may be obtained manually by a verification engineer for network reasons, or to avoid missed transmissions.

From the above, at least one of the above three modes can be adopted to obtain the test requirement data, so that the flexibility of obtaining the test requirement data can be improved, and further, different application scenes can be applied as required.

It should be understood that the manner of acquiring the test requirement data provided in the foregoing embodiments is merely illustrative, and is only for illustrating that the test case generation using the SoC in the embodiments of the present disclosure can acquire the test requirement data in time, and is not to be construed as limiting the present invention.

For example, in some other embodiments, the tester may also obtain test requirement data according to the test result when completing the test process of one of the digital IPs of the SoC.

In a specific application, the test case generation process of multiple digital IPs may be performed simultaneously, and the formats of test requirement data used by these test cases may be different. In order to improve the consistency and reliability of the acquired test demand data, the test demand data can be decomposed conveniently. And acquiring test requirement data meeting the interface requirements through a preset communication interface.

Specifically, through presetting the communication interface, the test requirement data is obtained only when the test requirement data meets the interface requirement, otherwise, the type of the test requirement data is directly discarded or converted, illegal access can be avoided, and the test case can be obtained more efficiently according to the user requirement.

In implementations, the definition and specification of the communication interface employed may be set according to the requirements and application scenarios to facilitate testing of the requirement data.

In some alternative examples, the preset communication interface may be a Representational state transfer application program interface (Representational STATE TRANSFER API, restful API).

In other embodiments of the present disclosure, the preset communication interface may also be a simple object access protocol (Simple Object Access Protocol, SOAP) API, where the embodiment of the present disclosure does not limit the type of the communication interface, so long as test requirement data meeting the requirements of the interface can be obtained through the preset communication interface.

In some other embodiments, the test requirement data may be directly acquired without considering information such as the type of the test requirement data, the data format, and the like.

In some embodiments of the present disclosure, when the test requirement data is obtained, the test requirement data may be decomposed according to different dimensions and stored.

Referring to fig. 2, a flowchart of a process of processing alternative test data in the embodiment of the present specification, as shown in fig. 2, includes:

s21, decomposing the test requirement data by adopting preset test dimensions to obtain alternative test data of each test dimension.

In a specific implementation, for different digital IPs, when testing the digital IPs, emphasis is not exactly the same, that is, different digital IPs have different testing dimensions, so that test requirement data can be decomposed according to the set testing dimensions, so that alternative testing data can cover all testing dimensions, so as to meet test requirements of different digital IPs.

In this embodiment, the test dimensions may include: at least one of a clock dimension, a reset dimension, an interface dimension, a function dimension and a performance dimension, so that alternative test data under the 5 test dimensions can be obtained to meet the test requirements of different digital IPs.

In an alternative embodiment, the test dimensions may include both the clock dimension and the reset dimension, as well as the clock dimension, the reset dimension, the interface dimension, and so forth. The embodiment of the present specification does not impose any limitation on the type and combination of types of test dimensions, as long as the test requirement data can be decomposed.

It should be noted that, in the step of acquiring the test requirement data, the enable signal may also be acquired at the same time, so as to determine the executed test dimension based on the state of the enable signal.

More specifically, the enable signal may include: clk_en, rst_en, interface_en, perf_en and function_en. When clk_en is triggered, decomposing clock dimension of test requirement data; when rst_en is triggered, carrying out decomposition of reset dimension on test requirement data; when interface_en is triggered, decomposing the interface dimension of the test requirement data; when the perf_en is triggered, decomposing performance dimensions of the test requirement data; when function_en is triggered, the test requirement data is decomposed in the functional dimension.

In implementations, different types of test dimensions, when performing the decomposition operation, the decomposition process is different.

For example, when the test dimension includes a clock dimension, at least one alternative clock test data is generated by invoking a user manual and an instruction document (i.e., spec/databook file) of the digital IP, and the frequency of the at least one alternative clock test data corresponds to the digital IP.

Among them, spec file is used to describe the functions of digital IP, and databook file is generally used to describe the digital IP in detail.

In a specific example, the clock is essentially a periodic signal in the simulation platform, which has a period of "1" and a period of "0", and these two periods of time are typically equal or may not be equal. The clocks are divided into a plurality of signals by a pre-packaged program according to the clocks in the test requirement data when the test requirement data are acquired.

For example, the corresponding one clock is generated using the always # (clk_period) clk= -clk, where clk_period is the corresponding clock period, so that it can be packaged as underlying code logic.

Furthermore, using the gen_ip_clk (input int clk_num, iuput real clk _freq) method to call gen_clk according to the number of clocks input, it is possible to generate different clocks matching the test dimension according to different digital IPs, for example, the number and frequency of the clocks.

For example, when the test dimension includes a reset dimension, performing multiple reset decomposition on the test requirement data to generate multiple alternative reset test data, where the reset time of each alternative reset test data is different, and alternative reset test signals with different reset types exist in the multiple alternative reset test data, and in each reset decomposition operation, the reset sequence of the multiple alternative reset test data is different.

In one specific example, the parameters of the reset are derived from the databook file, specifically including synchronous reset and asynchronous reset, where synchronous reset means that the reset is triggered at an edge (e.g., rising edge) of the clock, asynchronous reset means that the reset is independent of the clock edge, and asynchronous may determine the relationship of the reset to the clock based on the synchronous reset or asynchronous reset.

In the scenario of multiple resets, since the reset sequence may have different effects on the SoC, when multiple reset decomposition is performed, the method of reset decomposition should support that each call generates a different reset sequence and type.

For example, if the reset decomposition operation is performed to generate three reset signals, there is a case where the first reset signal is a synchronous reset signal, the second reset signal and the third reset signal are asynchronous reset signals, the reset generation time is any one clock within 0 to x, x is a random value, the random values of different reset signals are different, and in the repeated operation of the test case, the reset method repeatedly called can cover the reset sequence.

First, the reason why the reset decomposition is performed plural times is that: a normally running digital IP can recover normal perception after multiple resets, so that the reset performance of the digital IP can be verified; second, the reset method may produce different reset results in each invocation of the test case due to the compiler and the random method.

For another example, when the test dimension includes an interface dimension, a transmission request is initiated through an interface to the digital IP, a plurality of alternative transaction level test data are generated with a delay between each of the alternative transaction level test data.

In a specific example, in the verification methodology, the transfer is completed by initiating the transmission of interface data in units of transaction level, which is the abstraction level of the interface, on the interface, there is a need to implement stimulus for the interface, typically several transactions, in the commonality of SoC testing, and the intervals of the individual transactions are different.

In some embodiments, the generation of the plurality of alternative transaction level test data may be accomplished by a gen_transaction (input int tr_num, input int tr_delay).

Where tr_num is the number of transactions, tr_delay is the delay of the transaction, and gen_transaction is the decomposition parameter.

For another example, when the test dimension includes a performance dimension, alternative evaluation data is generated based on a data transmission speed requirement per unit length of digital IP.

In a specific example, during data sampling, the bandwidth of data within a certain period of time may be obtained, from the perspective of a test case, one test case has different evaluation criteria about the performance of the SoC, for example, one test case needs to send out short packets all at once, pps (PACKET PER seconds) or bbs (byte per second) may be very large, one test case needs to send out long packets all at once, pps or bbs may be very small, and different test cases need different evaluation criteria.

In an alternative example, alternative evaluation data may be generated by perf_analysis (input int type, input int max, input int min) to define upper and lower limits of performance.

For another example, when the test dimension includes a functional dimension, alternative constraint data for registers of the digital IP is generated based on test item types of the digital IP.

In one specific example, the register configuration of the SoC is typically stored in a class or data structure, deposited in the ral (register abstraction layer ). However, the constraints of different test cases on the registers are different, for example, if one ip has only three registers (Int a, int b and Int c) to be configured, the configuration of the registers meeting the test case requirement can be randomly generated after each invocation of gen_cfg through gen_cfg (input ral, output ral).

In the constraint configuration, a randomized function in class is called each time the register configuration is generated, and a specific value is required to generate a specific value, and the randomized value is not required to exist in the specific value.

S22, converting the alternative test data of each test dimension according to the data format set by the preset database, and storing the converted alternative test data into the preset database.

In a specific implementation, the candidate test data of each test dimension may be converted according to a data format set in the preset database and then stored in the preset database. By converting the format of the alternative test data, the consistency of the format of the alternative test data can be improved, the management and the generation operation are convenient, the downtime problem caused by the abnormal format of the alternative test data can be avoided, and the reliability and the stability of the test case generation process are improved.

In some alternative examples, during the data format conversion process, an exception error handling process may be added to process alternative test data (e.g., alternative test data is a null pointer) with some format exceptions, so as to further improve the stability of the test case generating method.

In some embodiments, the structural form of the database may be predefined so as to facilitate the conversion of the data format of the alternative test data, so that the database may store the alternative test data in a structured manner, that is, may store the alternative test data of the corresponding attribute through a plurality of different fields, respectively.

In some embodiments of the present disclosure, when decomposing test requirement data through a preset test dimension, the verification template may include a plurality of sub-verification templates, and one sub-verification template corresponds to one test dimension, that is, alternative test data under the corresponding test dimension is stored through different sub-verification templates, so that data stored by different sub-verification templates can be obtained in parallel, and further, generation efficiency of test cases is improved.

In this case, the step of selecting the digital IP and the test item corresponding to the target digital IP from the preset database and storing the digital IP and the test item in the verification template includes: and selecting target test data from a plurality of candidate test data based on the use times of the target digital IP, the test dimensions to be executed for each use time and the test quantity required by each test dimension, and storing the target test data at a preset position of a sub-verification template corresponding to the test dimensions.

Specifically, after decomposing the test requirement data according to the preset test dimensions, the verification engineer can determine the type of the processed digital IP, the number of times of use of each digital IP, and according to the use case examples, determine the test dimensions required by each digital IP and the number of test cases required to be generated in each test dimension, so as to determine the functions implemented by the test case script in sequence.

In some alternative embodiments, the target test data may be stored to a preset location of the sub-verification template by a key index to enable the output filling operation.

For example, one function in one sub-verification template is named as gen_transaction (), the universal code is aaa, and the code to be replaced is aaa, and the function at this time cannot be tested for the characteristic of the current digital IP, and at this time, the verification code for the current digital IP is written through the keyword index to replace the code to be replaced, so as to complete the test work for the characteristic of the current digital IP.

In some embodiments, there may be no data in the sub-verification template or the data stored in the sub-verification template is data of other sub-verification templates, so that the test cases of the required test dimension cannot or are not completely generated when the sub-verification template is called.

Based on this, before the verification template is called, whether the sub-verification template has data or not and the matching between the data and the sub-verification template can also be verified.

By adopting the test case generation method of the SoC in the example, the test requirement data can be decomposed in at least one dimension of a clock dimension, a reset dimension, an interface dimension, a function dimension and a performance dimension, the target test data of the target digital IP can be stored based on the verification template, and then the test case corresponding to the target digital IP can be generated by calling the verification template.

In some embodiments of the present disclosure, in the step of generating the test case corresponding to the target digital IP by calling the verification template based on the test case script, the test case generation method of the SoC may further include: and checking information configured in the test case script, and/or detecting whether a verification template exists in a call path of the test case script so as to improve the accuracy of test case generation.

For example, clock information, reset information and the like in information configured in the test case script are checked, and if the corresponding configuration information is missing in the test case script, the current test case generation process is stopped or the test case script is modified.

For example, if the verification template does not exist in the call path of the test case script, the required test case information of the target IP cannot be obtained, and thus the test case cannot be generated.

When the steps are executed, when the abnormality of the test case script is detected, corresponding alarm information is generated, and the safety and user interaction experience of the test case generation scheme are improved.

In some embodiments of the present disclosure, when determining that the configuration information of the test case script is normal, the generated test case may include: the number of test cases of the target digital IP, the number of test cases of each test case and the verification environment.

Namely: the test case script is used for providing a verification environment used by the test case.

For example, if there are three test cases in a target digital IP, where the first test case needs seven test cases, the second test case needs nine test cases, the third test case needs eleven test cases, after the test case script is run, 7+9+11=27 test cases and the verification environment corresponding to the three cases can be generated.

Where the verification environment specifies when and where clocks are generated, when and where configuration is completed, and when and where generation and driving of stimulus is completed and when and where performance comparisons and evaluations are completed.

More specifically, the framework of the verification environment is fixed, for example, the generation clock is reset at the top level of the verification environment, the data required for generating the use cases is set at build_phase, the configuration is set at configuration_phase, the stimulus is sent at main_phase, and the performance evaluation is completed in report.

In the embodiment of the specification, after the test case is generated by calling the verification template based on the test case script, the test case can be adopted to test the SoC.

Briefly, in the scheme in the embodiment of the disclosure, test requirement data is decomposed based on five dimensions of clock, reset, interface, function and performance, and is stored in a database; then, based on the self-test requirement input by the verification engineer, selecting data meeting the current digital IP test from the database, and filling the data into the blank of the verification template; finally, the script calls the verification template to generate the test case and the verification environment, wherein the verification environment body can be regarded as a folder, the code with the hierarchical level inside is formed and packaged into a software package (such as the verification template), and the software package is automatically generated after the script is called, so that the verification environment is generated.

The present specification also provides a test case generating device of an SoC corresponding to the test case generating method of an SoC, and detailed description will be given below with reference to the accompanying drawings by way of specific embodiments.

Referring to fig. 3, a schematic structural diagram of a test case generating device of an SoC in an embodiment of the present disclosure, in some embodiments of the present disclosure, the SoC includes at least one digital IP.

In this case, as shown in fig. 3, the test case generating apparatus 100 of the SoC may include:

A data acquisition unit 110, adapted to acquire test requirement data, where the test requirement data includes at least one digital IP and at least one test item corresponding to the digital IP;

The decomposition unit 120 is adapted to decompose the test requirement data to form a plurality of candidate test data, and store the candidate test data in a preset database;

A storage unit 130, adapted to select a digital IP and a test item corresponding to the target digital IP from the plurality of candidate test data, and store the digital IP and the test item in a verification template;

The processing unit 140 is adapted to generate a test case corresponding to the target digital IP by calling the verification template based on a test case script.

It should be understood that the above division of each unit is only a division of a logic function, and may be fully or partially integrated into a physical entity or may be physically separated when actually implemented. Furthermore, the above units may be implemented in the form of processor-invoked software.

By adopting the SoC test case generating device 100, on one hand, the decomposing unit 120 decomposes the test requirement data to form a plurality of candidate test data so as to meet the test requirement of the digital IP, and the plurality of candidate test data are stored in the preset database, so that the subsequent selection operation is facilitated; on the other hand, the processing unit 140 selects the digital IP and the test item corresponding to the target digital IP from the plurality of candidate test data, so that the current test requirement of the digital IP can be met, and the current test requirement of the digital IP can be determined by executing the operation stored in the verification template, and further, the processing unit 140 can generate the test case corresponding to the target digital IP by calling the verification template based on the test case script without manual processing, so that the generation efficiency and accuracy of the test case can be improved.

For better understanding and implementation by those skilled in the art, specific implementation examples of the data acquisition unit, the decomposition unit, the storage unit and the processing unit are described below, respectively.

In some embodiments of the present description, the data acquisition unit may acquire the test requirement data in a variety of ways.

For example, the data acquisition unit may acquire the test requirement data during a test of the SoC. Namely, a tester performs SoC test and acquires test requirement data, so that the real-time performance of the test requirement data can be improved, and the real-time performance and accuracy of the test case generation process can be improved. For another example, the data acquiring unit may acquire the test requirement data periodically according to the test requirement of the SoC. Therefore, the flexibility of test requirement data acquisition can be improved, and different application scenes can be applied according to the requirements.

In a specific application, the test case generation process of multiple digital IPs may be performed simultaneously, and the formats of test requirement data used by these test cases may be different. In order to improve the consistency and reliability of the acquired test demand data, the test demand data can be decomposed conveniently. The data acquisition unit can acquire test requirement data meeting the interface requirements through a preset communication interface.

In some optional examples, the preset communication interface may be a Restful API or a SOAP API, and the embodiment of the present disclosure does not limit the type of the communication interface, so long as test requirement data meeting the interface requirement can be obtained through the preset communication interface.

In some embodiments of the present disclosure, when the test requirement data is obtained, the decomposition unit may decompose the test requirement data according to different dimensions and store the test requirement data.

In some embodiments, the test dimension may include: at least one of a clock dimension, a reset dimension, an interface dimension, a function dimension and a performance dimension, so that alternative test data under the 5 test dimensions can be obtained to meet the test requirements of different digital IPs.

The operation of decomposing the test requirement data by adopting the preset test dimension can be referred to as an example.

And the decomposition unit can convert the alternative test data of each test dimension according to the data format set by the preset database and store the converted alternative test data into the preset database. By converting the format of the alternative test data, the consistency of the format of the alternative test data can be improved, the management and the generation operation are convenient, the downtime problem caused by the abnormal format of the alternative test data can be avoided, and the reliability and the stability of the test case generation process are improved.

In implementations, the storage unit may include any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and/or storage unit. Such as memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, compact Disk Read Only Memory (CDROM), compact disk recordable (CD-R), compact disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disks (DVDs), a tape, a cassette, or the like.

In some embodiments, the data store may employ MySQL for storage.

In some embodiments of the present disclosure, in the step of generating the test case corresponding to the target digital IP by calling the verification template based on the test case script, the processing unit may further: and checking information configured in the test case script, and/or detecting whether a verification template exists in a call path of the test case script so as to improve the accuracy of test case generation.

For example, clock information, reset information and the like in information configured in the test case script are checked, and if the corresponding configuration information is missing in the test case script, the processing unit stops executing the current test case generation process or modifies the test case script.

In some alternative examples, after generating the test case by calling the verification template based on the test case script, the processing unit may also test the SoC using the test case.

The present specification embodiment also provides a host adapted to be used to implement the test case generating method of the SoC, wherein the host includes a central processing unit (Central Processing Unit, CPU) that can perform various appropriate actions and processes, such as performing the method described in the above embodiment, according to a program stored in a Read-Only Memory (ROM) or a program loaded from a storage portion into a random access Memory (Random Access Memory, RAM). In the RAM, various programs and data required for the system operation are also stored. The CPU, ROM and RAM are connected to each other by a bus. An Input/Output (I/O) interface is also connected to the bus.

The following components are connected to the I/O interface: an input section including a keyboard, a mouse, etc.; an output section including a Cathode Ray Tube (CRT), a Liquid crystal display (Liquid CRYSTAL DISPLAY, LCD), and a speaker; a storage section including a hard disk or the like; and a communication section including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section performs communication processing via a network such as the internet. The driver 310 is also connected to the I/O interface as needed. Removable media such as magnetic disks, optical disks, magneto-optical disks, semiconductor memories, and the like are mounted on the drive as needed so that a computer program read therefrom is mounted into the storage section as needed.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such embodiments, the computer program may be downloaded and installed from a network via a communication portion, and/or installed from a removable medium. When being executed by a Central Processing Unit (CPU), performs the various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but 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 of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), a flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present invention may be implemented by software, or may be implemented by hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

According to one aspect of the present application, there is provided a computer program product or computer program comprising computer instructions stored in a computer readable storage medium. The computer instructions are read from the computer-readable storage medium by a processor of a computer device, and executed by the processor, cause the computer device to perform the methods provided in the various alternative implementations described above.

As another aspect, the present application also provides a computer-readable medium that may be contained in the electronic device described in the above embodiment; or may exist alone without being incorporated into the electronic device. The computer-readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to implement the methods described in the above embodiments.

It should be noted that although in the above detailed description several modules or units of a device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functions of two or more modules or units described above may be embodied in one module or unit in accordance with embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into a plurality of modules or units to be embodied.

From the above description of embodiments, those skilled in the art will readily appreciate that the example embodiments described herein may be implemented in software, or may be implemented in software in combination with the necessary hardware. Thus, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (may be a CD-ROM, a U-disk, a mobile hard disk, etc.) or on a network, and includes several instructions to cause a computing device (may be a personal computer, a server, a touch terminal, or a network device, etc.) to perform the method according to the embodiments of the present application.

Although the embodiments of the present specification are disclosed above, the present invention is not limited thereto. Various changes and modifications may be made by one skilled in the art without departing from the spirit and scope of the invention, and the scope of the invention should be assessed accordingly to that of the appended claims.

Claims

1. The test case generation method of the SoC is characterized in that the SoC comprises at least one digital IP, and the test case generation method of the SoC comprises the following steps:

2. The method for generating a test case for an SoC according to claim 1, wherein the decomposing the test requirement data to form a plurality of candidate test data and storing the candidate test data in a preset database includes:

3. The test case generation method of the SoC of claim 2, wherein when the test dimension includes a clock dimension, at least one alternative clock test data is generated by calling a user manual and an explanation document of the digital IP, and a frequency of the at least one alternative clock test data corresponds to the digital IP;

4. The method of claim 2, wherein the verification template includes a plurality of sub-verification templates, and one sub-verification template corresponds to one test dimension;

5. The method for generating a test case for an SoC according to claim 1, wherein the acquiring test requirement data includes:

Acquiring the test requirement data in the test process of the SoC;

And manually acquiring the test requirement data by a verification engineer.

6. The method for generating test cases for SoC according to claim 1, wherein said step of generating test cases corresponding to said target digital IP by calling said verification template based on test case scripts further comprises:

7. The test case generation method of the SoC of claim 1, further comprising:

and testing the SoC by adopting the test case.

8. A test case generation apparatus for an SoC, wherein the SoC includes at least one digital IP, the test case generation apparatus for an SoC comprising:

9. A host computer, which comprises a host computer, characterized by comprising the following steps: at least one processor and at least one memory storing one or more computer-executable instructions that the processor invokes to perform the test case generation method of the SoC of any of claims 1-7.

10. A computer program product comprising computer instructions which, when executed by a processor, implement the test case generation method of the SoC of any of claims 1 to 7.