Chip Tester

Abstract

The present application relates to a chip tester. It includes: the host computer driver responds to the first instruction issued by the application programming interface to generate a trigger start command; the business FPGA responds to the trigger start command, calls and runs the test vector, and when an infinite loop microinstruction in the test vector is detected, sets the status register in the business FPGA to a repeated execution state; the application programming interface notifies the host computer driver to poll the status register, and triggers the host computer driver when the repeated execution state is obtained; the host computer driver controls the business FPGA to execute a preset test. When an infinite repeating microinstruction is detected, the preset test function can be executed while the test vector is continuously run, freeing up the computing resources of the test machine, and only one test machine is required to run, without the need for multiple test machines to cooperate and run, greatly reducing the test cost.

Description

Technical Field

[0001] The present application relates to the field of chip testing technology, and in particular to a chip testing machine. Background Art

[0002] During chip testing, ATE (Automated Test Equipment) sends a series of timing signals to the input pins of the chip under test, and compares the output timing signals at the chip's output pins to determine whether the chip meets its functional requirements. In a narrow sense, a test pattern is the chip's truth table.

[0003] While testing a chip's timing characteristics, it's sometimes necessary to also test other parameters while the chip is operating. However, chip timing characteristics testing requires extremely high real-time performance, often occupying a large portion of a tester's computing resources, preventing other tests from being performed. Traditionally, multiple testers have been used to run simultaneously to perform timing characteristics testing and other tests simultaneously. However, this approach is costly and difficult to coordinate across multiple testers. Summary of the Invention

[0004] Based on this, it is necessary to provide a chip testing machine to address the above technical problems.

[0005] In a first aspect, the present application provides a chip tester, characterized in that it includes an application programming interface, a host computer driver, and a test head, the test head includes a service FPGA, the host computer driver is connected to the service FPGA, wherein:

[0006] The host computer drives and responds to the first instruction issued by the application programming interface to generate a trigger start command;

[0007] The service FPGA responds to the trigger start command, calls and runs the test vector, and sets the status register in the service FPGA to a repeat execution state when an infinite loop microinstruction in the test vector is detected;

[0008] The application programming interface notifies the host computer driver to poll the status register, and triggers the host computer driver when obtaining the repeated execution status;

[0009] The host computer drives and controls the service FPGA to execute a preset test.

[0010] In one embodiment, the service FPGA includes a main control module, a microinstruction module, and an input and output module, wherein:

[0011] The main control module responds to the trigger start command and sequentially starts the microinstruction module and the input and output module to run the test vector;

[0012] When the microinstruction module is running and querying the test vector, when an infinite loop microinstruction in the test vector is queried, the microinstruction module is changed to a repeat state and the repeat state information is sent to the input and output module;

[0013] The input-output module repeatedly executes the test waveform of the same cycle as the infinite loop microinstruction according to the repetitive state information.

[0014] In one embodiment, the input-output module sends the repeated status information to the main control module;

[0015] The main control module sets the status register to a repeat execution state.

[0016] In one embodiment, the application programming interface includes a non-blocking startup test vector interface; the user drives the first instruction to the host computer through the non-blocking startup test vector interface.

[0017] In one embodiment, the application programming interface includes a test vector status query interface; a user queries the running status of the test vector through the test vector status query interface.

[0018] In one embodiment, the host computer driver further notifies the application programming interface of register status information of the status register.

[0019] In one embodiment, the preset test includes a PPMU test and / or a TMU test.

[0020] In one embodiment, the application programming interface includes a first blocking test interface and / or a second blocking test interface;

[0021] The user drives the host computer to control the service FPGA to perform PPMU testing through the first blocking test interface; and / or,

[0022] The user drives the host computer to control the service FPGA to perform the TMU test through the second blocking test interface.

[0023] In one embodiment, the application programming interface includes a continue operation interface;

[0024] After the preset test is completed, the host computer drives the response to the continue operation instruction issued by the user through the continue operation interface to generate a trigger continuation command;

