Automatic IO test method and system applied to FPGA chip

Abstract

The invention relates to the technical field of integrated circuits, in particular to an automatic IO test method and system applied to an FPGA chip, and the method comprises the steps: obtaining a pin layout corresponding to a packaging type and an electrical standard corresponding to an IO type, quoting IO information, generating an engineering file and a constraint file of a test type according to the pin layout and the electrical standard, and in an EDA tool environment, generating a test file according to the engineering file and the constraint file. The method comprises the following steps: setting a chip model according to an FPGA chip model and a packaging type, introducing an engineering file and a constraint file for integration and implementation to obtain a log, judging whether a code point can be correctly generated according to the log, and if an error or a serious warning occurs during generation, debugging a test type until the code point can be correctly generated. And transcoding the correct code point into a machine test AVC file, generating a test vector file according to the constraint file, and carrying out ATE machine test according to the machine test AVC file, the test vector file and the test port information. According to the invention, the IO test efficiency of the current FPGA chip can be improved.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit technology, and in particular to an automated I / O testing method and system for FPGA chips. Background Technology

[0002] In integrated circuits, the I / O interface circuit of an FPGA (Field-Programmable Gate Array) is the key physical interface for data interaction between the FPGA chip and external circuits. In FPGA chips, ComboIO (Combined Input / Output Interface) mainly includes two types: HRIO (High Range I / O) and HPIO (High Performance I / O). Each type has its own unique interface standard and characteristics. To adapt to various application scenarios, ComboIO is compatible with dozens of level standards and more than a dozen characteristics, which brings significant challenges to chip production and testing.

[0003] The closest prior art invention publication number is CN111338326B, entitled "A device and method for testing a general FPGA I / O interface". However, this invention does not disclose an automated code stream and vector file generation system for FPGA chip ComboIO testing.

[0004] In traditional manual or semi-automatic process testing, in order to fully cover each level standard and port characteristic, it is necessary to build a test project and corresponding test vector for each level standard. This is a huge project that is time-consuming and prone to errors. Therefore, the current IO testing methods for FPGA chips have the problem of low testing efficiency. Summary of the Invention

[0005] This invention provides an automated I / O testing method and system for FPGA chips, the main purpose of which is to improve the I / O testing efficiency of current FPGA chips.

[0006] To achieve the above objectives, the present invention provides an automated I / O testing method for FPGA chips, comprising:

[0007] The system receives user input of the FPGA chip model, package type, IO type, and test type, and obtains IO information, including: number of banks, number of IOs, and number of IO categories.

[0008] Obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type based on the pin layout and electrical standard;

[0009] The pre-built EDA tool is run using the pre-built TCL script to obtain the EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log.

[0010] The system determines whether the preset code points can be correctly generated based on the log data.

[0011] If the code points cannot be generated correctly, the test type is debugged using the EDA tool until the correct code points are obtained.

[0012] If the code points can be generated correctly, then the correct code points are obtained;

[0013] The correct code points are converted into a preset machine test AVC file using a preset transcoding environment, a test vector file is generated according to the constraint file, and the test port information is output.

[0014] Based on the test AVC file, test vector file and test port information, perform ATE test to complete automated I / O test for FPGA chips.

[0015] Optionally, the test types include: HRIO type tests and HPIO type tests, wherein the HRIO type tests include: IO_DC test, IO_TERM test, IO_LEAKAGE test, IO_FUNC test, and IO_PULLTYPE test; and the HPIO type tests include: IO_DC test, IO_TERM test, IO_LEAKAGE test, IO_FUNC test, IO_PULLTYPE test, and IO_DCI test.

[0016] Optionally, the step of referencing the IO information and generating the project file and constraint file for the test type based on the pin layout and electrical standards includes:

[0017] Using the IO information, an RTL project corresponding to the test type is built according to the pin layout and electrical standards to obtain the project file. The RTL project is built by calling the source code of ComboIO.

[0018] Obtain the RTL project test content corresponding to the RTL project, and add ComboIO, IO level standard, ComboIO attribute, bit stream compression attribute, and other preset attributes to the constraint file according to the RTL project test content to obtain the constraint file. The ComboIO attribute includes pull-up attribute and pull-down attribute, and the other attributes include internal reference configuration.

[0019] Optionally, determining whether the preset codepoint can be correctly generated based on the log includes:

[0020] The pre-built log error warning capture program in the TCL script captures ERROR and CRITICAL WARNING information in the log log and determines whether ERROR or CRITICAL WARNING information exists in the log log.

[0021] If the log contains ERROR or CRITICAL WARNING information, code points cannot be generated correctly.

[0022] If no ERROR or CRITICAL WARNING information is found in the log, code points can be generated correctly.

[0023] Optionally, the step of debugging the test type using the EDA tool until the correct code point is obtained includes:

[0024] Based on the log, run the EDA tool to diagnose and locate faults in the test type until the correct code point is obtained.

[0025] Optionally, the step of generating a test vector file based on the constraint file and outputting test port information includes:

[0026] When the test type is IO_DC test or IO_FUNC test, the test vector is verified for the test type to obtain the test vector file for IO_DC test or the test vector file for IO_FUNC test. The test vector file for IO_DC test is divided into the following categories according to the preset level standard: single-ended IO test vector, IO test vector with external reference voltage, and differential level IO test vector.

[0027] Output test port information according to the test type.

[0028] Optionally, after generating the test vector file based on the constraint file and outputting the test port information, the method further includes:

[0029] When the test type is IO_TERM test, IO_LEAKAGE test, IO_PULLTYPE test, or IO_DCI test, the test port and Limit value are set on the pre-built ATE machine according to the test port information.

[0030] Optionally, the test vectors for the single-ended IO include: test vectors for the LVCMOS12 level standard, test vectors for the LVCMOS15 level standard, and test vectors for the LVCMOS18 level standard;

[0031] The IO test vectors with external reference voltage include: test vectors for SSTL level standards, test vectors for HSTL level standards, and test vectors for HSUL level standards;

[0032] The differential level IO test vectors include: test vectors for the DIFF_SSTL level standard, test vectors for the DIFF_HSTL level standard, and test vectors for the LVDS level standard.

[0033] Optionally, the IO_DC test includes: LVCMOS12 level standard test;

[0034] The IO_TERM test includes: terminating resistor test and differential resistor test. The level configuration standard for the terminating resistor test is SSTL_18 level standard, and the level configuration standard for the differential resistor test is LVDS25 level standard.

[0035] The IO_LEAKAGE test includes: high voltage leakage test, and the level configuration standard for the high voltage leakage test is LVCMOS33;

[0036] The IO_FUNC test includes: the IBUFDISABLE test;

[0037] The IO_PULLTYPE test includes: weak pull-up current test of LVCMOS33;

[0038] IO_DCI testing includes: source-side matching resistor testing.

[0039] To achieve the above objectives, the present invention also provides an automated I / O testing system for FPGA chips, comprising:

