CN116932412B - Sharing platform and method that can generate test stimulus files in different formats - Google Patents

Abstract

The invention can generate sharing platforms and methods of test excitation files with different formats, develop an API function library based on a compiling programming language and compile the API function library into a sharing library; writing a configuration file; generating a test excitation file by adopting an interpreted programming language; the invention allows the chip manufacturer to develop the test program with higher abstract level, and the library packaging is carried out on the test program by a modularized design method, thereby not only improving the efficiency, but also improving the maintainability and reusability of the test program; the method also allows chip manufacturers to write different hardware drivers according to the test environment, and meanwhile, the method can directly call the test program with higher abstract level, and finally, the test program is converted into the program which can be identified by the ATE or the verification platform, so that the development process is simplified, and the reusability of the test program is also improved.

Description

Sharing platform and method that can generate test stimulus files in different formats

Technical field

The invention belongs to the field of chip testing, and specifically relates to a sharing platform and method that can generate test stimulus files in different formats.

Background technique

With the continuous development and expansion of integrated circuit technology, chip verification and testing occupy an increasingly important position. Pattern (test stimulus file) is essentially the truth table of the chip. The main content it contains is the symbolic combination of input timing and expected timing. It also contains microinstructions used to implement certain complex functions.

ATE (Automatic Test Equipment) is automatic test equipment. During the chip testing process, it sends the input timing of the Pattern row vector to the input pin of the chip under test, and compares the output timing of the output pin of the chip under test with the Pattern (test stimulus). file) expected timing of the row vector, determine whether this test chip meets the requirements based on the comparison results.

The VCD (Value Change Dump) file format is a universal waveform file format. It is an ASCII (American Standard Code for Information Interchange) file defined in the IEEE1364 standard (Verilog HDL Hardware Description Language Standard, p325). It is a general chip design simulation file. At this stage, Pattern is usually converted from VCD.

The test procedures required for chip verification are developed by the chip manufacturer and are independent of FT testing; the test procedures required for FT testing are either re-developed by the packaging and testing factory according to the operation manual provided by the chip manufacturer, or passed by the packaging and testing factory through a common Conversion software or self-written conversion software converts verification waveform files based on industry standard formats. This conversion method of repeatedly developing or interpreting waveform files not only has low development efficiency, but also reduces the maintainability and reusability of the test program. Low.

Contents of the invention

The purpose of the present invention is to provide a sharing platform and method that can generate test stimulus files in different formats. It does not require repeated development or interpretation of waveform file conversion methods to obtain test programs in different formats, simplifying the development process and improving the reliability of the test program. Reusability.

The present invention can generate a method for testing stimulus files in different formats, including the following steps:

Step 1. Develop API function library based on compiled programming language and compile API function library into a shared library;

Develop API functions in parallel during the chip hardware development stage, abstract the functional test points of the chip, and then refine the test functions to the read and write functions of the chip registers, clarify the interactive interface methods and hierarchical relationships between API functions, and specify the API The input or output parameters of the function and the simulation model of some functional modules; the API function is written in a compiled programming language from the bottom up. The called API function will provide two interface parameters, the register address and the data list, so that the upper layer function can pass this Two interface parameters to call it; integrate the API function in the SDK environment and conduct simulation verification to ensure the correctness of the test program; distribute the successfully verified API functions in multiple files by function, and then encapsulate them into API functions Library; compile these files into a shared library to facilitate virtual platform calls;

Step 2. Write the configuration file;

Write a configuration file, which includes a specified chip pin list, hardware communication interface parameters and test environment parameters;

Step 3. Use interpreted programming language to generate test stimulus files;

Step 3.1. Build a virtual platform based on an interpreted programming language to isolate the dependencies of the test software from the test environment. Read the configuration information to ensure that the test software can run on different verification platforms;

Read the configuration file in cfg format through the Configuration reader module, and then output three parameters to the Generator module. The three parameters are the chip pin list, hardware communication interface parameters and test environment parameters;