[0025] The service FPGA responds to the trigger-continue command and continues to run the subsequent test waveform of the test vector; the subsequent test waveform is the next cycle waveform of the infinite loop microinstruction.

[0026] In one embodiment, the application programming interface includes a test result query interface;

[0027] The host computer drives the response to the test result query instruction issued by the user through the test result query interface to generate a test information query command;

[0028] The service FPGA responds to the test information query command and feeds back target test information to the host computer driver, and the host computer driver feeds back the target test information through the test result query interface.

[0029] The chip tester includes an application programming interface (API), a host computer driver, and a test head. The test head includes a service FPGA. The host computer driver is connected to the service FPGA. The host computer driver responds to a first instruction issued by the application programming interface and generates a trigger start command. The service FPGA responds to the trigger start command, retrieves and runs a test vector, and upon detecting an infinite loop microinstruction in the test vector, sets the status register in the service FPGA to a repeat execution state. The application programming interface notifies the host computer driver to poll the status register, and upon obtaining the repeat execution state, triggers the host computer driver. The host computer driver controls the service FPGA to execute a preset test. This solves the problem of being unable to perform other test tasks while performing chip testing on a single chip tester. When an infinite loop microinstruction is detected, the preset test function can be executed while the test vector is continuously running, freeing up the tester's computing resources. Furthermore, only one tester is required for operation, eliminating the need for multiple testers to coordinate and run, significantly reducing testing costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 This is a structural block diagram of a chip testing machine in one embodiment of the present application;

[0031] Figure 2 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0032] Figure 3 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0033] Figure 4 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0034] Figure 5 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0035] Figure 6 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0036] Figure 7 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0037] Figure 8 This is a structural block diagram of a chip testing machine in another embodiment of the present application;

[0038] Figure 9 This is a signaling diagram of a chip tester operating in one embodiment of the present application;

[0039] Figure 10 This is a flowchart of the chip testing machine operation in one embodiment of the present application. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0041] like Figure 1 As shown, a chip tester according to one embodiment includes an application programming interface (API), a host computer driver, and a test head. The test head includes a service FPGA, and the host computer driver is connected to the service FPGA. The host computer driver responds to a first instruction issued by the API and generates a trigger start command. The service FPGA responds to the trigger start command, retrieves and runs a test vector, and upon detecting an infinite loop microinstruction in the test vector, sets a status register in the service FPGA to a repeat execution state. The API notifies the host computer driver to poll the status register, and upon obtaining the repeat execution state, the host computer driver is triggered. The host computer driver then controls the service FPGA to execute a preset test.

[0042] The application programming interface (API) is an API (Application Programming Interface) interface, which refers to the entry point for operational data provided by an application program. The host computer is a computer that can directly issue control commands. The service FPGA (Field Programmable Gate Array) refers to the FPGA chip used to execute test services. The infinite loop microinstruction is the instruction information for performing an infinite loop test on a test vector carrying an infinite loop microinstruction. The first instruction is the API instruction issued by the application programming interface, which is the instruction information for executing the test task. The test vector is a set of data used to test chip performance, including chip input data and correct output data for comparison with the chip output value. The test vector (pattern) consists of N cycles, each cycle including a test waveform and microinstructions. The test waveform is a waveform of 0 or 1. Microinstructions include repeat microinstructions, loop microinstructions, endloop microinstructions, match microinstructions, trigger microinstructions, and scan microinstructions. This application mainly focuses on the defined infinite loop microinstruction (repeat infinite). The trigger start command is the instruction used to trigger the service FPGA to start and execute the test task. The "repeated execution state" refers to the state bit that repeatedly tests the test vector containing the infinite loop microinstruction. Polling is a method by which the CPU determines how to service peripheral devices. The CPU periodically queries each peripheral device in sequence whether it requires service. If so, it provides service. Once service is complete, the CPU asks the next peripheral device, and the cycle repeats. Preset testing refers to test tasks other than test vectors. The application programming interface and host computer driver are part of the host computer software.