[0040] The project file and constraint file generation module is used to receive the FPGA chip model, package type, IO type and test type input by the user, obtain IO information, wherein the IO information includes: number of banks, number of IOs, number of IO categories; obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type according to the pin layout and electrical standard;

[0041] The log acquisition module is used to run a pre-built EDA tool using a pre-built TCL script to obtain an EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log.

[0042] The correct code point acquisition module is used to determine whether the preset code point can be correctly generated based on the log; if the code point cannot be correctly generated, the test type is debugged according to the EDA tool until the correct code point is obtained; if the code point can be correctly generated, the correct code point is acquired.

[0043] The ATE (Automatic Test Equipment) module is used to transcode the correct code points into a preset test AVC file using a preset transcoding environment, generate a test vector file based on the constraint file, and output test port information; and perform ATE test based on the test AVC file, test vector file, and test port information.

[0044] To address the above problems, the present invention also provides an electronic device, the electronic device comprising:

[0045] A memory that stores at least one instruction; and a processor that executes the instructions stored in the memory to implement the automated I / O testing method for FPGA chips described above.

[0046] To address the aforementioned issues, the present invention also provides a computer-readable storage medium storing at least one instruction, which is executed by a processor in an electronic device to implement the aforementioned automated I / O testing method for FPGA chips.

[0047] To address the problems described in the background art, this invention first requires generating project files and constraint files for each test type. Since these files are closely related to I / O information, pin layout, and electrical standards, it is necessary to first receive the user's input of the FPGA chip model, package type, I / O type, and test type, and then obtain the I / O information, including the number of banks, the number of I / Os, and the number of I / O categories. Next, the pin layout corresponding to the package type and the electrical standards corresponding to the I / O type are obtained. At this point, the I / O information can be referenced, and project files and constraint files for each test type can be generated based on the pin layout and electrical standards. Since correct code points need to be generated, and correct code points can be determined based on log data, it is necessary to first run an EDA tool using a TCL script to obtain the EDA code points. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type. Finally, the project file and constraint file are referenced for synthesis and implementation to obtain the log. At this point, it is necessary to determine whether code points can be correctly generated based on the log. If code points cannot be correctly generated, the test type can be debugged using the EDA tool until the correct code points are obtained. If code points can be correctly generated, they are directly obtained. After obtaining the correct code points, ATE (Automatic Test Equipment) testing is required. Specifically, the correct code points are first converted into a preset ATE test AVC file using a transcoding environment. Then, a test vector file is generated according to the constraint file, and test port information is output. Finally, ATE test is performed based on the ATE test AVC file, test vector file, and test port information. Therefore, this invention can improve the IO testing efficiency of current FPGA chips. Attached Figure Description

[0048] Figure 1 This is a flowchart illustrating an automated I / O testing method for FPGA chips according to an embodiment of the present invention.

[0049] Figure 2 A flowchart illustrating the automated generation process of code points and test vector files according to an embodiment of the present invention;

[0050] Figure 3 This is a schematic diagram of user request reception provided in an embodiment of the present invention;

[0051] Figure 4 A functional block diagram of an automated I / O testing system for FPGA chips provided in an embodiment of the present invention;

[0052] Figure 5 This is a schematic diagram of the structure of an electronic device that implements the automated I / O testing method for FPGA chips, according to an embodiment of the present invention.

[0053] Explanation of reference numerals in the attached figures:

[0054] 10. Electronic device; 11. Processor; 12. Memory; 13. Bus.

[0055] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0056] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0057] This application provides an automated I / O testing method for FPGA chips. The executing entity of the automated I / O testing method for FPGA chips includes, but is not limited to, at least one of the following electronic devices that can be configured to execute the method provided in this application: a server, a terminal, etc. In other words, the automated I / O testing method for FPGA chips can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cloud server cluster.

[0058] Reference Figure 1 The diagram shown is a flowchart illustrating an automated I / O testing method for FPGA chips according to an embodiment of the present invention. In this embodiment, the automated I / O testing method for FPGA chips includes:

[0059] S1. Receive the FPGA chip model, package type, IO type and test type input by the user, and obtain IO information, wherein the IO information includes: number of banks, number of IOs, and number of IO categories.

[0060] Understandably, the FPGA chip model refers to a standardized device identifier used to precisely describe the intrinsic logic characteristics of the FPGA chip. The package type refers to a standardized device identifier that uniquely identifies the package form, number of pins, physical size, and pin layout of the FPGA chip. The I / O type refers to a predefined electrical specification used to define a series of electrical characteristics of the FPGA chip's physical pins when used as inputs or outputs, including signal voltage, current, reference level, and termination method.

[0061] Furthermore, the test type refers to a structured command used to specify one or more IO functional characteristics or electrical parameters that need to be verified, which determines the RTL design, constraint file, and ATE test program that the system should automatically generate. The IO information refers to a set of statistical data on the quantity and distribution of the chip's physical IO resources automatically extracted by the system after determining the FPGA chip model and package type. The number of banks refers to the total number of user IO pins physically divided into independent power supply groups under the given FPGA chip model and package type. The number of IOs refers to the total number of input / output pins that can be freely configured and used by the user under the given FPGA chip model and package type. The number of IO categories refers to the specific number of each category after classifying the total number of IO pins according to their physical capabilities and supported signal types.

[0062] For example, the I / O information for a certain chip model is shown below:

[0063] IO_Bank=5# There are a total of 5 banks;

[0064] IO_BANK=5 # A total of 5 banks;

[0065] IO_ALL=250 # There are a total of 250 IO ports in the 5 banks;

[0066] IO_EXVREF=10 # There are a total of 10 external reference I / O ports in the 5 banks;

[0067] IO_TOPSING=5 # The top IO in each Bank is a single-ended IO, so there are 5 top single-ended IOs;

[0068] IO_BOTSING=5 # The bottom IO in each Bank is a single-ended IO, so there are 5 bottom single-ended IOs;

[0069] IO_SING=$((IO_ALL)) # All IOs can be used as single-ended IOs;

[0070] IO_SING_VREF=$(((IO_ALL-IO_EXVREF))) # If an external reference voltage input is used, the total number of reference IOs that can be used = the total number of IOs - the number of external reference IOs.

[0071] IO_DIFF=$(((IO_ALL-IO_TOPSING-IO_BOTSING))) # The number of differential IOs that can be used = the total number of IOs - the top single-ended IOs - the bottom single-ended IOs.

[0072] In this embodiment of the invention, the test types include: HRIO type test and HPIO type test, wherein the HRIO type test includes: IO_DC test, IO_TERM test, IO_LEAKAGE test, IO_FUNC test, and IO_PULLTYPE test; and the HPIO type test includes: IO_DC test, IO_TERM test, IO_LEAKAGE test, IO_FUNC test, IO_PULLTYPE test, and IO_DCI test.