Use the top-level function run_test() of the Transaction descriptor module to call the API function in the shared library to build the behavioral model of the chip, and map the underlying functions mailbox_send(address, data) and mailbox_recieve(address, data) of the Transaction descriptor module to the Generator module Hardware driver function to achieve specific interface communication;

The Generator module contains the top-level function run_gen() and the hardware driver function. Run_gen() selects the type of excitation signal based on the incoming hardware communication interface parameters, and confirms the hardware driver function based on the incoming chip pin list and test environment parameters. The assignment object and the format of the test stimulus file, and finally map the mailbox_send(address, data) and mailbox_recieve(address, data) of the Transactiondescriptor module to hardware interface functions;

The top-level and bottom-level functions are written in an interpreted programming language;

Step 3.2. Run run_gen() to generate the test stimulus file and output it;

The format of the test stimulus file is determined by the Generator module reading the test environment parameters. When the ATE test environment is selected, the output format is a pat format file recognized by ATE. When the Verilog test environment is selected, the output format is a Verilog HDL format file. When selecting the SDK test environment, the output format is a cfg format file.

When developing, testing and debugging code in the SDK, set the return value of each API function to a Boolean value. Once the function is executed correctly, it will return true, and once it is executed incorrectly, it will return false.

The invention can generate a sharing platform for test stimulus files in different formats, including a shared library that is convenient for virtual platform calls and a virtual platform provided based on an interpreted programming language. The virtual platform is constructed by a Configuration reader module, a Transaction descriptor module and a Generator module. To isolate the dependencies of the test software from the test environment, and ensure that the test software can run on different verification platforms by reading configuration information;

The shared library that is convenient for virtual platforms to call is compiled from an API function library developed based on a compiled programming language; the API database is encapsulated by all successfully executed API functions distributed in multiple files according to their functions. The API functions described are developed in parallel during the chip hardware development stage, abstracting the functional test points of the chip, and then refining the test functions to the read and write functions of the chip registers, clarifying the interactive interface methods and hierarchical relationships between API functions , stipulate the input or output parameters of the API function and the simulation model of some functional modules; then use the compiled programming language to write the API function from the bottom up. The called API function will provide two interface parameters, the register address and the data list, so that the previous The layer function calls it through these two interface parameters; integrate the API function in the SDK environment and simulate it to verify it, ensure the correctness of the test program through SDK development testing, and obtain the successfully verified API function;

The Configuration reader module is used to read the configuration file in cfg format, and then outputs three parameters to the Generator module. The three parameters are the chip pin list, hardware communication interface parameters and test environment parameters; the configuration file includes Specify the chip pin list, hardware communication interface parameters and test environment parameters;

The Transaction descriptor module is used to call the API function in the shared library through its top-level function run_test() to build a behavioral model of the chip, and is mapped to the chip through its underlying functions mailbox_send(address, data) and mailbox_recieve(address, data) The hardware driver function of the Generator module to achieve specific interface communication;

The Generator module contains the top-level function run_gen() and the hardware driver function. Run_gen() selects the type of excitation signal based on the incoming hardware communication interface parameters, and confirms the hardware driver function based on the incoming chip pin list and test environment parameters. Assign the object and the format of the test stimulus file, and finally map the mailbox_send(address, data) and mailbox_recieve(address, data) of the Transaction descriptor module to the hardware interface function; run run_gen() to generate the test stimulus file and output it;

The top-level and bottom-level functions are written in an interpreted programming language;

The format of the test stimulus file is determined by the Generator module reading the test environment parameters. When the ATE test environment is selected, the output format is a pat format file that can be recognized by ATE. When the Verilog test environment is selected, the output format is a Verilog HDL format file. , when selecting the SDK test environment, the output format is a cfg format file.

An electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are At least one processor executes, so that the at least one processor can execute the processing steps of any of the above methods that can generate test stimulus files in different formats.