[0043] Specifically, when a user needs to execute a chip test task for a target chip, they invoke an application programming interface (API) to issue a first instruction corresponding to the chip test task. The first instruction may include the chip identifier of the target chip. During the operation of the chip tester, the host computer driver responds to the first instruction issued by the API and, based on the first instruction, determines that a trigger start command is required to start running the test vector for the target chip. The trigger start command is then received by the service FPGA, which calls and executes the test vector accordingly. Simultaneously, the service FPGA monitors whether the test vector contains an infinite loop microinstruction. If the service FPGA detects an infinite loop microinstruction carried by the test vector during execution, it sets its internal status register to a repeat execution state, allowing the service FPGA to continuously execute the infinite loop microinstruction. In this case, the chip tester only requires a small portion of its computing power to execute the infinite loop microinstruction, freeing up the majority of its computing power to execute the preset test. The API notifies the host computer driver to poll the status register bit to check whether the FPGA status register has entered the repeat execution state. Upon confirming that the FPGA status register has entered the repeat execution state, the host computer driver is triggered, and the host computer driver controls the service FPGA to execute the preset test.

[0044] The chip tester includes an application programming interface (API), a host computer driver, and a test head. The test head includes a service FPGA. The host computer driver is connected to the service FPGA. The host computer driver responds to a first instruction issued by the application programming interface and generates a trigger start command. The service FPGA responds to the trigger start command, retrieves and runs a test vector, and upon detecting an infinite loop microinstruction in the test vector, sets the status register in the service FPGA to a repeat execution state. The application programming interface notifies the host computer driver to poll the status register, and upon obtaining the repeat execution state, triggers the host computer driver. The host computer driver controls the service FPGA to execute a preset test. This solves the problem of being unable to perform other test tasks while performing chip testing on a single chip tester. When an infinite loop microinstruction is detected, the preset test function can be executed while the test vector is continuously running, freeing up the tester's computing resources. Furthermore, only one tester is required for operation, eliminating the need for multiple testers to coordinate and run, significantly reducing testing costs.

[0045] In one embodiment, Figure 2As shown, the business FPGA includes a main control module, a microinstruction module and an input-output module. The main control module responds to the trigger start command and starts the microinstruction module and the input-output module in sequence to run the test vector. When the microinstruction module is running and querying the test vector, when the infinite loop microinstruction in the test vector is queried, it changes to a repeat state and sends the repeat state information to the input-output module. The input-output module repeats the test waveform of the same cycle as the infinite loop microinstruction according to the repeat state information.

[0046] The "repeat state" refers to the state in which the microinstruction module repeatedly executes the test waveform within the cycle of the infinite loop microinstruction. The waveform output by the relevant pins of the chip tester is in a hold state. Repeat state information includes information indicating that the microinstruction module is in the repeat state. It should be noted that in the current state of the chip tester's other pins, the service FPGA can execute the preset test.

[0047] Specifically, the service FPGA consists of three key components: a main control module, a microinstruction module, and an input / output module. The service FPGA's main control module responds to start commands and coordinates the entire testing process. The microinstruction module executes the microinstructions in the test vector and, when necessary, processes infinite loop microinstructions. The input / output module processes the input and output data associated with the test vector. During chip testing, these three components work together as follows: the host computer driver sends a trigger start command to the main control module in the service FPGA. The main control module responds to the trigger start command and sends it to the microinstruction module. Upon receiving the trigger start command, the microinstruction module in the FPGA runs the test vector and starts the input / output module to run the test vector. While the microinstruction module is running the test vector, if it detects an infinite loop microinstruction in the test vector, it switches the microinstruction module's operating state to repeat mode and sends this repeat mode information to the input / output module. Upon receiving this repeat mode information, the input / output module repeatedly executes the test waveform corresponding to the infinite loop microinstruction within the same cycle.