[0073] For a detailed diagram illustrating the user request reception process, please refer to [link / reference]. Figure 3 As shown. The HRIO type test refers to the electrical characteristics and functional compliance verification of a specific IO bank for High Range I / O (HRIO). An IO Bank refers to the basic unit on an FPGA chip that groups and manages physical input / output (IO) pins. A High Range I / O refers to an IO bank whose power supply supports a wide operating voltage range of 1.2V-3.3V, and internally includes modules for high voltage detection and withstand voltage protection. The HPIO type test refers to the electrical characteristics and functional compliance verification of a specific IO bank for High Performance I / O (HPIO). A High Performance I / O refers to a high-performance ComboIO pin optimized for high-speed applications, whose IO bank operates at a voltage range of 1.2V-1.8V and internally includes digitally controlled impedance and voltage equalization modules. A ComboIO refers to a combined input / output interface, i.e., configurable IO resources on an FPGA chip. ComboIO is a key interface for interaction between the chip and external devices, responsible for signal input, output, and processing. IO configuration directly affects system performance, signal integrity, and reliability.

[0074] Furthermore, the IO_DC test (IO DC characteristic test) refers to a comprehensive test used to verify whether the basic, static DC electrical parameters of the FPGA chip's IO pins conform to the JEDEC (Solid State Technology Association) specifications when following a specific level standard (such as LVCMOS12). The level standard refers to the rules defining the high and low voltage ranges in the circuit, its core being the differentiation of the logic states (0 / 1) of digital signals, and is the basis for compatibility between chips, interfaces, and communication protocols. Compatible level standards in FPGAs include LVCMOS, SSTL, HSTL, DIFF_SSTL, DIFF_HSTL, LVDS, and TMDS. The IO_DC test includes: input buffer IBUF test and output buffer OBUF test. When performing the input buffer IBUF test, it is necessary to test its input low voltage VIL and input high voltage VIH to ensure the correctness of its input signal recognition. When performing the output buffer OBUF test, under the load condition of meeting the specified output drive current (output low current IOL, output high current IOH), its output low voltage VOL and output high voltage VOH are measured.

[0075] In detail, the IO_TERM test (IO termination resistance test) refers to the test used to verify the accuracy of the resistance value of the programmable on-chip termination resistor integrated inside the FPGA chip's IO module. The IO_TERM test only measures the termination characteristics of the chip's input terminals. The IO_TERM test is used to test the terminating resistor or differential resistor of the ComboIO.

[0076] Explained, the IO_LEAKAGE test (IO leakage current test) refers to a parameter test used to measure the unexpected, minute DC current flowing into or out of the IO pins of an FPGA chip in static (non-switching) mode. The IO_LEAKAGE test is used to test the leakage current of the ComboIO pad during pull-up and pull-down operations.

[0077] Furthermore, the IO_FUNC test (IO function characteristic test) refers to a digital function test used to verify whether the special control functions or logic characteristics of the FPGA IO module work as expected. The IO_FUNC test is used to test the functions of IO, including IBUFDISABLE (configuration attribute of the control input buffer (IBUF) enable / disable state), KEEPER (hold attribute of the IO port), INTERVREF (internal reference voltage attribute), OBUFT (tri-state attribute of OBUF), etc.

[0078] It should be understood that the IO_PULLTYPE test (IO pull-up / pull-down function test) refers to a digital function and parameter mixing test used to verify whether the programmable weak pull-up / pull-down resistor function integrated inside the FPGA IO module is functioning correctly. The IO_PULLTYPE test is used to test the current value of the ComboIO when configured with weak pull-up or weak pull-down.

[0079] Understandably, the IO_DCI test (Digitally Controlled Impedance test) refers to a comprehensive test specifically designed to verify the accuracy and collaborative working ability of the advanced digitally controlled impedance (DCI) function in Xilinx FPGAs. The IO_DCI test is used to test the matching resistor value for the digitally controlled impedance matching in the IO.

[0080] In this embodiment of the invention, the IO_DC test includes: LVCMOS12 level standard test;

[0081] The IO_TERM test includes: terminating resistor test and differential resistor test. The level configuration standard for the terminating resistor test is SSTL_18 level standard, and the level configuration standard for the differential resistor test is LVDS25 level standard.

[0082] The IO_LEAKAGE test includes: high voltage leakage test, and the level configuration standard for the high voltage leakage test is LVCMOS33;

[0083] The IO_FUNC test includes: the IBUFDISABLE test;

[0084] The IO_PULLTYPE test includes: weak pull-up current test of LVCMOS33;

[0085] IO_DCI testing includes: source-side matching resistor testing.

[0086] Furthermore, the terminating resistor test is used to verify whether the resistance value of the on-chip parallel terminating resistor provided by the FPGA IO module for the single-ended signal standard conforms to the nominal value. The differential resistor test is used to verify whether the resistance value of the on-chip differential terminating resistor provided by the FPGA IO module for the differential signal standard, connected across the differential pair (P / N) pins, conforms to the nominal value. The LVCMOS12 level standard test refers to the test using ATE to verify whether the DC electrical parameters of the FPGA chip's IO pins strictly conform to the specifications defined by JEDEC when configured to the LVCMOS12 level standard. The SSTL_18 level standard refers to the reference voltage type single-ended signal IO standard defined by JEDEC specifically designed for high-speed memory interfaces such as DDR2 SDRAM, with an operating power supply voltage of 1.8V. The LVDS25 level standard refers to the low-voltage differential signal interface technology defined by the ANSI / TIA / EIA-644 standard, using a 2.5V power supply, to transmit data at high speed, low power consumption, and with high interference immunity through a pair of inverted transmission lines.

[0087] In detail, the high-voltage leakage test refers to the test of measuring DC leakage current by applying a DC voltage higher than the normal rated operating voltage to the IO pin. LVCMOS33 refers to the low-voltage CMOS digital signal interface standard defined by JEDEC that uses a 3.3V power supply. The IBUFDISABLE test verifies the IBUFDISABLE configurable attribute of the FPGA IO module. The LVCMOS33 weak pull-up current test verifies whether the programmable weak pull-up resistor function inside the IO pin configured as an LVCMOS33 standard can function properly and generate a pull-up current within the specification range when enabled. The source-end matching resistor test verifies whether the actual resistance value of the programmable series terminating resistor integrated inside the FPGA output driver conforms to the nominal value in the DC parameter characterization test.

[0088] S2. Obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type based on the pin layout and electrical standard.

[0089] Understandably, the pin layout refers to the physical mapping layout of logic function ports and physical pins on an FPGA chip. The electrical standards refer to the electrical standards defining the voltage, current, etc., of I / O pins during signal transmission. The project files refer to files created and managed by EDA tools that organize, manage, and track relevant source files, configuration information, and tool settings for a specific FPGA design project. The constraint files refer to text files that convey specific requirements for the physical implementation and performance timing of the FPGA to the EDA tools.

[0090] In this embodiment of the invention, the step of referencing the IO information and generating the project file and constraint file for the test type based on the pin layout and electrical standards includes:

[0091] Using the IO information, an RTL project corresponding to the test type is built according to the pin layout and electrical standards to obtain the project file. The RTL project is built by calling the source code of ComboIO.

[0092] Obtain the RTL project test content corresponding to the RTL project, and add ComboIO, IO level standard, ComboIO attribute, bit stream compression attribute, and other preset attributes to the constraint file according to the RTL project test content to obtain the constraint file. The ComboIO attribute includes pull-up attribute and pull-down attribute, and the other attributes include internal reference configuration.

[0093] Understandably, the RTL (Register Transfer Level) project refers to a collection of source code used in a hardware description language to construct the logic function of a digital system by describing the transfer and processing behavior of data between registers in a digital circuit. The project file refers to a project index file created by EDA tools that records and manages the resources required for each test type. The RTL project test content refers to the key information generated by parsing the guidance constraint file obtained from the RTL project. The ComboIO of the constraint file refers to the portion of the constraint file that is associated with the physical location of the I / O ports, used to represent pin assignment constraints. The I / O level standard refers to the electrical behavior specification of the I / O ports in the constraint file. The ComboIO attribute refers to the additional attributes set for the I / O ports in the constraint file to control their internal high-level functions or specific behaviors. The bitstream compression attribute refers to the project settings used to optimize the size of the generated code point file. The internal reference configuration refers to the specific attributes used to enable and set the internal reference voltage generator of the FPGA chip. The source term refers to the lowest level, most basic, and indivisible hardware functional unit in the FPGA design library.

[0094] Understandably, when generating project files for each test type by referencing IO information, a script is needed to create an RTL project for each test type to ensure that the generated test plan can verify every available user IO pin on the FPGA chip.

[0095] Furthermore, when the test type is IO_DC test, the RTL project can be as follows: When performing LVCMOS12 level standard test, in order to achieve efficient parallel testing, the 250 packaged IOs are divided into two groups, and 125 independent input / output pairs (I / O pairs) are constructed. Each output / output pair consists of an IO from the first group (configured as an input) and an IO from the second group (configured as an output), thereby enabling parallel driving and measurement on the AET (Automatic Test Equipment).

[0096] Specifically, all 250 encapsulated IOs are divided into input[124:0] and output[124:0]. Then, input[i] and output[i] are combined into a pair of input and output pairs, for a total of 125 input and output pairs. At this time, the input low level VIL and input high level VIH of each input are tested, and the output low level VOL, output high level VOH, output low current IOL, and output high current IOH of each output are tested.

[0097] In detail, LVCMOS12 level standard testing is divided into forward test mode and reverse test mode. In forward test mode, for each I / O pair, one pin is configured as an input and the other as an output. The ATE performs VIL / VIH parameter tests on the pin configured as an input, and simultaneously performs VOL / VOH parameter tests on the pin configured as an output under specified IOL / IOH load conditions. In reverse test mode, the I / O pairs in the forward test mode are reversed, and the parameter tests in the forward test mode are performed again. It can be understood that LVCMOS12 level standard testing is divided into two types: the first is liuo (lower input and upper output) testing, where in each input / output pair, the lower pad is used as the input and the upper pad as the output; the second is uilo (upper input and lower output) testing, where in each input / output pair, the upper pad is used as the input and the lower pad as the output. The pad refers to the outermost physical metal interface on the FPGA chip that can be directly contacted by the ATE's probes or sockets.

[0098] In detail, when the test type is IO_TERM test, the RTL project should refer to the following: IO_TERM test is divided into termination resistance test and differential resistance test. In the termination resistance test, taking the SSTL_18 level standard as an example, all single-ended IOs (IO_SING) need to be configured to use the 250 input ports of the SSTL_18 level standard with internal reference voltage (the 250 input ports can be represented as input[249:0]). Different internal termination resistance attributes should be applied to all single-ended IOs under test. The internal termination resistance attribute can be INTERM_40 / 50 / 60, which correspond to the nominal values ​​of 40 / 50 / 60 ohms respectively (i.e., internal termination resistance 40 / 50 / 60 ohms). Each project tests the termination resistance of all IOs. In differential resistance testing, taking the LVDS25 level standard as an example, all 240 IO_DIFF (differential pair IO) need to be configured to the LVDS25 level standard. The 240 IO_DIFF can be represented as inputn[119:0], inputp[119:0], which can measure the IO termination resistance of all DIFF.

[0099] Furthermore, when the test type is IO_LEAKAGE test, the RTL project can refer to the following: Taking high-voltage leakage current test as an example, during the test, firstly, two independent test projects are created through an automated process, configuring the 250 IO pins under test in either the tri-state input (IBUF) mode or the high-impedance output (OBUF Tri-stated) mode under the LVCMOS33 standard. Subsequently, for each configuration, the ATE will sequentially apply a DC voltage of 3.465V (high-voltage stress) and 0V to all IO pads, and accurately measure the DC leakage current flowing through the pads under each voltage condition to ensure that its value is within the specification range.

[0100] Understandably, when the test type is IO_FUNC test, the RTL project can refer to the following: Taking the IBUFDISABLE test as an example, the 250 IOs are tested in two sessions. In the first test, 247 of the IOs are configured as SSTL_18 level standard inputs with ibufdisable function, i.e., input[246:0]; one ibufdisable port is configured; one AND logic output port out_and is configured, i.e., the AND output of all input ports; and one OR logic output port out_or is configured, i.e., the OR output of all input ports. In the second test, the ibufdisable port, out_and port, and out_or port verified in the first test are configured as SSTL_18 level standard inputs with ibufdisable function, and three other ports are selected and configured as ibufdisable ports, out_and ports, and out_or ports.

[0101] In detail, when the test type is IO_PULLTYPE test, the RTL project can refer to the following: Taking the weak pull-up current test of LVCMOS33 as an example, 250 ComboIOs need to be configured as tri-state input ports of LVCMOS33 level standard and pull-up function needs to be configured. During the test, the pad is grounded and the pad current is measured.

[0102] Furthermore, when the test type is IO_DCI test, the RTL project can refer to the following: Taking the source-side matching resistor test as an example, 247 of the 250 IOs need to be configured as LVDCI_18 level output ports. Two of the remaining three IOs are top and bottom IO calibration ports, and there is one input port. The outputs of all 247 output ports (output[246:0]) are equal to the values ​​of the input ports. During measurement, a calibration resistor needs to be connected to the IO calibration port. A voltage of VCCO / 2 is applied to the pads of the 247 output ports (output[246:0]). Inputs 0 and 1 respectively at the input ports (input). The current is measured when the output is high and low, and then the resistance value is calculated using the voltage / current ratio.

[0103] In detail, when the test type is IO_DC test, the constraint file can refer to the following: In the IO_DC test of LVCMOS12 level standard, the physical location allocation of the ports needs to be performed first. The 125 input ports and 125 output ports defined in the RTL project are mapped to the physical pins of the FPGA respectively. Specifically, the constraint ports of input[124:0] and output[124:0] need to be added in sequence. Then, the voltage standard of these constraint ports is set to the LVCMOS12 level standard. Specifically, input[124:0] and output[124:0] can be added in sequence to obtain the voltage standard of LVCMOS12. During the construction of the constraint file, it should be noted that the test ports of liuo and uilo are reversed.

[0104] Explained, when the test type is IO_TERM test, the constraint file can refer to the following: When generating the constraint file for IO_TERM test, the process will apply different rules depending on the test sub-item. Specifically, when the test sub-item is terminating resistor test, firstly, pin assignments need to be performed for the 250 input ports, and their level standard needs to be set to SSTL_18 level. Subsequently, the internal reference voltage (INTERNAL_VREF) is enabled, and the corresponding INTERM attributes are iteratively added according to the test target (such as 40 / 50 / 60 ohms). Specifically, first, input[249:0] is added sequentially. First, constrain the ports, then add the input[i] level standard to SSTL_18 level, finally add the internal reference voltage, and add the INTERM_40 / 50 / 60 attribute; when the test item is differential resistance test, it is necessary to first assign pins to the 120 pairs of differential ports and set their level standard to LVDS25, and enable the built-in ohmic terminating resistor of each pair of differential input terminals by adding the DIFF_TERM="TRUE" attribute. Specifically, first add the constrained ports of inputn[119:0] and inputp[119:0] in sequence, then add the level standard of inputn[119:0] and inputp[119:0] to LVDS25, and finally add the DIFF_TERM attribute.

[0105] Furthermore, when the test type is IO_LEAKAGE test, the constraint file can refer to the following: When generating the constraint file for IO_LEAKAGE test, it is necessary to first map all logic ports to the physical pins of the FPGA through port physical location allocation, and then uniformly set the voltage standard of the logic ports to LVCMOS33. Specifically, it is necessary to add the constraint ports of input[249:0] in sequence, and then add the voltage standard of input[249:0] to LVCMOS33 in sequence.

[0106] It should be understood that when the test type is IO_FUNC test, the constraint file can refer to the following: When generating the constraint file for IO_FUNC test, the first test requires physical pin assignment to the ports in the RTL project (e.g., input[246:0], ibufdisable port, out_and / out_or port), then setting the port voltage standard to SSTL_18, automatically adding the corresponding internal reference voltage configuration, and adding the IBUFDISABLE attribute. Specifically, the first test requires adding the constraint ports for input[246:0], ibufdisable, out_and, and out_or in sequence; then adding the voltage standard to SSTL_18 in sequence; finally adding the internal reference voltage and adding the IBUFDISABLE attribute. The second test will repeat the same constraint logic, only rotating the port roles during the physical pin assignment stage.

[0107] In detail, when the test type is IO_PULLTYPE test, the constraint file can refer to the following: When generating the constraint file for IO_PULLTYPE test, it is necessary to first perform physical pin assignment on the 250 input ports under test, then set the voltage standard of these input ports under test to LVCMOS33, and finally add the PULLTYPE=PULL_UP attribute. Specifically, it is necessary to add the constraint ports of input[249:0] in sequence, then add the voltage standard of LVCMOS33 in sequence, and finally add the PULLTYPE=PULL_UP attribute.

[0108] It should be explained that when the test type is IO_DCI test, the constraint file can refer to the following: When generating the constraint file for IO_DCI test, it is necessary to first assign physical pins to different ports: including 247 output ports under test, 1 driver input port, and reserve two reference pins for DCI calibration. In terms of electrical standard settings, the voltage standard of the output port under test is configured as LVDCI_18, while the level standard of the driver input port is configured as LVCMOS18. Specifically, in the IO_DCI test of LVCMOS12: first add the constraint ports of output[246:0] and input in sequence, then add the voltage standard of output[246:0] as LVDCI_18 and the level standard of input as LVCMOS18 in sequence, the reference IO is not configured, and finally configure the DCI cascading attribute to cascade the DCI of each bank.

[0109] S3. Run the pre-built EDA tool using the pre-built TCL script to obtain the EDA tool environment. In the EDA tool environment, set the chip model according to the FPGA chip model and package type, and use the project file and constraint file to perform synthesis and implementation to obtain the log.

[0110] In this embodiment of the invention, the TCL (Tool Command Language) script refers to a TCL language command text file containing the entire automated build and verification process. The EDA tool refers to a software suite for FPGA design, synthesis, implementation, and verification; it is an FPGA adaptive SoC design suite. The EDA tool is a highly integrated development environment covering the entire hardware development process from design input, synthesis, implementation (placement and routing) to verification and debugging. The EDA tool environment refers to a working environment created in computer memory after the TCL script starts the EDA tool, containing a complete project context and capable of executing subsequent commands. Synthesis refers to converting the hardware description language into a logic connection diagram composed of the FPGA's underlying logic units. Specifically, it translates abstract RTL code into a basic hardware resource connection netlist for the corresponding device, only solving functional mapping and not concerning physical location; it is a "logic-level translation." The implementation refers to assigning a specific physical location to each logic unit according to the logic connection diagram, and connecting the logic units with physical routing resources. By actually placing the synthesized netlist onto the physical units of the FPGA / chip, placement and routing are completed, solving the physical landing problem, while ensuring timing convergence. This is the "physical-level landing." The log refers to a text file automatically generated during the synthesis and implementation process of the EDA tool, recording operations, status information, warnings, and errors.

[0111] In detail, for each test type, the following steps can be completed using a TCL script: open the EDA tool, set the FPGA chip model, reference the RTL project file, reference the RTL constraint file, synthesize, implement, and generate the corresponding code points.

[0112] S4. Determine whether the preset code points can be correctly generated based on the log.

[0113] Explained, the code point refers to the final binary bitstream configuration file that carries complete FPGA design information and can be directly used to configure the physical chip. It contains a binary dataset containing all the information needed to configure the FPGA for a specific hardware function.

[0114] In this embodiment of the invention, determining whether a preset code point can be correctly generated based on the log includes:

[0115] The pre-built log error warning capture program in the TCL script captures ERROR and CRITICAL WARNING information in the log log and determines whether ERROR or CRITICAL WARNING information exists in the log log.

[0116] If the log contains ERROR or CRITICAL WARNING information, code points cannot be generated correctly.

[0117] If no ERROR or CRITICAL WARNING information is found in the log, code points can be generated correctly.

[0118] Explained, the log error warning capture program refers to a subroutine code specifically written within the TCL script for text processing and pattern matching. Its core function is to automatically and programmatically check the log file and search for and extract predefined keywords that indicate problems in the build process. The ERROR message refers to a high-priority error report printed in the log file when the EDA tool encounters an unmanageable or unrecoverable problem during execution. The CRITICAL WARNING message refers to a second-highest priority warning report printed in the log file when the EDA tool discovers a very serious design problem that is highly likely to cause final hardware failure or performance degradation.

[0119] Furthermore, the TCL script can incorporate bionic code for simulation. A log error warning capture program can be written into the TCL script to capture ERROR and CRITICAL WARNING information from the log, so as to determine whether the program is running normally during the code point generation process.

[0120] If code points cannot be generated correctly, then execute S5 to debug the test type according to the EDA tool until the correct code points are obtained.

[0121] Explained, the correct code point refers to a code point whose generation process and final result fully meet all preset quality standards.