A non-transitory computer-readable storage medium storing computer instructions, the computer instructions being used to cause a computer to execute processing steps according to any of the above methods for generating test stimulus files in different formats.

The present invention develops a cross-platform software development architecture by combining a compiled programming language and an interpreted programming language. The cross-platform software development architecture allows chip manufacturers to develop test programs with better abstraction levels, modular design, and test The library encapsulation of the program not only improves the efficiency, but also improves the maintainability and reusability of the test program; it also allows chip manufacturers to write different hardware drivers according to the test environment, and can also directly call higher abstraction levels. The test program is eventually converted into a program that can be recognized by ATE or the verification platform, which simplifies the development process and improves the reusability of the test program.

Using the technical solution of the present invention, chip manufacturer application engineers can directly use test programs with a higher abstraction level, encapsulate these test programs in the SDK, and then carry out application development and functional testing of the chip back to the factory, realizing the first step of the test program. Secondary reuse; chip manufacturer chip verification engineers can directly use test programs with higher abstraction levels to do functional tests, or they can call lower-level patterns through system functions and then do functional tests, so that the second pass of the test program can be implemented Reuse; test engineers at the packaging and testing factory can specify the ATE test environment to generate different patterns, thereby realizing the third reuse of the test program; since different patterns can be generated according to different functions, the need for large-capacity storage space is eliminated. Disadvantages of permanently storing test files in various formats.

Description of the drawings

Figure 1 is a functional block diagram of a sharing platform that can generate test stimulus files in different formats according to the present invention;

Figure 2 is a flow chart of a method for generating test stimulus files in different formats according to the present invention.

Detailed ways

In order to make the purpose, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present invention, not all of them. . Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of the present invention.

Embodiment 1

As shown in Figures 1 and 2, Embodiment 1 of the present invention provides a method for generating test stimulus files in different formats, including the following steps:

Step 1. Develop API function library based on compiled programming language and compile API function library into a shared library;

Develop API functions in parallel during the chip design stage, abstract the functional test points of the chip, and refine the test functions down to the reading and writing functions of the chip registers, and clarify the interactive interface methods and hierarchical relationships between API functions, specifically: which API functions serve as upper-level functions or lower-level functions. Which functions require input parameters or output parameters, and which functions require writing model function models for result comparison;

A compiled programming language is used to write API functions from the bottom up. The API function that is allowed to be called needs to provide two interface parameters: the register address and the data list to be sent. The upper layer function is allowed to call the next layer function through these two interface parameters. For example, the upper-level function flash_erase(address, write_data) calls the lower-level function flash_reg_write(address, write_data). The first parameter in the function is the register address, and the second parameter is the data list to be sent;

Integrate API functions into the SDK environment for SDK development testing, verify them and ensure the correctness of the test program: In order to facilitate debugging the code, set the return value of each API function to a Boolean type value. Once a function If it is executed correctly, it will return true, and once it is executed incorrectly, it will return false, so as to quickly determine the abnormal point and then return to the SDK development test;

Encapsulate all successfully executed API functions into an API function library;

In the process of writing API functions, for the reusability and maintainability of the program, the API function libraries are distributed in multiple files, and then compiled into a shared library to facilitate run_test() calls;

Step 2. Write the configuration file;

Write a configuration file, which includes the specified chip pin list, hardware communication interface parameters and test environment parameters. For example, the ATE device accesses the chip through the jtag interface;

Step 3. Use interpreted programming language to generate test stimulus files;

Step 3.1. Provide a virtual platform based on the interpreted programming language to isolate the dependencies of the test software from the test environment, and ensure that the test software can run on different verification platforms by reading configuration information;

The Configuration reader module reads the configuration file in cfg format, and then outputs three parameters to the Generator module, which are the chip pin list, hardware communication interface parameters and test environment parameters;

Through the top-level function run_test() of the Transaction descriptor module, the API function in the shared library is called to build the behavioral model of the chip. For example, to erase a certain section of flash storage space, you can call the API function library in the shared library. The function flash_erase(address, write_data) is mapped to the hardware driver function of the Generator module through the underlying functions mailbox_send(address, data) and mailbox_recieve(address, data) of the Transactiondescriptor module, thereby realizing specific interface communication;

The Generator module contains the top-level function run_gen() and the hardware driver function. Run_gen() selects the type of excitation signal based on the incoming hardware communication interface parameters, and confirms the hardware driver function based on the incoming chip pin list and test environment parameters. The assignment object and the format of the test stimulus file, and finally map the mailbox_send(address, data) and mailbox_recieve(address, data) of the Transactiondescriptor module to the hardware interface function. For example, when the return value of the hardware communication interface parameter is "01", the communication The interface is jtag, and the hardware driver functions jtag_reg_write(address, write_data) and jtag_reg_read(address, read_data) respectively map the mailbox_send(address, data) and mailbox_recieve(address, data) functions in run_test();

Step 3.2. Run run_gen() to generate the test stimulus file and output it;

The test stimulus file can be a pat format file that can be recognized by ATE, or a Verilog HDL format file that can be recognized by chip simulation tools; the format of the test stimulus file is determined by the Generator module reading the test environment parameters. When the ATE test environment is selected When the Verilog test environment is selected, the output format is a Verilog HDL format file. When the SDK test environment is selected, the output format is a cfg format file.

Using the technical solution of the present invention, chip manufacturer application engineers can directly use test programs with a higher abstraction level, encapsulate these test programs in the SDK, and then carry out application development and functional testing of the chip back to the factory, realizing the first step of the test program. Secondary reuse; chip manufacturer chip verification engineers can directly use test programs with higher abstraction levels to do functional tests, or they can call lower-level patterns through system functions and then do functional tests, so that the second pass of the test program can be implemented Reuse; test engineers at the packaging and testing factory can specify the ATE test environment to generate different patterns, thereby realizing the third reuse of the test program; since different patterns can be generated according to different functions, the need for large-capacity storage space is eliminated. Disadvantages of permanently storing test files in various formats.

Embodiment 2

As shown in Figure 1, the present invention provides a sharing platform that can generate test stimulus files in different formats, including a shared library that is convenient for the virtual platform to call and a virtual platform provided based on an interpreted programming language. The virtual platform is composed of a Configuration reader module, The Transaction descriptor module and the Generator module are built to isolate the dependencies of the test software from the test environment, and ensure that the test software can run on different verification platforms by reading configuration information;

The shared library that is convenient for virtual platforms to call is compiled from an API function library developed based on a compiled programming language; the API database is encapsulated by all successfully executed API functions distributed in multiple files according to their functions. The API functions described are developed in parallel during the chip hardware development stage, abstracting the functional test points of the chip, and then refining the test functions to the read and write functions of the chip registers, clarifying the interactive interface methods and hierarchical relationships between API functions , stipulate the input or output parameters of the API function and the simulation model of some functional modules; then use the compiled programming language to write the API function from the bottom up. The called API function will provide two interface parameters, the register address and the data list, so that the previous The layer function calls it through these two interface parameters; integrate the API function in the SDK environment and simulate and verify it, ensure the correctness of the test program through SDK development testing, and obtain the successfully verified API function; in order to facilitate debugging the code, In the SDK development test, set the return value of each API function to a Boolean value. Once the function is executed correctly, it will return true, and once the execution error occurs, it will return false, so as to quickly determine the abnormal point and then return to the SDK. development testing;

The Configuration reader module is used to read the configuration file in cfg format, and then outputs three parameters to the Generator module, which are chip pin list, hardware communication interface parameters and test environment parameters; the configuration file includes specified chip pins List, hardware communication interface parameters and test environment parameters;