[0048] In this embodiment, the main control module in the service FPGA responds to the trigger start command transmitted by the host computer driver, notifying the microinstruction module in the service FPGA to run the test vector. When the microinstruction module queries the test vector, it changes to a repeating state. After entering the repeating state, the microinstruction module notifies the input and output modules in the service FPGA to enter the waveform holding state. The microinstruction module and the input and output modules are arranged in the service FPGA, and through the internal operation mode of the service FPGA, when the service FPGA queries an infinite loop microinstruction in the test vector, the input and output modules are promptly notified to enter the waveform holding state, thereby improving the input and output modules' perception efficiency of the infinite loop microinstruction. Through the collaborative work of the host computer software and the service FPGA, the chip tester system provides flexible and efficient chip testing functions, repeatedly running test vectors while supporting different types of test tasks.

[0049] For example, Figure 3 As shown, based on the above solution, the input and output module sends the repeat status information to the main control module; the main control module sets the status register to the repeat execution state.

[0050] Specifically, while the input and output module repeatedly executes the test waveform of the same cycle as the infinite loop microinstruction, it sends the repetition status information to the main control module to notify the main control module to set the status register to the repetition status. After receiving the repetition status information, the main control module sets the status register in the main control module to the repetition status.

[0051] It can be understood that passing the repeated status information to the main control module can enable the main control module to update the status bit of the status register in a timely manner, so that the host computer can promptly control the FPGA to execute the preset test when the status register is in the repeated execution state, and realize that when the business FPGA queries the infinite loop microinstructions in the test vector, the status register in the business FPGA is promptly set to the repeated execution state, thereby improving the test execution efficiency and the test efficiency of the chip.

[0052] In one embodiment, Figure 4 As shown, the application programming interface includes a non-blocking startup test vector interface; the user drives the host computer to issue a first instruction through the non-blocking startup test vector interface.

[0053] Among them, non-blocking refers to the state when the user or program is waiting for the return result or input data.

[0054] The above method sends the first instruction to the host computer driver through the non-blocking startup test vector interface, which can ensure that when the business FPGA detects the infinite loop microinstruction in the test vector and sets the status register in the business FPGA to the repeated execution state, the host computer driver is notified through the application programming interface to poll the status register to determine whether the status register is in the repeated execution state.

[0055] In one embodiment, Figure 5 As shown, the application programming interface includes a test vector status query interface; the user queries the running status of the test vector through the test vector status query interface.

[0056] The test vector status query interface refers to an API interface for querying the test vector status. Users can query whether the test vector has entered the repeated execution state through the test vector status query interface.

[0057] The above method sets up a test vector status query interface, and queries the running status of the test vector through the test vector status query interface, which can improve the query efficiency of the running status of the test vector and avoid interface information calling errors when calling the application programming interface.

[0058] In one embodiment, the preset test includes a PPMU test and / or a TMU test.

[0059] The per pin parametric measurement unit (PPMU) is a functional module within the tester, used to measure voltage while increasing current, or current while increasing voltage. The time measurement unit (TMU) monitors time accuracy by comparing multiple incoming time signals with the time reference signal of the central core clock and reporting the comparison results to the monitoring center via the data network.

[0060] It is understandable that in other embodiments, the preset test may also be other tests that need to be performed, which can be determined by the user according to actual needs and are not specifically limited here.

[0061] The above solution allows the test machine to repeatedly run a part of the test vectors after the test machine triggers an infinite loop microinstruction to release computing resources. Based on the released computing resources, PPMU testing and / or TMU testing can be performed, and the pin signal and time signal status can be obtained in a timely manner, saving testing costs.

[0062] Exemplarily, the host computer driver also notifies the application programming interface of the register status information of the status register.

[0063] Specifically, the register status information includes whether the status register in the service FPGA is in the repetitive state or the non-repetitive state. If the status register is in the repetitive state, the test vector is in the repetitive state; if the status register is in the non-repetitive state, the test vector is in the normal operating state. The application programming interface can determine the operating status of the test vector based on the register status information of the status register sent by the host computer driver.