[0122] In this embodiment of the invention, the step of debugging the test type using the EDA tool until the correct code point is obtained includes:

[0123] Based on the log, run the EDA tool to diagnose and locate faults in the test type until the correct code point is obtained.

[0124] Understandably, after all code points in the test projects have been generated, the log information captured by the log error warning capture program can be used to check whether any error messages and critical warning messages (ERROR and CRITICAL WARNING) occurred during the code point generation process. If there are error messages and critical warning messages, the log file can be viewed and EDA tools can be run to diagnose the test type that malfunctioned. If there are no error messages and critical warning messages, the subsequent steps can be continued.

[0125] If the code points can be generated correctly, then execute S6 to obtain the correct code points.

[0126] Understandably, if code points can be generated correctly, i.e., the log file contains no error messages or critical warning messages, then the generated code points can be considered correct code points.

[0127] S7. Using a preset transcoding environment, the correct code points are transcoded into a preset machine test AVC file, a test vector file is generated according to the constraint file, and the test port information is output.

[0128] Understandably, the transcoding environment refers to a set of software tools, scripts, and predefined libraries used to parse FPGA design products and translate them into a format recognizable by ATE (Automatic Test Equipment). The machine test AVC file (AutoVoltage Calibration File) refers to a test vector file in ASCII text format specific to ATE test equipment. Input files required for ATE test equipment testing include AVC files with correct code points and vector AVC files. The test vector file refers to a file containing test stimuli and expected response information captured from RTL functional simulation for verifying circuit logic functionality. The test port information refers to a mapping file, also known as a PINMAP file, that establishes the connection relationship between logic signal names and physical channels on the ATE test head and physical pins of the device under test (DUT).

[0129] In this embodiment of the invention, generating a test vector file based on the constraint file and outputting test port information includes:

[0130] When the test type is IO_DC test or IO_FUNC test, the test vector is verified for the test type to obtain the test vector file for IO_DC test or the test vector file for IO_FUNC test. The test vector file for IO_DC test is divided into the following categories according to the preset level standard: single-ended IO test vector, IO test vector with external reference voltage, and differential level IO test vector.

[0131] Output test port information according to the test type.

[0132] Understandably, the test vector verification refers to a testing method based on test stimuli and expected response information. The specific process is as follows: The ATE (Automatic Test Equipment) drives a series of dynamically changing digital signals (test stimuli) to the input pins of the FPGA according to the timing and code pattern in the test AVC file. Simultaneously or shortly thereafter, the ATE samples the output pins of the FPGA and compares the captured signals with the expected response defined in the test vector file. During ATE testing, by applying test vectors (vector signals) to the FPGA chip, the chip's response output is tested and compared with the expected result to determine whether the chip meets the specifications.

[0133] Furthermore, the test vector file for the IO_DC test is a set of ATE test programs specifically designed to verify the DC characteristics of IO (such as VIL / VIH, VOL / VOH), and the test vector file for the IO_FUNC test refers to a set of ATE test programs specifically designed to verify the specific digital logic functions of IO (such as IBUFDISABLE).

[0134] Specifically, the single-ended I / O test vector refers to a general test vector template designed for single-ended, rail-to-rail I / O standards such as LVCMOS. The I / O test vector with external reference voltage refers to a test vector template designed for reference voltage type I / O standards such as SSTL, HSTL, and HSUL. The differential level I / O test vector refers to a test vector template designed for differential I / O standards such as LVDS and DIFF_SSTL.

[0135] In this embodiment of the invention, the test vector of the single-ended IO includes: test vector of LVCMOS12 level standard, test vector of LVCMOS15 level standard, and test vector of LVCMOS18 level standard;

[0136] The IO test vectors with external reference voltage include: test vectors for SSTL level standards, test vectors for HSTL level standards, and test vectors for HSUL level standards;

[0137] The differential level IO test vectors include: test vectors for the DIFF_SSTL level standard, test vectors for the DIFF_HSTL level standard, and test vectors for the LVDS level standard.

[0138] Specifically, the test vectors for the LVCMOS12 level standard refer to ATE test programs whose internal voltage parameters are set to conform to the LVCMOS12 specification. The test vectors for the LVCMOS15 level standard refer to ATE test programs whose internal voltage parameters are set to conform to the LVCMOS15 specification. The test vectors for the LVCMOS18 level standard refer to ATE test programs specifically customized for the LVCMOS18 specification. The test vectors for the SSTL level standard refer to ATE test programs designed specifically for the SSTL (StubSeries Terminated Logic) series standards (such as SSTL_18 and SSTL_15). The test vectors for the HSTL level standard refer to ATE test programs designed specifically for the HSTL (High-Speed ​​Transceiver Logic) series standards, commonly used in high-performance communications. The test vectors for the HSUL level standard refer to ATE test programs designed specifically for the HSUL (High-Speed ​​Unterminated Logic) series standards. The test vectors for the DIFF_SSTL level standard refer to differential versions of the SSTL level standard test vectors, designed specifically for clock and strobe signals of DDR memory. The test vectors for the DIFF_HSTL level standard refer to differential versions of the HSTL level standard test vectors. The test vector of the LVDS level standard refers to the ATE test program designed specifically for the LVDS (Low-Voltage Differential Signaling) standard, which is the most widely used differential standard.

[0139] In this embodiment of the invention, after generating the test vector file based on the constraint file and outputting the test port information, the method further includes:

[0140] When the test type is IO_TERM test, IO_LEAKAGE test, IO_PULLTYPE test, or IO_DCI test, the test port and Limit value are set on the pre-built ATE machine according to the test port information.

[0141] Understandably, the ATE (Automatic Test Equipment) is a highly complex, computer-controlled automated testing device specifically designed for the rapid and accurate testing of the functionality, performance, and electrical characteristics of semiconductor chips during mass production. The test port refers to one or more physical pins designated as the target of a specific measurement task in the ATE test procedure. The limit value refers to the upper and lower limits of the specification pre-set for each parameter measurement in the ATE test procedure, used to determine whether the measurement passes or fails.

[0142] S8. Perform ATE machine testing based on the machine test AVC file, test vector file and test port information to complete the automated IO test applied to the FPGA chip.

[0143] Understandably, ATE (Automatic Test Equipment) testing refers to the process of using ATE to perform a series of automated electrical and functional tests on semiconductor chips based on the machine's test AVC file, test vector file, and test port information. This process filters out defective products and ensures product quality. Essentially, it is an "automatic quality inspection tool" for the entire chip development and mass production process, replacing manual labor in the comprehensive testing of chip functionality, performance, and reliability. It is an essential step for chip mass production. A flowchart of the automated generation process for FPGA chip ComboIO testing code points and test vector files can be found here. Figure 2 As shown.