The Transaction descriptor module is used to call the API function in the shared library through its top-level function run_test() to build a behavioral model of the chip, and is mapped to the chip through its underlying functions mailbox_send(address, data) and mailbox_recieve(address, data) The hardware driver function of the Generator module realizes specific interface communication. The top-level and bottom-level functions are written in an interpreted programming language;

The Generator module contains the top-level function run_gen() and the hardware driver function. Run_gen() selects the type of excitation signal based on the incoming hardware communication interface parameters, and confirms the hardware driver function based on the incoming chip pin list and test environment parameters. Assign the object and the format of the test stimulus file, and finally map the mailbox_send(address, data) and mailbox_recieve(address, data) of the Transaction descriptor module to the hardware interface function; run run_gen() to generate the test stimulus file and output it.

The format of the test stimulus file is determined by the Generator module reading the test environment parameters. When the ATE test environment is selected, the output format is a pat format file that can be recognized by ATE. When the Verilog test environment is selected, the output format is a Verilog HDL format file. , when selecting the SDK test environment, the output format is a cfg format file.

Embodiment 3

Embodiment 3 of the present invention provides an electronic device. The electronic device may be the foregoing terminal device or server, or may be a terminal device or server connected to the foregoing terminal device or server to implement the method of Embodiment 1 of the present invention.

The electronic device may include: a processor (such as a CPU), a memory, and a data acquisition device; the processor is connected to and controls the data acquisition device. Various instructions can be stored in the memory to complete various processing functions and implement the processing steps described in the method of the first embodiment.

Embodiment 4

Embodiment 4 of the present invention also provides a computer-readable storage medium. The computer-readable storage medium stores instructions that, when run on a computer, cause the computer to execute the processing steps described in the method of Embodiment 1 above.

Those skilled in the art should further realize that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present invention can be implemented by electronic hardware, computer software, or a combination of both. In order to clearly illustrate the hardware and software Interchangeability, in the above description, the composition and steps of each example have been generally described according to functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each specific application, but such implementations should not be considered to be beyond the scope of the present invention.

The above-described specific embodiments further describe the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above-mentioned are only specific embodiments of the present invention and are not intended to limit the scope of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included in the protection scope of the present invention.

Claims (5)