[0064] In the above solution, the application programming interface can obtain the running status of the test vector in a timely manner through the register status information sent by the host computer driver, thereby improving the execution efficiency of the test task.

[0065] In one embodiment, Figure 6 As shown, the application programming interface includes a first blocking test interface and / or a second blocking test interface; the user drives the host computer to drive the control service FPGA to perform PPMU testing through the first blocking test interface; and / or,

[0066] The user drives the host computer to drive the control service FPGA to perform TMU testing through the second blocking test interface.

[0067] The blocking test interface is the state of the test interface while the user is waiting for a result or input. When the test interface is in the blocking state, the current thread is suspended before the call result is returned and returns after the result is obtained. The first blocking test interface is the API interface used to issue test instructions for the PPMU test, and the second blocking test interface is the API interface used to issue test instructions for the PPMU test.

[0068] Specifically, when the host computer driver polls the status register and determines that the status register in the FPGA enters the repeated execution state, triggering the host computer driver, the user determines whether to perform the PPMU test and the TMU test based on the test requirements. If the PPMU test needs to be performed, the host computer driver control service FPGA is driven to perform the PPMU test through the first blocking test interface; if the TMU test needs to be performed, the host computer driver control service FPGA is driven to perform the TMU test through the second blocking test interface. It can be understood that the above-mentioned PPMU test and TMU test can be performed simultaneously or separately.

[0069] The above scheme sets up a first blocking test interface for driving the host computer drive control service FPGA to perform PPMU test, and a second blocking test interface for driving the host computer drive control service FPGA to perform TMU test. This can distinguish the application programming interface that drives the host computer drive control service FPGA to perform preset test from the application programming interface that drives the host computer drive control service FPGA to run test vectors. At the same time, different application programming interfaces are set for executing different preset tests, which can improve the execution efficiency of test tasks and avoid interface information call errors when calling the application programming interface.

[0070] In one embodiment, Figure 7 As shown, the application programming interface includes a continue-run interface; after the preset test is completed, the host computer driver responds to the continue-run instruction issued by the user through the continue-run interface and generates a trigger-continue command; the business FPGA responds to the trigger-continue command and continues to run the subsequent test waveform of the test vector; the subsequent test waveform is the next cycle waveform of the infinite loop microinstruction.

[0071] The "continue instruction" is the instruction to continue running the next sequential test vector following the test vector containing the infinite loop microinstruction. The "continue interface" is the API used to issue the "continue instruction." The "trigger continue command" is the instruction that notifies the service FPGA to continue running the test vector.

[0072] Specifically, after the service FPGA completes the preset PPMU test and / or TMU test, the user can issue a continue command through the continue interface. The host computer driver responds to the continue command issued by the user through the continue interface and generates a trigger-continue command. The service FPGA responds to the trigger-continue command issued by the host computer driver and continues to execute the subsequent test waveforms of the test vector.

[0073] Exemplarily, the application programming interface includes a test result query interface; the host computer driver responds to the test result query instruction issued by the user through the test result query interface and generates a test information query command; the business FPGA responds to the test information query command and feeds back the target test information to the host computer driver, and the host computer driver feeds back the target test information through the test result query interface.

[0074] The test result query interface is an API interface used to issue test result query instructions. A test result query instruction is an instruction used to query the test waveform of a test vector executed by the service FPGA. The test result query instruction may include the target cycle that the user is querying. The target test information may be a table recording the test results for the target cycle.

[0075] The host computer driver responds to the test result query instruction issued by the user through the test result query interface and generates a test information query command. The business FPGA responds to the test information query command issued by the host computer driver, reads the target test data of the target cycle to be queried by the user according to the test information query command, and generates target test information according to the target test data, and feeds back the target test information to the host computer driver. The host computer driver feeds back the target test information to the user through the test result query interface.

[0076] Users can query target test information through the test result query interface, which can improve the flexibility of users in querying business FPGA test results.

[0077] The above solution can notify the business FPGA to continue running the subsequent test waveforms of the test vector through the continue running interface after completing the preset test, so that the business FPGA can execute the preset test while running the test vector, and continue to run the test vector after the preset test is completed, thereby improving the flexibility of the business FPGA in executing test tasks.

[0078] For example, based on the above embodiment, Figure 8 As shown, the chip tester consists of host software and a service FPGA. The host software includes an application programming interface (API) and a host driver, providing functions for controlling and managing the test process. The service FPGA includes a main control module, a microinstruction module, and an input / output module, which work together to execute test tasks. Within the host software, the API provides multiple interfaces, including non-blocking test vector initiation, test vector status query, first blocking test, second blocking test, and continue operation, to support different testing requirements. The host driver is responsible for interpreting and executing instructions from the API.

[0079] For example, the signaling diagram of the chip tester operation is as follows: Figure 9As shown. When the user starts the Pattern process, the first instruction is issued through the non-blocking start test vector interface in the application programming interface. The non-blocking start test vector interface is the non-blocking Start Pattern API interface. Running the Pattern process is running the test vector process. After the upper computer driver receives the first instruction issued by the non-blocking Start Pattern API interface, it responds to the first instruction and generates a Trigger Start command for starting the test vector. The Trigger Start command is the trigger start command, and the TriggerStart command is sent to the main control module in the business FPGA. The main control module responds to the Trigger Start command and sends the TriggerStart command to the microinstruction module and IO_Ctrl module in the business FPGA. The IO_Ctrl module is the input and output module. After receiving the Trigger Start command, the microinstruction module and IO_Ctrl module in the FPGA run the test vector Pattern.

[0080] The user uses the Pattern Status API to notify the host computer driver to poll the pattern's running status to check whether the service FPGA has entered the Repeat Infinite state. The Pattern Status API is also used to query the test vector status. The Repeat Infinite state indicates the repeated execution state.

[0081] If an infinite loop microinstruction is detected while the microinstruction module is executing the pattern, the module's operating state is changed to the Repeat state, and the Repeat state information is sent to the IO_Ctrl module. Upon receiving the Repeat state information, the IO_Ctrl module repeats the test waveform for the same cycle as the infinite loop microinstruction based on the Repeat state information and sends the Repeat state information to the main control module, instructing the main control module to set the status register to the RepeatInfinite state. The Repeat Infinite state is the repeat execution state. Upon receiving the Repeat state information, the main control module sets the status register in the main control module to the Repeat Infinite state.

[0082] The user queries the running status of the Pattern by querying the Pattern status API interface. When it is determined that the status register in the FPGA enters the Repeat Infinite state, the host computer driver is triggered, and the host computer driver controls the service FPGA to perform the preset test. The preset test includes the PPMU test and / or the TMU test. If the preset test is the PPMU test, the host computer driver controls the service FPGA to perform the PPMU test through the first blocking test interface; if the preset test is the TMU test, the host computer driver controls the service FPGA to perform the TMU test through the second blocking test interface. After the preset test is completed, the host computer driver responds to the Continue Pattern instruction issued by the user through the continue API interface to generate a Trigger Continue command. The Trigger Continue command is a trigger continue command, the continue API interface is a continue operation interface, and the Continue Pattern instruction is a continue operation instruction. The service FPGA responds to the Trigger Continue command and continues to run the subsequent test waveforms of the Pattern.

[0083] The above-mentioned chip tester can realize that when infinitely repeated microinstructions are detected, it can continuously run the test vector while executing the preset test function, freeing up the computing resources of the tester, and only requires one tester to run, without the need for multiple testers to cooperate, which greatly reduces the testing cost.

[0084] In another embodiment, the chip tester operation flow chart is as follows: Figure 10 shown.

[0085] When the chip tester begins running, it first loads a test vector containing an infinite loop microinstruction. The user, through the application programming interface (API), controls the host computer driver to generate a trigger start command, causing the service FPGA to respond to the trigger start command and begin running the test vector. Simultaneously, the user, through the API, controls the host computer driver to poll the run status flag. If the service FPGA's microinstruction module detects an infinite loop microinstruction while running the test vector, it controls the input and output modules to enter a repeat execution state. The input and output modules then send this repeat status information to the main control module, which then modifies the run status register to enter a repeat execution state. The host computer driver then polls the run status register and returns the status to the API. The API then controls the host computer driver, causing it to control the service FPGA to execute the pre-set test. Once the pre-set test is completed, the API sends a trigger continue command to the main control module through the host computer driver, causing the service FPGA to continue running the test vector.

[0086] It should be understood that, although the various steps in the flowcharts involved in the embodiments described above are shown in sequence as indicated by the arrows, these steps are not necessarily performed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these steps or stages is not necessarily performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0087] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0088] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A chip testing machine, characterized in that: It includes an application programming interface, a host computer driver and a test head, wherein the test head includes a business FPGA, and the host computer driver is connected to the business FPGA, wherein: The host computer drives and responds to the first instruction issued by the application programming interface to generate a trigger start command; The service FPGA responds to the trigger start command, calls and runs the test vector, and sets the status register in the service FPGA to a repeat execution state when an infinite loop microinstruction in the test vector is detected; The application programming interface notifies the host computer driver to poll the status register, and triggers the host computer driver when obtaining the repeated execution status; The host computer drives and controls the service FPGA to execute a preset test.

2. The chip testing machine according to claim 1, characterized in that: The service FPGA includes a main control module, a microinstruction module, and an input and output module, wherein: The main control module responds to the trigger start command and sequentially starts the microinstruction module and the input and output module to run the test vector; When the microinstruction module is running and querying the test vector, when an infinite loop microinstruction in the test vector is queried, the microinstruction module is changed to a repeat state and the repeat state information is sent to the input and output module; The input-output module repeatedly executes the test waveform of the same cycle as the infinite loop microinstruction according to the repetitive state information.

3. The chip testing machine according to claim 2, characterized in that: The input and output module sends the repeated status information to the main control module; The main control module sets the status register to a repeat execution state.

4. The chip testing machine according to any one of claims 1 to 3, characterized in that: The application programming interface includes a non-blocking startup test vector interface; the user drives the sending of the first instruction to the host computer through the non-blocking startup test vector interface.

5. The chip testing machine according to any one of claims 1 to 3, characterized in that: The application programming interface includes a test vector status query interface; a user queries the running status of the test vector through the test vector status query interface.

6. The chip testing machine according to any one of claims 1 to 3, characterized in that: The host computer driver also notifies the application programming interface of the register status information of the status register.

7. The chip testing machine according to any one of claims 1 to 3, characterized in that: The preset test includes a PPMU test and / or a TMU test.

8. The chip testing machine according to claim 7, characterized in that: The application programming interface includes a first blocking test interface and / or a second blocking test interface; The user drives the host computer to control the service FPGA to perform PPMU testing through the first blocking test interface; and / or, The user drives the host computer to control the service FPGA to perform the TMU test through the second blocking test interface.

9. The chip testing machine according to claim 8, characterized in that: The application programming interface includes a continue operation interface; After the preset test is completed, the host computer drives the response to the continue operation instruction issued by the user through the continue operation interface to generate a trigger continuation command; The service FPGA responds to the trigger-continue command and continues to run the subsequent test waveform of the test vector; the subsequent test waveform is the next cycle waveform of the infinite loop microinstruction.

10. The chip testing machine according to claim 9, characterized in that: The application programming interface includes a test result query interface; The host computer drives the response to the test result query instruction issued by the user through the test result query interface to generate a test information query command; The service FPGA responds to the test information query command and feeds back target test information to the host computer driver, and the host computer driver feeds back the target test information through the test result query interface.

Images