[0144] This invention, through the construction of an automated I / O testing system, enables users to flexibly generate test files for ComboIO for different FPGA chip models by inputting the FPGA chip model, I / O type, test type, and package type. This reduces manual input time, improves testing efficiency, and generates logs for error information extraction. By generating code points and test vector files from hundreds of projects using the automated I / O testing system, the system becomes adaptable to FPGA chip testing with different chip models, package types, I / O types, and test types, effectively covering all I / O test items. Furthermore, since ComboIO has many external components on the EVB board during the manual screening test stage, it cannot correctly test the I / O state. Therefore, debugging on the machine is required during the Final Test Phase (FT). Using the code points and test vector files generated by the automated I / O testing system not only saves labor and time costs but also reduces the probability of human error.

[0145] To address the problems described in the background art, this invention first requires generating project files and constraint files for each test type. Since these files are closely related to I / O information, pin layout, and electrical standards, it is necessary to first receive the user's input of the FPGA chip model, package type, I / O type, and test type, and then obtain the I / O information, including the number of banks, the number of I / Os, and the number of I / O categories. Next, the pin layout corresponding to the package type and the electrical standards corresponding to the I / O type are obtained. At this point, the I / O information can be referenced, and project files and constraint files for each test type can be generated based on the pin layout and electrical standards. Since correct code points need to be generated, and correct code points can be determined based on log data, it is necessary to first run an EDA tool using a TCL script to obtain the EDA code points. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type. Finally, the project file and constraint file are referenced for synthesis and implementation to obtain the log. At this point, it is necessary to determine whether code points can be correctly generated based on the log. If code points cannot be correctly generated, the test type can be debugged using the EDA tool until the correct code points are obtained. If code points can be correctly generated, they are directly obtained. After obtaining the correct code points, ATE (Automatic Test Equipment) testing is required. Specifically, the correct code points are first converted into a preset ATE test AVC file using a transcoding environment. Then, a test vector file is generated according to the constraint file, and test port information is output. Finally, ATE test is performed based on the ATE test AVC file, test vector file, and test port information. Therefore, this invention can improve the IO testing efficiency of current FPGA chips.

[0146] like Figure 4 The diagram shown is a functional block diagram of an automated I / O testing system for FPGA chips provided in an embodiment of the present invention.

[0147] The automated I / O testing system 100 for FPGA chips described in this invention can be installed in electronic devices. Depending on the functions implemented, the automated I / O testing system 100 for FPGA chips may include a project file and constraint file generation module 101, a log acquisition module 102, a correct code point acquisition module 103, and an ATE (Automatic Test Equipment) module 104. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and which are stored in the memory of the electronic device.

[0148] The project file and constraint file generation module 101 is used to receive the FPGA chip model, package type, IO type and test type input by the user, obtain IO information, wherein the IO information includes: number of banks, number of IOs, number of IO categories; obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, refer to the IO information, and generate the project file and constraint file of the test type according to the pin layout and electrical standard;

[0149] The log acquisition module 102 is used to run a pre-built EDA tool using a pre-built TCL script to obtain an EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log.

[0150] The correct code point acquisition module 103 is used to determine whether the preset code point can be correctly generated based on the log; if the code point cannot be correctly generated, the test type is debugged according to the EDA tool until the correct code point is obtained; if the code point can be correctly generated, the correct code point is acquired.

[0151] The ATE machine test module 104 is used to transcode the correct code points into a preset machine test AVC file using a preset transcoding environment, generate a test vector file according to the constraint file, and output test port information; and perform ATE machine testing according to the machine test AVC file, test vector file, and test port information.

[0152] In detail, the modules in the automated I / O test system 100 for FPGA chips described in this embodiment of the invention employ the same methods as described above. Figure 1 The method used is the same as the automated I / O testing method for FPGA chips described in the previous section, and can produce the same technical effect, so it will not be repeated here.

[0153] like Figure 5 The diagram shown is a structural schematic of an electronic device that implements an automated I / O testing method for FPGA chips, according to an embodiment of the present invention.

[0154] The electronic device 1 may include a processor 10, a memory 11 and a bus 12, and may also include a computer program stored in the memory 11 and executable on the processor 10, such as an automated I / O test method program applied to an FPGA chip.

[0155] The memory 11 includes at least one type of readable storage medium, such as flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 can be an internal storage unit of the electronic device 1, such as a portable hard drive. In other embodiments, the memory 11 can be an external storage device of the electronic device 1, such as a plug-in portable hard drive, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on the electronic device 1. Furthermore, the memory 11 includes both internal storage units and external storage devices of the electronic device 1. The memory 11 can be used not only to store application software and various types of data installed on the electronic device 1, such as code for automated I / O testing methods applied to FPGA chips, but also to temporarily store data that has been output or will be output.

[0156] In some embodiments, the processor 10 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 10 is the control unit of the electronic device, connecting various components of the entire electronic device through various interfaces and lines. It executes programs or modules stored in the memory 11 (e.g., automated I / O testing methods for FPGA chips) and calls data stored in the memory 11 to perform various functions of the electronic device 1 and process data.

[0157] The bus 12 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 12 can be divided into an address bus, a data bus, a control bus, etc. The bus 12 is configured to realize the connection and communication between the memory 11 and at least one processor 10, etc.

[0158] Figure 5 Only electronic devices with components are shown; it will be understood by those skilled in the art that... Figure 5The structure shown does not constitute a limitation on the electronic device 1, and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0159] For example, although not shown, the electronic device 1 may also include a power supply (such as a battery) to power the various components. Preferably, the power supply can be logically connected to the at least one processor 10 through a power management device, thereby enabling functions such as charging management, discharging management, and power consumption management. The power supply may also include one or more DC or AC power supplies, recharging devices, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The electronic device 1 may also include various sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be described in detail here.

[0160] Furthermore, the electronic device 1 may also include a network interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), which is typically used to establish communication connections between the electronic device 1 and other electronic devices.

[0161] Optionally, the electronic device 1 may further include a user interface, which may be a display, an input unit (such as a keyboard), and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the electronic device 1 and to display a visual user interface.

[0162] The automated I / O test method program for the FPGA chip stored in the memory 11 of the electronic device 1 is a combination of multiple instructions. When run in the processor 10, it can achieve the following:

[0163] The system receives user input of the FPGA chip model, package type, IO type, and test type, and obtains IO information, including: number of banks, number of IOs, and number of IO categories.

[0164] Obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type based on the pin layout and electrical standard;

[0165] The pre-built EDA tool is run using the pre-built TCL script to obtain the EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log.

[0166] The system determines whether the preset code points can be correctly generated based on the log data.

[0167] If the code points cannot be generated correctly, the test type is debugged using the EDA tool until the correct code points are obtained.

[0168] If the code points can be generated correctly, then the correct code points are obtained;

[0169] The correct code points are converted into a preset machine test AVC file using a preset transcoding environment, a test vector file is generated according to the constraint file, and the test port information is output.

[0170] Based on the test AVC file, test vector file and test port information, perform ATE test to complete automated I / O test for FPGA chips.

[0171] Specifically, the processor 10's implementation method for the above instructions can be found in [reference needed]. Figures 1 to 5 The descriptions of the relevant steps in the corresponding embodiments are not repeated here.

[0172] Furthermore, if the modules / units integrated in the electronic device 1 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, or a read-only memory (ROM).

[0173] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor of an electronic device, can perform the following:

[0174] The system receives user input of the FPGA chip model, package type, IO type, and test type, and obtains IO information, including: number of banks, number of IOs, and number of IO categories.

[0175] Obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type based on the pin layout and electrical standard;

[0176] The pre-built EDA tool is run using the pre-built TCL script to obtain the EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log.

[0177] The system determines whether the preset code points can be correctly generated based on the log data.

[0178] If the code points cannot be generated correctly, the test type is debugged using the EDA tool until the correct code points are obtained.

[0179] If the code points can be generated correctly, then the correct code points are obtained;

[0180] The correct code points are converted into a preset machine test AVC file using a preset transcoding environment, a test vector file is generated according to the constraint file, and the test port information is output.

[0181] Based on the test AVC file, test vector file and test port information, perform ATE test to complete automated I / O test for FPGA chips.

[0182] In the embodiments provided by this invention, it should be understood that the disclosed devices, systems, and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative, and actual implementations may have other classification methods.

[0183] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0184] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0185] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0186] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. An automated I / O testing method for FPGA chips, characterized in that, The method includes: The system receives user input of the FPGA chip model, package type, IO type, and test type, and obtains IO information, including: number of banks, number of IOs, and number of IO categories. Obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type based on the pin layout and electrical standard; The pre-built EDA tool is run using the pre-built TCL script to obtain the EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log. The system determines whether the preset code points can be correctly generated based on the log data. If the code points cannot be generated correctly, the test type is debugged using the EDA tool until the correct code points are obtained. If the code points can be generated correctly, then the correct code points are obtained; The correct code points are converted into a preset machine test AVC file using a preset transcoding environment, a test vector file is generated according to the constraint file, and the test port information is output. Based on the test AVC file, test vector file and test port information, perform ATE test to complete automated I / O test for FPGA chips.

2. The automated I / O testing method for FPGA chips as described in claim 1, characterized in that, The test types include: HRIO type tests and HPIO type tests. The HRIO type tests include: IO_DC test, IO_TERM test, IO_LEAKAGE test, IO_FUNC test, and IO_PULLTYPE test. The HPIO type tests include: IO_DC test, IO_TERM test, IO_LEAKAGE test, IO_FUNC test, IO_PULLTYPE test, and IO_DCI test.

3. The automated I / O testing method for FPGA chips as described in claim 1, characterized in that, The process of referencing the IO information and generating the project file and constraint file for the test type based on the pin layout and electrical standards includes: Using the IO information, an RTL project corresponding to the test type is built according to the pin layout and electrical standards to obtain the project file. The RTL project is built by calling the source code of ComboIO. Obtain the RTL project test content corresponding to the RTL project, and add ComboIO, IO level standard, ComboIO attribute, bit stream compression attribute, and other preset attributes to the constraint file according to the RTL project test content to obtain the constraint file. The ComboIO attribute includes pull-up attribute and pull-down attribute, and the other attributes include internal reference configuration.

4. The automated I / O testing method for FPGA chips as described in claim 3, characterized in that, The step of determining whether the preset code points can be correctly generated based on the log includes: The pre-built log error warning capture program in the TCL script captures ERROR and CRITICAL WARNING information in the log log and determines whether ERROR or CRITICAL WARNING information exists in the log log. If the log contains ERROR or CRITICAL WARNING information, code points cannot be generated correctly. If no ERROR or CRITICAL WARNING information is found in the log, code points can be generated correctly.

5. The automated I / O testing method for FPGA chips as described in claim 1, characterized in that, The step of debugging the test type using the EDA tool until the correct code point is obtained includes: Based on the log, run the EDA tool to diagnose and locate faults in the test type until the correct code point is obtained.

6. The automated I / O testing method for FPGA chips as described in claim 5, characterized in that, The step of generating a test vector file based on the constraint file and outputting test port information includes: When the test type is IO_DC test or IO_FUNC test, the test vector is verified for the test type to obtain the test vector file for IO_DC test or the test vector file for IO_FUNC test. The test vector file for IO_DC test is divided into the following categories according to the preset level standard: single-ended IO test vector, IO test vector with external reference voltage, and differential level IO test vector. Output test port information according to the test type.

7. The automated I / O testing method for FPGA chips as described in claim 6, characterized in that, After generating the test vector file based on the constraint file and outputting the test port information, the method further includes: When the test type is IO_TERM test, IO_LEAKAGE test, IO_PULLTYPE test, or IO_DCI test, the test port and Limit value are set on the pre-built ATE machine according to the test port information.

8. The automated I / O testing method for FPGA chips as described in claim 6, characterized in that, The test vectors for the single-ended I / O include: test vectors for the LVCMOS12 level standard, test vectors for the LVCMOS15 level standard, and test vectors for the LVCMOS18 level standard; The IO test vectors with external reference voltage include: test vectors for SSTL level standards, test vectors for HSTL level standards, and test vectors for HSUL level standards; The differential level IO test vectors include: test vectors for the DIFF_SSTL level standard, test vectors for the DIFF_HSTL level standard, and test vectors for the LVDS level standard.

9. The automated I / O testing method for FPGA chips as described in claim 2, characterized in that, The IO_DC test includes: LVCMOS12 level standard test; The IO_TERM test includes: terminating resistor test and differential resistor test. The level configuration standard for the terminating resistor test is SSTL_18 level standard, and the level configuration standard for the differential resistor test is LVDS25 level standard. The IO_LEAKAGE test includes: high voltage leakage test, and the level configuration standard for the high voltage leakage test is LVCMOS33; The IO_FUNC test includes: the IBUFDISABLE test; The IO_PULLTYPE test includes: weak pull-up current test of LVCMOS33; IO_DCI testing includes: source-side matching resistor testing.

10. An automated I / O testing system for FPGA chips, characterized in that, The system includes: The project file and constraint file generation module is used to receive the FPGA chip model, package type, IO type and test type input by the user, obtain IO information, wherein the IO information includes: number of banks, number of IOs, number of IO categories; obtain the pin layout corresponding to the package type and the electrical standard corresponding to the IO type, reference the IO information, and generate the project file and constraint file for the test type according to the pin layout and electrical standard; The log acquisition module is used to run a pre-built EDA tool using a pre-built TCL script to obtain an EDA tool environment. In the EDA tool environment, the chip model is set according to the FPGA chip model and package type, and the project file and constraint file are referenced for synthesis and implementation to obtain the log. The correct code point acquisition module is used to determine whether the preset code point can be correctly generated based on the log; if the code point cannot be correctly generated, the test type is debugged according to the EDA tool until the correct code point is obtained; if the code point can be correctly generated, the correct code point is acquired. The ATE (Automatic Test Equipment) module is used to transcode the correct code points into a preset test AVC file using a preset transcoding environment, generate a test vector file based on the constraint file, and output test port information; and perform ATE test based on the test AVC file, test vector file, and test port information.

Images