1. A method for generating test stimulus files in different formats, which is characterized by including the following steps: Step 1. Develop API function library based on compiled programming language and compile API function library into a shared library; Develop API functions in parallel during the chip hardware development stage, abstract the functional test points of the chip, and then refine the test functions to the read and write functions of the chip registers, clarify the interactive interface methods and hierarchical relationships between API functions, and specify the API The input or output parameters of the function and the simulation model of some functional modules; the API function is written in a compiled programming language from the bottom up. The called API function will provide two interface parameters, the register address and the data list, so that the upper layer function can pass this Two interface parameters to call it; integrate the API function in the SDK environment and conduct simulation verification to ensure the correctness of the test program; distribute the successfully verified API functions in multiple files by function, and then encapsulate them into API functions Library; compile these files into a shared library that is convenient for virtual platform calls; Step 2. Write the configuration file; Write a configuration file, which includes a specified chip pin list, hardware communication interface parameters and test environment parameters; Step 3. Use interpreted programming language to generate test stimulus files; Step 3.1. Provide a virtual platform based on the interpreted programming language to isolate the dependencies of the test software from the test environment, and ensure that the test software can run on different verification platforms by reading configuration information; Read the configuration file in cfg format through the Configuration reader module, and then output three parameters to the Generator module. The three parameters are the chip pin list, hardware communication interface parameters and test environment parameters; Use the top-level function run_test() of the Transaction descriptor module to call the API function in the shared library to build the behavioral model of the chip, and map the underlying functions mailbox_send(address, data) and mailbox_recieve(address, data) of the Transaction descriptor module to the Generator module Hardware driver function to achieve specific interface communication; The Generator module contains the top-level function run_gen() and the hardware driver function. Run_gen() selects the type of excitation signal based on the incoming hardware communication interface parameters, and confirms the hardware driver function based on the incoming chip pin list and test environment parameters. The assignment object and the format of the test stimulus file, and finally map the mailbox_send(address, data) and mailbox_recieve(address, data) of the Transaction descriptor module to hardware interface functions; The top-level and bottom-level functions are written in an interpreted programming language; Step 3.2. Run run_gen() to generate the test stimulus file and output it; The format of the test stimulus file is determined by the Generator module reading the test environment parameters. When the ATE test environment is selected, the output format is a pat format file recognized by ATE. When the Verilog test environment is selected, the output format is a VerilogHDL format file. When using the SDK test environment, the output format is a cfg format file. 2. The method for generating test stimulus files in different formats according to claim 1, characterized in that: when performing SDK development, testing and debugging code, the return value of each API function is set to a Boolean type value. Once the function is correct If executed correctly, true will be returned, and if an error occurs, false will be returned. 3. A shared platform that can generate test stimulus files in different formats. It is characterized by: including a shared library that is convenient for the virtual platform to call and a virtual platform based on an interpreted programming language. The virtual platform consists of a Configuration reader module, a Transaction descriptor module and a Generator. Module construction is used to isolate the dependencies of the test software from the test environment, and ensure that the test software can run on different verification platforms by reading configuration information; The shared library that is convenient for virtual platforms to call is compiled from an API function library developed based on a compiled programming language; the API function library is encapsulated by all successfully executed API functions distributed in multiple files according to their functions. , the API functions described are developed in parallel during the chip hardware development stage, abstracting the functional test points of the chip, and then refining the test functions to the read and write functions of the chip registers, clarifying the interactive interface methods and levels between API functions relationship, specifying the input or output parameters of the API function and the simulation model of some functional modules; and then writing the API function in a compiled programming language from the bottom up. The called API function will provide two interface parameters, the register address and the data list, so that it can be uploaded A layer of function calls it through these two interface parameters; the API function is integrated into the SDK environment and simulated and verified, and the correctness of the test program is ensured through SDK development testing, and the successfully verified API function is obtained; The Configuration reader module is used to read the configuration file in cfg format, and then outputs three parameters to the Generator module. The three parameters are the chip pin list, hardware communication interface parameters and test environment parameters; the configuration file includes Specify the chip pin list, hardware communication interface parameters and test environment parameters; The Transaction descriptor module is used to call the API function in the shared library through its top-level function run_test() to build a behavioral model of the chip, and is mapped to the chip through its underlying functions mailbox_send(address, data) and mailbox_recieve(address, data) The hardware driver function of the Generator module to achieve specific interface communication; The Generator module contains the top-level function run_gen() and the hardware driver function. Run_gen() selects the type of excitation signal based on the incoming hardware communication interface parameters, and confirms the hardware driver function based on the incoming chip pin list and test environment parameters. Assign the object and the format of the test stimulus file, and finally map the mailbox_send(address, data) and mailbox_recieve(address, data) of the Transaction descriptor module to the hardware interface function; run run_gen() to generate the test stimulus file and output it; The top-level and bottom-level functions are written in an interpreted programming language; The format of the test stimulus file is determined by the Generator module reading the test environment parameters. When the ATE test environment is selected, the output format is a pat format file that can be recognized by ATE. When the Verilog test environment is selected, the output format is a Verilog HDL format file. , when selecting the SDK test environment, the output format is a cfg format file. 4. An electronic device, characterized in that it includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, The instructions are executed by the at least one processor, so that the at least one processor can perform the processing steps of the method of any one of claims 1 to 2 that can generate test stimulus files in different formats. 5. A computer-readable storage medium storing computer instructions, characterized in that the computer instructions are used to cause the computer to execute a method for generating test stimulus files in different formats according to any one of claims 1 to 2. Processing steps.