CN116932412B - Sharing platform and method capable of generating test excitation files with different formats - Google Patents
Sharing platform and method capable of generating test excitation files with different formats Download PDFInfo
- Publication number
- CN116932412B CN116932412B CN202311169439.2A CN202311169439A CN116932412B CN 116932412 B CN116932412 B CN 116932412B CN 202311169439 A CN202311169439 A CN 202311169439A CN 116932412 B CN116932412 B CN 116932412B
- Authority
- CN
- China
- Prior art keywords
- test
- function
- parameters
- api
- functions
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 144
- 230000005284 excitation Effects 0.000 title claims abstract description 35
- 238000000034 method Methods 0.000 title claims abstract description 31
- 230000006870 function Effects 0.000 claims abstract description 185
- 238000012795 verification Methods 0.000 claims abstract description 18
- 238000011161 development Methods 0.000 claims abstract description 12
- 238000004806 packaging method and process Methods 0.000 claims abstract description 10
- 238000004891 communication Methods 0.000 claims description 26
- 238000004088 simulation Methods 0.000 claims description 12
- 238000011981 development test Methods 0.000 claims description 10
- 230000006399 behavior Effects 0.000 claims description 6
- 230000002452 interceptive effect Effects 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 5
- 238000013461 design Methods 0.000 abstract description 4
- 238000011990 functional testing Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 4
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000013341 scale-up Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3648—Software debugging using additional hardware
- G06F11/3656—Software debugging using additional hardware using a specific debug interface
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
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
Technical Field
The invention belongs to the field of chip testing, and particularly relates to a sharing platform and method capable of generating test excitation files with different formats.
Background
With the continuous development and scale-up of integrated circuit technology, chip verification and testing are increasingly important. Pattern (test stimulus document), essentially a truth table of a chip, contains a combination of symbols of input timing and expected timing, and also contains micro-instructions for implementing some complex functions.
ATE (Automatic Test Equipment) is an automatic test device, in the process of testing a chip, an input timing sequence of a Pattern row vector is sent to an input pin of the tested chip, an output timing sequence of an output pin of the tested chip is compared with an expected timing sequence of the Pattern row vector, and whether the tested chip meets the requirement is determined according to a comparison result.
The VCD (Value Change Dump) file format is a general waveform file format, is an ASCII (American Standard Code for Information Interchange ) file defined in the IEEE1364 standard (Verilog HDL hardware description language standard, p 325), is a general chip design simulation file, and the current Pattern is usually converted by VCD.
The test program required for chip verification is developed by the chip manufacturer and is independent of the FT test; the test program required by the FT test is re-developed by a packaging test factory according to an operation manual provided by a chip manufacturer, or is obtained by converting a verification waveform file based on an industry standard format by the packaging test factory through universal conversion software or self-organized conversion software.
Disclosure of Invention
The invention aims to provide a sharing platform and a sharing method capable of generating test excitation files with different formats, test programs with different formats are obtained without repeated development or explanation of conversion modes of waveform files, the development process is simplified, and the reusability of the test programs is improved.
The method for generating the test excitation file with different formats comprises the following steps:
step 1, developing an API function library based on a compiling programming language and compiling the API function library into a shared library;
in the chip hardware development stage, the API functions are developed in parallel, the function test points of the chip are abstracted, then the test functions are thinned, the read-write functions of the chip registers are thinned, the interactive interface modes and the hierarchical relations among the API functions are defined, and the input or output parameters of the API functions and the simulation model of part of functional modules are specified; programming an API function by adopting a compiling programming language from bottom to top, wherein the called API function provides two interface parameters of a register address and a data list so that a function of a previous layer calls the register address and the data list through the two interface parameters; integrating the API function in the SDK environment and performing simulation verification on the API function to ensure the correctness of the test program; distributing the successfully verified API functions in a plurality of files according to functions, and then packaging the API functions into an API function library; compiling the files into a shared library to facilitate virtual platform call;
step 2, compiling a configuration file;
writing a configuration file, wherein the configuration file comprises a specified chip pin list, hardware communication interface parameters and test environment parameters;
step 3, generating a test excitation file by adopting an interpreted programming language;
step 3.1, building a virtual platform based on an interpreted programming language, isolating the dependency item of the test software from the test environment, and ensuring that the test software can run on different verification platforms by reading configuration information;
reading a configuration file in a cfg format through a Configuration reader module, and then outputting three parameters to a Generator module, wherein the three parameters are a chip pin list, hardware communication interface parameters and test environment parameters respectively;
calling an API function in a shared library through a top layer function run_test () of a Transaction descriptor module to construct a behavior level model of the chip, and mapping bottom layer functions mailbox_send (address, data) and mailbox_direct (address, data) of the Transaction descriptor module to a hardware driving function of a Generator module so as to realize specific interface communication;
the Generator module comprises a top layer function run_gen () and a hardware driving function, wherein the run_gen () selects the type of an excitation signal according to the input hardware communication interface parameters, confirms the assignment object of the hardware driving function and the format of a test excitation file according to the input chip pin list and the test environment parameters, and finally maps the mailbox_send (address, data) and the mailbox_direct (address, data) of the Transaction descriptor module into the hardware interface functions;
the top layer and bottom layer functions are written by an interpreted programming language;
step 3.2, running run_gen () to generate a test excitation file and outputting the test excitation file;
the format of the test stimulus file is determined by the Generator module reading test environment parameters, when the ATE test environment is selected, the output format is a pat format file which can be identified by ATE, when the Verilog test environment is selected, the output format is a Verilog HDL format file, and when the SDK test environment is selected, the output format is a cfg format file.
When SDK development test debugging codes are carried out, the return value of each API function is set to be a Boolean type numerical value, true is returned once the function is correctly executed, and false is returned once the function is executed in error.
The invention can generate the sharing platform of the test excitation file of different formats, including the sharing library which is convenient for the virtual platform to call and the virtual platform provided based on the interpreted programming language, the virtual platform is constructed by Configuration reader module, transaction descriptor module and Generator module, used for isolating the dependency item of the test software from the test environment, and ensuring the test software to run on different verification platforms by reading the configuration information;
the shared library convenient for the virtual platform to call is compiled by an API function library developed based on a compiling programming language; the API database is formed by packaging all the successfully executed API functions distributed in a plurality of files according to functions, the API functions are developed in parallel in a chip hardware development stage, the function test points of a chip are abstracted, then the test functions are thinned, the read-write functions of the chip registers are thinned, the interactive interface modes and the hierarchical relationship among the API functions are defined, and input or output parameters of the API functions and simulation models of partial functional modules are specified; then, compiling an API function by adopting a compiling programming language from bottom to top, wherein the called API function provides two interface parameters of a register address and a data list so that a function on the upper layer calls the API function through the two interface parameters; integrating the API function in an SDK environment and performing simulation verification on the API function, ensuring the correctness of a test program through SDK development test, and obtaining the successfully verified API function;
the Configuration reader module is used for reading the configuration file in the cfg format and then outputting three parameters to the Generator module, wherein the three parameters are a chip pin list, hardware communication interface parameters and test environment parameters respectively; the configuration file comprises a specified chip pin list, hardware communication interface parameters and test environment parameters;
the Transaction descriptor module is configured to call an API function in the shared library through a top layer function run_test () thereof to construct a behavior level model of the chip, and map the bottom layer functions mailbox_send (address, data) and mailbox_direct (address, data) thereof to a hardware driver function of the Generator module, thereby implementing specific interface communication;
the Generator module comprises a top layer function run_gen () and a hardware driving function, wherein the run_gen () selects the type of an excitation signal according to the parameters of an input hardware communication interface, confirms the assignment object of the hardware driving function and the format of a test excitation file according to the input chip pin list and the test environment parameters, and finally maps the mailbox_send (address, data) and the mailbox_direct (address, data) of the Transaction descriptor module into the hardware interface function; running run_gen () to generate a test excitation file and outputting the test excitation file;
the top layer and bottom layer functions are written by an interpreted programming language;
the format of the test stimulus file is determined by the Generator module reading test environment parameters, when the ATE test environment is selected, the output format is a pat format file which can be identified by ATE, when the Verilog test environment is selected, the output format is a Verilog HDL format file, and when the SDK test environment is selected, the output format is a cfg format file.
An electronic device, comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the processing steps of any of the methods described above for generating test stimulus files of different formats.
A non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the process steps of a method of generating test stimulus files according to any of the above-described different formats.
According to the invention, the cross-platform software development architecture is developed by combining the compiling programming language and the interpretation programming language, and allows a chip manufacturer to develop the test program with better abstract level, so that the test program can be designed in a modularized manner, and library packaging is performed on the test program, 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.
By adopting the technical scheme of the invention, an application engineer of a chip manufacturer can directly use test programs with higher abstract level, the test programs are packaged in the SDK, then the development of the application and the functional test of the chip returning to the factory are carried out, and the first multiplexing of the test programs is realized; the chip manufacturer chip verification engineer can directly use the test program with higher abstract level to perform functional test, and can also call the lower-layer pattern through the system function and then perform functional test, so that the second multiplexing of the test program can be realized; the package test factory test engineer may specify the test environment of the ATE to generate different patterns to implement a third reuse of test programs; because different patterns can be generated according to different functions, the defect that a large-capacity storage space is needed to store test files in various formats at one time is overcome.
Drawings
FIG. 1 is a functional block diagram of a shared platform of the present invention that may generate test stimulus files of different formats;
FIG. 2 is a flow chart of a method for generating test stimulus files of different formats according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in further detail below with reference to the accompanying drawings, it being apparent that the described embodiments are only some, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Example 1
As shown in fig. 1 and 2, a first embodiment of the present invention provides a method for generating test stimulus files with different formats, which includes the following steps:
step 1, developing an API function library based on a compiling programming language and compiling the API function library into a shared library;
in the chip design stage, the API functions are developed in parallel, the function test points of the chip are abstracted, the test functions are thinned to the read-write functions of the chip registers, and the interactive interface modes and the hierarchical relations among the API functions are defined, specifically: which API functions are used as the functions of the upper layer or the functions of the lower layer, which functions need input parameters or output parameters, and which functions need to write model function models to compare results;
the method comprises the steps that an API function is written by adopting a compiling programming language from bottom to top, the API function which is allowed to be called needs to provide two interface parameters of a register address and a data list to be sent, a function of a previous layer is allowed to call a function of a next layer through the two interface parameters, for example, a function of the previous layer, namely, flash_erase (address, write_data), calls a function of the next layer, namely, flash_reg_write (address, write_data), wherein a first parameter in the function is the register address, and a second parameter is the data list to be sent;
integrating the API function into the SDK environment to perform SDK development test, verifying the SDK development test and ensuring the correctness of the test program: in order to facilitate debugging codes, setting the return value of each API function as a Boolean type value, returning true once a function is correctly executed, and returning false once an error is executed, thereby quickly determining an abnormal point, and then returning to an SDK development test;
packaging all the successfully executed API functions into an API function library;
in the process of programming an API function, for the reusability and maintainability of a program, API function libraries are distributed in a plurality of files, and then compiled into a shared library so as to facilitate run_test () call;
step 2, compiling a configuration file;
writing a configuration file, wherein the configuration file comprises a specified chip pin list, hardware communication interface parameters and test environment parameters, for example, ATE equipment accesses a chip through a jtag interface;
step 3, generating a test excitation file by adopting an interpreted programming language;
step 3.1, providing a virtual platform based on an interpreted programming language, isolating the dependency item of the test software from the test environment, and ensuring that the test software can run on different verification platforms by reading configuration information;
the Configuration reader module reads a configuration file in a cfg format and then outputs three parameters to the Generator module, wherein the three parameters are a chip pin list, hardware communication interface parameters and test environment parameters respectively;
calling an API function in the shared library to construct a behavior level model of the chip through a top layer function run_test () of the Transaction descriptor module, for example, if a certain section of memory space of the flash is to be erased, a function flash_erase (address, write_data) in the API function library in the shared library can be called; mapping the bottom functions mailbox_send (address, data) and mailbox_direct (address, data) of the Transaction descriptor module to a hardware driving function of the Generator module, so that specific interface communication is realized;
the Generator module comprises a top-level function run_gen () and a hardware driver function, wherein the run_gen () selects the type of the excitation signal according to the input hardware communication interface parameter, confirms the assignment object of the hardware driver function and the format of the test excitation file according to the input chip pin list and the test environment parameter, and finally maps the mailbox_send (address, data) and the mailbox_direct (data) of the Transaction descriptor module into the hardware interface function, for example, when the hardware communication interface parameter returns a value of "01", the communication interface is jtag, and the hardware driver functions jtag_reg_write (address, write_data) and jtag_reg_read (address, read_data) map the mailbox_send (address, data) and mailbox_direct (address, data) functions in the run_test (), respectively;
step 3.2, running run_gen () to generate a test excitation file and outputting the test excitation file;
the test excitation file can be a pat format file which can be identified by ATE, and can also be a Verilog HDL format file which can be identified by a chip simulation tool; the format of the test stimulus file is determined by the Generator module reading test environment parameters, when the ATE test environment is selected, the output format is a pat format file which can be identified by ATE, when the Verilog test environment is selected, the output format is a Verilog HDL format file, and when the SDK test environment is selected, the output format is a cfg format file.
By adopting the technical scheme of the invention, an application engineer of a chip manufacturer can directly use test programs with higher abstract level, the test programs are packaged in the SDK, then the development of the application and the functional test of the chip returning to the factory are carried out, and the first multiplexing of the test programs is realized; the chip manufacturer chip verification engineer can directly use the test program with higher abstract level to perform functional test, and can also call the lower-layer pattern through the system function and then perform functional test, so that the second multiplexing of the test program can be realized; the package test factory test engineer may specify the test environment of the ATE to generate different patterns to implement a third reuse of test programs; because different patterns can be generated according to different functions, the defect that a large-capacity storage space is needed to store test files in various formats at one time is overcome.
Example two
As shown in FIG. 1, the present invention provides a shared platform capable of generating test stimulus files of different formats, comprising a shared library for facilitating the invocation of a virtual platform and a virtual platform provided based on an interpreted programming language, wherein the virtual platform is constructed by a Configuration reader module, a Transaction descriptor module and a Generator module and is used for isolating the dependency item of test software from the test environment, and the configuration information is read to ensure that the test software can run on different verification platforms;
the shared library convenient for the virtual platform to call is compiled by an API function library developed based on a compiling programming language; the API database is formed by packaging all the successfully executed API functions distributed in a plurality of files according to functions, the API functions are developed in parallel in a chip hardware development stage, the function test points of a chip are abstracted, then the test functions are thinned, the read-write functions of the chip registers are thinned, the interactive interface modes and the hierarchical relationship among the API functions are defined, and input or output parameters of the API functions and simulation models of partial functional modules are specified; then, compiling an API function by adopting a compiling programming language from bottom to top, wherein the called API function provides two interface parameters of a register address and a data list so that a function on the upper layer calls the API function through the two interface parameters; integrating the API function in an SDK environment and performing simulation verification on the API function, ensuring the correctness of a test program through SDK development test, and obtaining the successfully verified API function; in order to facilitate debugging codes, setting the return value of each API function as a Boolean type value in an SDK development test, returning true once the function is correctly executed, and returning false once an error is executed, thereby quickly determining an abnormal point, and then returning to the SDK development test;
the Configuration reader module is used for reading the configuration file in the cfg format, and then outputting three parameters to the Generator module, wherein the three parameters are a chip pin list, hardware communication interface parameters and test environment parameters respectively; the configuration file comprises a specified chip pin list, hardware communication interface parameters and test environment parameters;
the Transaction descriptor module is configured to call an API function in the shared library through a top layer function run_test () thereof to construct a behavior level model of the chip, and map the top layer function to a hardware driver function of the Generator module through bottom layer functions mailbox_send (address, data) and mailbox_direct (address, data) thereof, so as to implement specific interface communication, where the top layer function and the bottom layer function are written by an interpreted programming language;
the Generator module comprises a top layer function run_gen () and a hardware driving function, wherein the run_gen () selects the type of an excitation signal according to the parameters of an input hardware communication interface, confirms the assignment object of the hardware driving function and the format of a test excitation file according to the input chip pin list and the test environment parameters, and finally maps the mailbox_send (address, data) and the mailbox_direct (address, data) of the Transaction descriptor module into the hardware interface function; running run_gen () generates a test stimulus file and outputs it.
The format of the test stimulus file is determined by the Generator module reading test environment parameters, when the ATE test environment is selected, the output format is a pat format file which can be identified by ATE, when the Verilog test environment is selected, the output format is a Verilog HDL format file, and when the SDK test environment is selected, the output format is a cfg format file.
Example III
The third embodiment of the present invention provides an electronic device, which 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 a method of the embodiments of the present invention.
The electronic device may include: a processor (e.g., CPU), a memory, a data acquisition device; the processor is connected with and controls the data acquisition device. The memory may store various instructions for performing the various processing functions and implementing the processing steps described in the methods of the previous embodiments.
Example IV
A fourth embodiment of the present invention also provides a computer-readable storage medium having stored therein instructions which, when executed on a computer, cause the computer to perform the processing steps described in the method of the first embodiment.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative elements and steps are described above generally in terms of functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The foregoing description of the embodiments has been provided for the purpose of illustrating the general principles of the invention, and is not meant to limit the scope of the invention, but to limit the invention to the particular embodiments, and any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the invention are intended to be included within the scope of the invention.
Claims (5)
1. A method for generating test stimulus files of different formats, comprising the steps of:
step 1, developing an API function library based on a compiling programming language and compiling the API function library into a shared library;
in the chip hardware development stage, the API functions are developed in parallel, the function test points of the chip are abstracted, then the test functions are thinned, the read-write functions of the chip registers are thinned, the interactive interface modes and the hierarchical relations among the API functions are defined, and the input or output parameters of the API functions and the simulation model of part of functional modules are specified; programming an API function by adopting a compiling programming language from bottom to top, wherein the called API function provides two interface parameters of a register address and a data list so that a function of a previous layer calls the register address and the data list through the two interface parameters; integrating the API function in the SDK environment and performing simulation verification on the API function to ensure the correctness of the test program; distributing the successfully verified API functions in a plurality of files according to functions, and then packaging the API functions into an API function library; compiling the files into a shared library convenient for the virtual platform to call;
step 2, compiling a configuration file;
writing a configuration file, wherein the configuration file comprises a specified chip pin list, hardware communication interface parameters and test environment parameters;
step 3, generating a test excitation file by adopting an interpreted programming language;
step 3.1, providing a virtual platform based on an interpreted programming language, isolating the dependency item of the test software from the test environment, and ensuring that the test software can run on different verification platforms by reading configuration information;
reading a configuration file in a cfg format through a Configuration reader module, and then outputting three parameters to a Generator module, wherein the three parameters are a chip pin list, hardware communication interface parameters and test environment parameters respectively;
calling an API function in a shared library through a top layer function run_test () of a Transaction descriptor module to construct a behavior level model of the chip, and mapping bottom layer functions mailbox_send (address, data) and mailbox_direct (address, data) of the Transaction descriptor module to a hardware driving function of a Generator module so as to realize specific interface communication;
the Generator module comprises a top layer function run_gen () and a hardware driving function, wherein the run_gen () selects the type of an excitation signal according to the input hardware communication interface parameters, confirms the assignment object of the hardware driving function and the format of a test excitation file according to the input chip pin list and the test environment parameters, and finally maps the mailbox_send (address, data) and the mailbox_direct (address, data) of the Transaction descriptor module into the hardware interface functions;
the top layer and bottom layer functions are written by an interpreted programming language;
step 3.2, running run_gen () to generate a test excitation file and outputting the test excitation file;
the format of the test stimulus file is determined by the Generator module reading test environment parameters, when the ATE test environment is selected, the output format is a pat format file which can be identified by ATE, when the Verilog test environment is selected, the output format is a Verilog HDL format file, and when the SDK test environment is selected, the output format is a cfg format file.
2. The method for generating test stimulus files of different formats as claimed in claim 1, wherein: when SDK development test debugging codes are carried out, the return value of each API function is set to be a Boolean type numerical value, true is returned once the function is correctly executed, and false is returned once the function is executed in error.
3. The sharing platform capable of generating test excitation files of different formats is characterized in that: the system comprises a shared library which is convenient for the virtual platform to call and a virtual platform provided based on an interpreted programming language, wherein the virtual platform is constructed by a Configuration reader module, a Transaction descriptor module and a Generator module and is used for isolating the dependence item of test software from a test environment, and the configuration information is read to ensure that the test software can run on different verification platforms;
the shared library convenient for the virtual platform to call is compiled by an API function library developed based on a compiling programming language; the API function library is formed by packaging all the successfully executed API functions distributed in a plurality of files according to functions, the API functions are developed in parallel in a chip hardware development stage, the function test points of a chip are abstracted, then the test functions are thinned, the read-write functions of the chip registers are thinned, the interactive interface modes and the hierarchical relationship among the API functions are defined, and input or output parameters of the API functions and simulation models of partial functional modules are specified; then, compiling an API function by adopting a compiling programming language from bottom to top, wherein the called API function provides two interface parameters of a register address and a data list so that a function on the upper layer calls the API function through the two interface parameters; integrating the API function in an SDK environment and performing simulation verification on the API function, ensuring the correctness of a test program through SDK development test, and obtaining the successfully verified API function;
the Configuration reader module is used for reading the configuration file in the cfg format and then outputting three parameters to the Generator module, wherein the three parameters are a chip pin list, hardware communication interface parameters and test environment parameters respectively; the configuration file comprises a specified chip pin list, hardware communication interface parameters and test environment parameters;
the Transaction descriptor module is configured to call an API function in the shared library through a top layer function run_test () thereof to construct a behavior level model of the chip, and map the bottom layer functions mailbox_send (address, data) and mailbox_direct (address, data) thereof to a hardware driver function of the Generator module, thereby implementing specific interface communication;
the Generator module comprises a top layer function run_gen () and a hardware driving function, wherein the run_gen () selects the type of an excitation signal according to the parameters of an input hardware communication interface, confirms the assignment object of the hardware driving function and the format of a test excitation file according to the input chip pin list and the test environment parameters, and finally maps the mailbox_send (address, data) and the mailbox_direct (address, data) of the Transaction descriptor module into the hardware interface function; running run_gen () to generate a test excitation file and outputting the test excitation file;
the top layer and bottom layer functions are written by an interpreted programming language;
the format of the test stimulus file is determined by the Generator module reading test environment parameters, when the ATE test environment is selected, the output format is a pat format file which can be identified by ATE, when the Verilog test environment is selected, the output format is a Verilog HDL format file, and when the SDK test environment is selected, the output format is a cfg format file.
4. An electronic device, comprising: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the process steps of the method of any one of claims 1 to 2 for generating test stimulus files of different formats.
5. A computer readable storage medium storing computer instructions for causing a computer to perform the process steps of the method of generating test stimulus files of different formats according to any of claims 1 to 2.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311169439.2A CN116932412B (en) | 2023-09-12 | 2023-09-12 | Sharing platform and method capable of generating test excitation files with different formats |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311169439.2A CN116932412B (en) | 2023-09-12 | 2023-09-12 | Sharing platform and method capable of generating test excitation files with different formats |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116932412A CN116932412A (en) | 2023-10-24 |
| CN116932412B true CN116932412B (en) | 2024-01-23 |
Family
ID=88394357
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311169439.2A Active CN116932412B (en) | 2023-09-12 | 2023-09-12 | Sharing platform and method capable of generating test excitation files with different formats |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116932412B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1387304A1 (en) * | 2002-07-30 | 2004-02-04 | Bull S.A. | Method for functional verification of an integrated circuit model for building a verification platform, emulator equipment and verification platform |
| CN102480467A (en) * | 2010-11-25 | 2012-05-30 | 上海宇芯科技有限公司 | SOC (System on a Chip) software and hardware collaborative simulation verification method based on network communication protocol |
| CN102929627A (en) * | 2012-10-29 | 2013-02-13 | 无锡江南计算技术研究所 | Automatic testing program generating method based on ATE (Automatic Test Equipment) and ATE testing method |
| CN113702810A (en) * | 2021-09-01 | 2021-11-26 | 厦门优迅高速芯片有限公司 | MCU-based optical transceiver driver chip function test method and related equipment |
| CN114236359A (en) * | 2021-12-21 | 2022-03-25 | 无锡江南计算技术研究所 | Novel integrated circuit test excitation generation method for ATE test equipment |
| CN114580344A (en) * | 2022-04-24 | 2022-06-03 | 飞腾信息技术有限公司 | Test excitation generation method, verification system and related equipment |
| CN115858336A (en) * | 2022-11-01 | 2023-03-28 | 北京物芯科技有限责任公司 | Test vector generation method and device, computing equipment and storage medium |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114548031A (en) * | 2022-02-25 | 2022-05-27 | 长鑫存储技术有限公司 | Signal detection method and device |
-
2023
- 2023-09-12 CN CN202311169439.2A patent/CN116932412B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1387304A1 (en) * | 2002-07-30 | 2004-02-04 | Bull S.A. | Method for functional verification of an integrated circuit model for building a verification platform, emulator equipment and verification platform |
| CN102480467A (en) * | 2010-11-25 | 2012-05-30 | 上海宇芯科技有限公司 | SOC (System on a Chip) software and hardware collaborative simulation verification method based on network communication protocol |
| CN102929627A (en) * | 2012-10-29 | 2013-02-13 | 无锡江南计算技术研究所 | Automatic testing program generating method based on ATE (Automatic Test Equipment) and ATE testing method |
| CN113702810A (en) * | 2021-09-01 | 2021-11-26 | 厦门优迅高速芯片有限公司 | MCU-based optical transceiver driver chip function test method and related equipment |
| CN114236359A (en) * | 2021-12-21 | 2022-03-25 | 无锡江南计算技术研究所 | Novel integrated circuit test excitation generation method for ATE test equipment |
| CN114580344A (en) * | 2022-04-24 | 2022-06-03 | 飞腾信息技术有限公司 | Test excitation generation method, verification system and related equipment |
| CN115858336A (en) * | 2022-11-01 | 2023-03-28 | 北京物芯科技有限责任公司 | Test vector generation method and device, computing equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 16*16位Wallace乘法器测试激励文件设计;刘贝尔;《科技传播》(第11期);1-2 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116932412A (en) | 2023-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8402438B1 (en) | Method and system for generating verification information and tests for software | |
| CN112131829A (en) | Verification method, system and related device of chip register | |
| US7930603B2 (en) | Feature-oriented test program development and execution | |
| US20070061641A1 (en) | Apparatus and method for generating test driver | |
| CN112630622B (en) | Method and system for pattern compiling, downloading and testing of ATE (automatic test equipment) | |
| CN113704043A (en) | Chip function verification method and device, readable storage medium and electronic equipment | |
| CN112444731B (en) | Chip testing method and device, processor chip and server | |
| CN114117977B (en) | Method suitable for automatically verifying processor system scene | |
| CN111967209A (en) | SOC simulation verification method and device and storage medium | |
| CN115952758A (en) | Chip verification method and device, electronic equipment and storage medium | |
| CN103365772B (en) | Software test automatic evaluation device and method | |
| CN111400169A (en) | Method and system for automatically generating netlist file for testing software and hardware | |
| CN112560372B (en) | Chip prototype verification method, device, equipment and medium | |
| CN114218882A (en) | SoC chip inspection method, device and related equipment | |
| CN116932412B (en) | Sharing platform and method capable of generating test excitation files with different formats | |
| CN116227398B (en) | Method and system for automatically generating IP core test stimulus | |
| CN116719729A (en) | Universal verification platform, universal verification method, medium and electronic equipment | |
| US20030025490A1 (en) | Method for verifying hardware circuits through simulation | |
| CN113204939A (en) | Full-chip simulation verification method | |
| KR100939642B1 (en) | Test device generating stimulus based on software, method for testing using the same and computer-readable storage medium storged program for generating the stimulus | |
| CN111258838B (en) | Verification component generation method, device, storage medium and verification platform | |
| EP3734491A1 (en) | Method, apparatus, device, and medium for implementing simulator | |
| JP2013020425A (en) | Hardware and software cooperative verification method using open source software | |
| CN117094269B (en) | Verification method, verification device, electronic equipment and readable storage medium | |
| CN109800155B (en) | Method and device for testing QTE interlocking application software based on Probe |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |