Built-in device testing of integrated circuits

Embodiments are directed to a computer implemented method and system for the testing, characterization and diagnostics of integrated circuits. A system might include a device under test, such as an integrated circuit, that includes an adaptive microcontroller. The method includes loading a testing program for execution by the adaptive microcontroller, causing the microcontroller to execute the testing program. Once results from the testing program are received, the testing program can be adaptively modified based on the results. The modified testing program can be run again. The testing program can modify parameters of the integrated circuit that are not externally accessible. Other embodiments are also disclosed.

BACKGROUND

The present disclosure relates in general to the field of integrated circuits. More specifically, the present disclosure relates to systems and methodologies for the testing of integrated circuit devices.

There is an increased desire for manufacturers, developers, and test organization to effectively test, characterize, and diagnose an integrated circuit (IC) more completely and at the lowest possible cost. One method of testing and characterizing is to use the Shmoo plot tool—a graphical representation of an IC's ability to operate properly in response to various combinations of values of various operating parameters. For example, one might repeatedly test an IC using different combinations of supply voltage and frequency to determine if the IC operates properly at those combinations and parameter ranges. This is typically mapped on a Shmoo plot. For example, the voltage can be on one axis of a scatter plot and the frequency can be on the other axis of the scatter plot. A test of the IC is done at each combination of voltage and frequency and the pass/fail status can be indicated on the shmoo plot.

A difficulty becomes evident when dealing with larger ICs such as VLSI chips known as systems on a chip (SOC) or complex multi-core processors with millions or even billions of transistors and heterogeneous circuits such as combinational logic, various types of memory, analog, and wireless RF. In such devices, the ability to adjust critical operating parameters, reconfigure the chip into separate regions, alter the data paths, and change test operations, might also be internal to the chip as an integral part of the chip design (in contrast to more traditional methods of controlling things like voltage, frequency, and chip test modes which can be controlled outside the IC). Strict external and limited internal test controls are not conducive to complex testing methodologies such as chip self-test and testing at application speeds and environmental conditions in various chip configurations.

SUMMARY

Embodiments are directed to an on-chip, computer-assisted test method. The method includes loading an on-chip test flow and control testing program for execution by a microcontroller within an integrated circuit chip to be tested. The microcontroller within the integrated circuit chip can then execute the testing program. The testing program can be dynamically self-adjusted based on the execution of the testing program.

Embodiments are further directed to a computer system. The system includes a memory, a processor system communicatively coupled to the memory, and an integrated circuit chip to be tested, the integrated circuit chip comprising an adaptive testing microcontroller. The adaptive testing microcontroller configured to perform a method comprising loading a testing program from an external traditional test system. The method can further comprise executing the testing program. The method also comprises dynamically adjusting the testing program based on the execution of the testing program. The method further comprises executing the adjusted testing program.

Embodiments are further directed to a computer program product. The computer program product includes a computer-readable storage medium having program instructions embodied therewith. The computer-readable storage medium is not a transitory signal per se. The program instructions readable by a processor system to cause the processor system to perform a method comprising loading a testing program from the test processor system. Thereafter executing the testing program. The method further comprises dynamically adjusting the testing program based on the execution of the testing program. The method further comprises executing the adjusted testing program.

Additional features and advantages are realized through techniques described herein. Other embodiments and aspects are described in detail herein. For a better understanding, refer to the description and to the drawings.

DETAILED DESCRIPTION

Various embodiments of the present disclosure will now be described with reference to the related drawings. Alternate embodiments may be devised without departing from the scope of this disclosure. Various connections might be set forth between elements in the following description and in the drawings. These connections, unless specified otherwise, may be direct or indirect, and the present disclosure is not intended to be limiting in this respect. Accordingly, a coupling of entities may refer to either a direct or an indirect connection.

Additionally, although this disclosure includes a detailed description of a computing device configuration, implementation of the teachings recited herein are not limited to a particular type or configuration of computing device(s). Rather, embodiments of the present disclosure are capable of being implemented in conjunction with any other type or configuration of wireless or non-wireless computing devices and/or computing environments, now known or later developed.

At least the features and combinations of features described in the present application, including the corresponding features and combinations of features depicted in the figures, amount to significantly more than implementing a method of analyzing data in a particular technological environment. Additionally, at least the features and combinations of features described in the present application, including the corresponding features and combinations of features depicted in the figures, go beyond what is well-understood, routine and conventional in the relevant field(s).

As described above, creating a shmoo plot in the above-described manner (a process sometimes known as shmooing) might not be not a viable method of testing when sensitivity parameters or device reconfigurability cannot be changed by means that are external to a device being tested. This parameter controllability and observability problem can be a critical limitation to the current characterization and diagnostic techniques used in the testing of highly integrated ICs. In many of these VLSI devices, the critical parameters and reconfigurability are internal to the device. This can limit testing and the subsequent diagnosis of VLSI devices in the identification of multi-dimensional failing regions and the sensitivity and correlation of these failing regions to several test setup parameters. Typically, the failing regions are determined by shmooing two test variables at a time, such as frequency versus voltage, over an extended device operating range and localizing the failing region in the two-dimensional space of a shmoo plot. While this approach can be effective for some defects, it is not adaptive. Nor is the approach robust enough to identify small failing regions that are dependent on several variables due to more subtle defects. This approach also limits or even prevents effective characterization for the whole chip and/or its regions at operation speeds while dynamically reconfiguring a chip or adjusting parameters similar to what might happen during chip application operations in the field.

Identifying these diverse and subtle defects and pinpointing the root cause of the problem in a large logic structure typically uses high-resolution diagnostic calls to isolate any defects, and to successfully complete the physical failure analysis (PFA) defect localization and/or quickly find and fix early design problems during verification. The resolution of state-of-the-art logic diagnostic algorithms and techniques depend on the number of tests being conducted and the amount of passing and failing test result data available for each fault and/or design issue. Conventional methods of generating failures and collecting associated test results might be insufficient to achieve the desired diagnostic resolution. Further, reconfiguring and isolating other regions of a complex multi-core or SOC (system on a chip) design is necessary, by conventional methods, for effective characterization of good and bad chips.

Today's complex SOCs typically have additional on-chip support to adaptively and dynamically reconfigure the chip using techniques including, but not limited to, power fencing, clock gating, reconfigurable data paths, and bypassing memory and logic, all during the multidimensional parameter shmoo process. Due to the nature of these large and very complex design configurations and the parameter shmooing matrices, this novel diagnostic and characterization method using a design for test (DFT) microcontroller with diagnostic data storage is used to provide on-chip programmable and iterative diagnostic and characterization procedure that can be loaded on chip and work interactively with a traditional tester. Thus, today's large SOC design characterization and problem isolation is limited by large external characterization instrumentation typically on Automated Test Equipment (ATE) or bench test equipment.

Today's adaptive characterization and diagnostics is limited to chip scan loads to control chip configuration and other conditional parameters. Scan unloads might also be required to observe internal chip DFT monitoring and results registers. Complex SOCs continue to cause complex AC and subtle intermittent problems. Chip shmoo DFT is used to monitor and control chip configurations during shmoo and characterization.

Problem isolation sometimes requires dynamic chip reconfiguration such as changing clock speeds, enabling and disabling clocks, chip region select and deselect, bypassing regions such as memory, and adjusting internal DACs for voltage, timing, and the like. Dynamic, at-speed reconfiguration is typically performed during standard shmooing like voltage, timing, and temperature.

Embodiments disclosed herein propose the use of ‘device-assisted’ characterization and diagnostic method by integrating adaptive, at-speed reconfigurability, critical parameter control and observability, and on-chip data analytics within the device design. These dynamically adaptive built-in controls, in conjunction with interactive shmoo tools, result in effective characterization & diagnostic methods applicable to functional and structural testing.

Embodiments presented herein provide on-chip DFT shmooing logic which executes a built-in self-test circuit or shmoo instruments and dynamically alters the test circuit or shmoo conditions based on the real-time results recorded during testing. Traditionally, the conditions and chip configurations have been varied through external control or scan loads. In the alternative, a predefined set of test conditions could be programmed into an on-chip controller. What is disclosed here is a built-in method which dynamically adjusts the circuit instruments or shmoo based on results of the test. Items including, but not limited to on-chip scan configuration, chip clock skew, voltage regulators, voltage pumps, level shifters, OCCG (On Chip Clock Generators) and PLLs (Phase Lock Loops), timing circuits, elastic I/O DLLs (Chip Input/Output Driver & Receiver Delay Lock Loops) along with their associated controllers can be adjusted based on any test or shmoo response. Other DFT logic, such as noise generators, jitter generators, and thermal heaters, can also be deployed to modulate and simulate system environments during functional operation to help diagnose product Accepted Quality Level field fails. These can be either complex fault test escapes or reliability life failures in the system. These types of fails can be particularly difficult to repeat due to lack of a real system environment running complex system instructions at varying chip and system conditions. Hence, embodiments presented herein can adapt based on the real-time results as well as many chip parameters enabling a very complex multi-dimensional test or shmoo closer to the failing conditions.

For this process, “done” will be defined differently depending on the goal of the analysis. If the goal is diagnostic, the analysis will iterate until the conditions which excite the fail are clearly understood. Conditions being tested can include voltage, temperature, timing, chip configuration, and many other parameters. If the goal is characterization then the analysis continues until the operating range of the product operational space is clearly understood.

An on-chip test-assist microcontroller is programmed with a pre-determined characterization test or diagnostics flow or shmoo and characterization flow. The microcontroller has access to all of the SOC DFT controls to dynamically and adaptively adjust on-chip timing, voltage, clock, configuration registers, and many other chip configuration characteristics. A shmoo or sequential set of tests can be performed by controlling all of these parameters at chip speeds during dead cycles or cycle sharing. Large amounts of data can be stored in an on-chip test results memory, which can be immediately analyzed by an on-chip analytics processor. The analytics processor can be pre-programmed to perform adaptive and conditional shmoos and/or change characterization flows, parameters, and configurations based on the analyzed results.

With reference toFIG. 1, a block diagram presenting an overview of an embodiment is presented.FIG. 1illustrates a test system110that can be used to test a device under test (“DUT”)150. Test system110is coupled to device under test150via data lines116and control lines118. Within test system110is a program test flow112that can contain the information and parameters that will be used to test device under test150. The information and parameters that will be used for testing include, but are not limited to, device setup, test sequencing, pattern load, pattern modification, pattern execution, microcontroller sequencing information, and results processing.

Test system110can also include a pattern memory114. Program test flow112can be loaded into pattern memory114. In addition, program test flow112is coupled to device under test150via control lines118. Pattern memory114is coupled to device under test150via data lines116. Device under test150includes a microcontroller152. Device under test150also has several additional modules, including configuration select154, logic poke registers, logic stimulation, and observation of results156, and parameter modify158. The operation of the system shown inFIG. 1is described in greater detail below inFIG. 2.

A flowchart illustrating a method200is presented inFIG. 2. Method200is merely exemplary and is not limited to the embodiments presented herein. Method200can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, processes, and/or activities of method200can be performed in the order presented. In other embodiments, the procedures, processes, and/or activities of method200can be performed in any other suitable order. In still other embodiments, one or more of the procedures, processes, and/or activities of method200can be combined with additional steps or skipped. The blocks located within block210can be executed by test system110. The blocks located within block250can be executed by device under test150.

The process starts at block212. The test system begins program execution (block214). The initial setup of the device under test is performed (block216). Basic tests are then performed (block218). Basic tests can include the operation at various timings, voltages, and temperatures on a subset of patterns to first verify the chip is mostly defect free and able to load and run a test program and verify that the DFT features are all working properly. If the basic tests fail, the device under test is marked as a failure and appropriate actions are taken on the device (block220). For example, a failed device can be recycled or otherwise prevented from being further tested, characterized or released. In some cases, tests will continue for yield learning to diagnose fails to root cause and Failure Analysis (FA).

If the device under test passes the basic test, the microcontroller of the device under test is loaded with a program test flow (block222) then the microcontroller begins execution of the loaded program test flow for a more complex set of tests and characterization procedures (block224).

At the device under test, the program test flow is loaded into the microcontroller (block252). The device under test is configured (block254). Thereafter, the program test flow, containing an adaptive built-in test, is executed (block256). The parameters in the program test flow can change aspects or parts of the device under test that are not typically accessible by external testers. These can include, but are not limited to, on-chip scan configuration, chip or core region select, test type, on chip BIST engine selection and BIST programs or patterns, chip clock skew, voltage regulators, voltage pumps, level shifters, OCG (On Chip Clock Generators) and PLLs (Phase Lock Loops), timing circuits, elastic I/O DLLs (Chip Input/Output Driver & Receiver Delay Lock Loops), and partial-good repairs and redundancy selections.

Once the built-in test containing the initial set of parameters is executed, it is checked to see if the test is done (block258). If not, then another iteration of configuration and logic parameters is loaded (block260) and operation resumes at block254. Otherwise, control returns to the test system. A key aspect of some embodiments is that a second iteration from block260can be dynamically selected based on results from a first adaptive test. Then a third iteration from block260can be dynamically selected based on results from the first and second adaptive tests and so on. This continues until the desired result is reached or the on chip test program is exhausted. Additional test programs can also be loaded to start more on chip test flow passes until a desired result is completed.

At the test system, the results are analyzed (block228). It is determined if the device under test passed or failed the diagnostics (block230). If further diagnostics are needed, then the device under test is loaded with further diagnostic and characterization data (block234) and the method resumes at block224. Otherwise, the test ends (block232).

What follows are a few examples of the use of an embodiment in testing various chips. A flowchart illustrating a method300is presented inFIG. 3. Method300is merely exemplary and is not limited to the embodiments presented herein. Method300can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, processes, and/or activities of method300can be performed in the order presented. In other embodiments, the procedures, processes, and/or activities of method300can be performed in any other suitable order. In still other embodiments, one or more of the procedures, processes, and/or activities of method300can be combined or skipped.

Method300illustrates the operation of an embodiment when testing a memory chip or embedded memory within an SOC. The initial system configuration information is set (block302). The test is begun, using the configuration information (block304). It is determined if the memory passed the test (block306). If the memory did not pass, then the failure information is gathered (block312). The failure conditions are noted in a log (block316) and a repair is made (block318). Operation then resumes at block304, with the memory being tested again.

If the memory or a sub-memory array passes or fails, it is determined if there are other configurations (such as other voltages, frequencies, memory physical configurations and the like are to be tested (block320). Other configurations may encompass modifying internally generated voltage sources by modifying Digital-to-Analog Converters (DACs) settings. If there are other configurations to be tested, the new configuration, including other frequencies and voltages, is selected and loaded into the tester (block322). Thereafter, operation resumes at block304. If there are no other configurations to be tested, then any repair actions are implemented (block324) and the first test operation is complete (block326). After repair, memory testing may resume to verify the repair(s) and may continue to further test the memory to more complex memory disturb, retention, or AC tests until the memory performs to product like applications and at speed conditions for a full memory characterization and analysis.

A flowchart illustrating a method400is presented inFIG. 4. Method400is merely exemplary and is not limited to the embodiments presented herein. Method400can be employed in many different embodiments or examples not specifically depicted or described herein. In some embodiments, the procedures, processes, and/or activities of method400can be performed in the order presented. In other embodiments, the procedures, processes, and/or activities of method400can be performed in any other suitable order. In still other embodiments, one or more of the procedures, processes, and/or activities of method400can be combined or skipped.

Method400illustrates the use of an embodiment when testing a chip that can be controlled by both on-chip and off-chip instruments. A test program containing operational and conditional parameters is loaded onto the chip, which can be controlled by both off-chip and on-chip instruments (block402). Operational parameters might include test time controls that run cores or other chip regions of the DUT in parallel or sequentially. Other operational parameters could include programmable sensor controls that control, measure, and store on-chip temperature, on-chip clock frequency, and various voltage domains during the testing process. The parameters and configuration can then be verified (block404). Options might be made available for on-chip calibration test. Additionally, a test shutdown can occur if the programmed conditions like on-chip temperature, frequency, and voltage are not met or preliminary test instrumentation checks fail. At block406, the setup conditions and measured settings information can then be unloaded and evaluated to readjust any external tester and internal chip controls before an on-chip testing is restarted. Once all the conditions are satisfied, the first iteration is allowed to start (block410).

The first iteration can run a variety of tests and shmoos on the entire chip including logic regions, cores, and nest or glue logic and memory for a set of standard pre-loaded conditions such as temperature, timing, voltage, steps, test limits, and the start/stop of each test or set of shmoo parameters. All the programmed steps or start and stop boundaries can also be sampled for a very fast first iteration with results stored in an on-chip results memory (block412).

Results are stored and analyzed by an adaptive analytics processor. The first iteration summary is analyzed in an on-chip analytics processor and then adapted to run any number of pre-programmed test options and chip configurations to collect more detailed information (block414). This can also be a pre-programmed adaptive or conditional diagnostic for good and bad chip characterization.

At block414, the analytical processor may also provide the microcontroller instructions or conditional decisions to adapt the test flow or select any core or another chip region, as well as the shmoo and test program conditions and additional test data points to run. An adaptive and conditional test flow, test sequence, and test ranges can also be pre-programmed. Other items, such as logic, memory, or both, may also be selected or bypassed. Different test paths might also be selected. The analytical processor can analyze results and make cognitive decisions to redirect the adaptive test microcontroller for more testing based on the results.

At block416, it is determined if the testing is done. If not, then method400proceeds with block418, where the next iteration is selected using any number of pre-programmed configurations and set of shmoo parameters or any number of adaptive changes such as memory repairs and test conditions. In addition, the analytical processor may also be pre-programmed to collect more detailed information using additional data log parameters. Information can be collected by logging the chip by region or recording results in on-chip memory by pass/fail, fails only, or by fail count. Also, logging by fail types or by failing addresses or any other detailed points in a test or shmoo. At block420, new configuration register values are set and another iteration is run.

The second iteration results can be stored in the on-chip and/or off-chip memory and a preloaded adapted test or shmoo can continue or end. The second pass summary of fails can be stored in a separate detailed memory partition to preserve the first pass data (block422). The first and/or second pass results can then be re-evaluated by the analytical processor at block414. This can then be run for any number of iterations to adapt and run any number of programmed test and shmoo options. Objectives such as altering any condition or shmoo operation can be achieved to collect more detailed information on any chip region, processor core, analog circuit, RF circuit, or memory. A third iteration (or any subsequent iteration) also can be run. As an example, tasks such as deselecting failing or passing cores or chip regions and then restarting the same previously executed shmoo can be performed. Other tasks, such as repairing logic, input/output circuits, and memory, and running the tests or shmoo again also can be performed in subsequent iterations. When testing is considered done, the results are unloaded (block430) and method400ends (block432).

FIG. 5depicts a high level block diagram computer system500, which may be used to implement one or more embodiments of the present disclosure. More specifically, computer system500may be used to implement hardware components of systems capable of performing methods described herein. Although one exemplary computer system500is shown, computer system500includes a communication path526, which connects computer system500to additional systems (not depicted) and may include one or more wide area networks (WANs) and/or local area networks (LANs) such as the Internet, intranet(s), and/or wireless communication network(s). Computer system500and additional system are in communication via communication path526, e.g., to communicate data between them.

Computer system500includes one or more processors, such as processor502. Processor502is connected to a communication infrastructure504(e.g., a communications bus, cross-over bar, or network). Computer system500can include a display interface506that forwards graphics, textual content, and other data from communication infrastructure504(or from a frame buffer not shown) for display on a display unit508. Computer system500also includes a main memory510, preferably random access memory (RAM), and may also include a secondary memory512. Secondary memory512may include, for example, a hard disk drive514and/or a removable storage drive516, representing, for example, a floppy disk drive, a magnetic tape drive, or an optical disc drive. Hard disk drive514can be in the form of a solid state drive (SSD), a traditional magnetic disk drive, or a hybrid of the two. There also may be more than one hard disk drive514contained within secondary memory512. Removable storage drive516reads from and/or writes to a removable storage unit518in a manner well known to those having ordinary skill in the art. Removable storage unit518represents, for example, a floppy disk, a compact disc, a magnetic tape, or an optical disc, etc. which is read by and written to by removable storage drive516. As will be appreciated, removable storage unit518includes a computer-readable medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory512may include other similar means for allowing computer programs or other instructions to be loaded into the computer system. Such means may include, for example, a removable storage unit520and an interface522. Examples of such means may include a program package and package interface (such as that found in video game devices), a removable memory chip (such as an EPROM, secure digital card (SD card), compact flash card (CF card), universal serial bus (USB) memory, or PROM) and associated socket, and other removable storage units520and interfaces522which allow software and data to be transferred from the removable storage unit520to computer system500.

Computer system500may also include a communications interface524. Communications interface524allows software and data to be transferred between the computer system and external devices. Examples of communications interface524may include a modem, a network interface (such as an Ethernet card), a communications port, or a PC card slot and card, a universal serial bus port (USB), and the like. Software and data transferred via communications interface524are in the form of signals which may be, for example, electronic, electromagnetic, optical, or other signals capable of being received by communications interface524. These signals are provided to communications interface524via communication path (i.e., channel)526. Communication path526carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and/or other communications channels.

In the present disclosure, the terms “computer program medium,” “computer usable medium,” and “computer-readable medium” are used to generally refer to media such as main memory510and secondary memory512, removable storage drive516, and a hard disk installed in hard disk drive514. Computer programs (also called computer control logic) are stored in main memory510and/or secondary memory512. Computer programs may also be received via communications interface524. Such computer programs, when run, enable the computer system to perform the features of the present disclosure as discussed herein. In particular, the computer programs, when run, enable processor502to perform the features of the computer system. Accordingly, such computer programs represent controllers of the computer system. Thus it can be seen from the forgoing detailed description that one or more embodiments of the present disclosure provide technical benefits and advantages.

Referring now toFIG. 6, a computer program product600in accordance with an embodiment that includes a computer-readable storage medium602and program instructions604is generally shown.

The present disclosure may be a system, a method, and/or a computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.