What is dft design for test?

Designing for Test, Testability, Sustainment, etc. must be a multiple disciplinary-inclusive process without design domain barriers. The activity must coexist as an efficient and exhaustive approach that always has an eye on the sustainment objectives and thereby contributes to the forming of a byproduct knowledgebase. But to gain any true knowledgebase, data artifacts retrieved from the integration of relevant, disciplinary-owed data would need to be formally “integrated”, which is beyond the simple “sharing” of data.

Since the objective of “Design For Testability” was intended to be to “Develop for the Sustainment lifecycle during Design Development”, any DFT activity would require the gathering, restructuring and organization of the DFT data for any and all of the designs comprising the “system” AND how each design is “interrelated” to any other design(s) within a fielded product (“Integrated System”).

When focused on any independent design, DFT is important and can be extremely valuable. But for an interdependent design, the awareness of the entire functional scope of all designs that may have been developed by other design teams or organizations, is equally imperative consideration as design complexity and intended operational sophistication increases. As independently developed designs are integrated into larger designs, it is often the case that assemblies, subsystems or the fielded product, cannot conclusively rely on the “selective” DFT activities performed exclusively for each independent lower-level designs. Therefore, it is too often discovered that the independently-applied DFT to any exclusive design piece is no longer equally applicable to its manufacturing value, when realized from the “fielded product” and supportability perspective. Unless the (functional and failure) interrelationships for each independent design are established in an integrated systems’ diagnostic architecture, the utility of DFT for improving the operational availability of the fielded product is subject to being inadvertently subverted.

When the capturing of the functional and failure interdependencies between each design entity, regardless of design domain (electronic, hydraulic, mechanical, optical or software, etc.), is performed, then the DFT is significantly more effective. As such, the holistic integrated-systems’ DFT, is now capable of determining corresponding (operational) Fault Groups for the fielded product in accordance with any (operational) “integrated” diagnostic constraints. It then follows that the transitioning to designing for sustainment diagnostic design may begin.

In a diagnostic engineering analysis, there are several critical issues to be considered. Probably the most critical among them is “Test Coverage”. Test Coverage describes which components in the design are being included in a particular diagnostic test. Diagnostic testing refers to a process, similar to measurement testing, where the analysis is able to determine whether a component can be indicted or exonerated. Consequently, the accumulation of diagnostic evaluations lead to a “Diagnostic Conclusion” or hypothesis.

As comprehensive as that approach sounds, it is impure. Quite often, the diagnostic analysis can be influenced by a concept known as Interference”. Interference is a systemic characteristic of most every complex design, where unexpected components, or their functions—upstream, downstream, or tangential to the defined diagnostic test coverage—are able to impact the diagnostic hypothesis. The only way that this kind of diagnostic Interference can be discovered is by the assessing of the diagnostic integrity of that design within an advanced diagnostic engineering endeavor. This is a core competency of the eXpress diagnostic engineering application that excels in this area, which is the primary reason why eXpress is sought to deliver on the diagnostic demands of the largest or most complex systems designed today.

As a result of this rich coverage analysis capability, the diagnostic interpretation of a testability analysis becomes quite extensive and accurate, regardless of whether the captured eXpress design is a small, or when assed interdependently other designs or subsystems in a much larger capacity. As a consequence of this higher level of analysis, disparities in Built-In-Test (BIT) test coverage may be found to be deficient in the operational state in a deployed environment. For this reason, it then becomes possible to unlock more associated treasures when performing of DFT, DfT and DTT in the test environment. Ultimately, this is a critical step in the transitioning to an effective diagnostic acumen that can be immediately deployed along with the certainty of fielding an accurate, consistent and reliable sustainment support strategy.

When interdisciplinary design data is able to be collected, (re)structured and (re)organized in a consistent and deliberate manner that enables the establishing of the functional or failure interdependencies and interrelationships within any complex system, a “Diagnostic Design Knowledgebase” is able to be formed. In the using of the eXpress diagnostic engineering tool, several critical steps are accomplished that lead to the establishing of a Diagnostic Design Knowledgebase.

The first step is the creation of a model that establishes the functional interrelationships between objects or very high-level functional systems, if performed early in design development.  A more complex system’s model will be framed by the use of empty functional models until more detail is determined or available during development, allowing high-level feedback to influence diagnostic design to meet the objectives of alternative sustainment approaches.

As the design development progresses, the functional interrelationships can be synced up with other “integrated designs”. In a larger sense this is the capturing of the functional or failure interrelationships within each “subsystem” and any lower-level design(s) and their interdependent designs within any given hierarchical “integrated system” structure. This design activity takes advantage, and “leverages” the producing of a Dependency Analysis, or the way that components’ test points, interconnections, and other models are interrelated throughout the integrated systems hierarchy. As mentioned above, diagnostic tests are incorporated to take advantage of the coverage revealed during modeling preparations. Finally, various Diagnostic Analysis Studies can comprise all the modeling information together to assess and improve as an “integrated” capability.

From that point forward, the appropriate Test Coverage for each point of test, observation or location of health status interrogation (BIT sensors, ATE, etc.), as based upon such diagnostic analyses, will all be brought together to provide an “agile” Diagnostic Design Knowledgebase. This knowledgebase will represent the captured expert diagnostic design in such a form that it can be shared, assessed, modified, validated and augmented with other design or support activities or partnering organizations. Obviously, capturing and validating the test coverage for complex systems is an inherent, and unique, advantage of using eXpress.

Design for Test as used by professionals in the semiconductor industry, have an acutely specialized understanding of DFT. As such, this activity concerns itself with digital designs using techniques as ABIST, AMBIST, ATPG, Boundary Scan, BSC, BSR, CBIST, FASTSCAN, IBIST, JTAG, Logic Test, LOGICBIST, MBIST, Memory Test, Mixed-Signal Test, etc. While these are, today, established techniques and have significant merit at that specific piece of DFT, the investment into this flavor of DFT has not been generating enough attention as a valuable or reusable asset for the systems’ integrator for larger “integrated” products (trains, military vehicles, missile systems, airplanes, etc.). This will continue to be a challenge for the DFT community in this sector until it reaches out to integrate with methods or tools that can leverage this investment with, and across, other designs and design domains in a seamless transition, and become effective in supporting any evolving sustainment paradigm(s).

The use of system is not universally understood to be narrowly specific, so it would be otherwise advantageous to embrace the broadest understanding of the term, “system”. It therefore becomes critical, regardless of whatever DFT, DfT or DTT activities are embraced, that the investment made should lead to a meaningful interconnectivity into other interdependent design domains, activities throughout the sustainment lifecycle. Consequently, such expanded program value need to address benefits to the servicing and balancing of four (4) significant goals of testability:

1. Availability of Equipment or Systems 2. Operational or Mission Success, or Reliability 3. Operational Safety 4. Cost of Ownership

The various “illities” (e.g., testability, reliability, maintainability, sustainability, etc.) aspire to perform co-related activities as an effort to integrate a system’s ability to be developed and supported effectively. But in the servicing of this objective, these disciplines typically behave as competing activities that, unfortunately, aspire to achieve a greater priority, and thereby, greater influence on program budget.

To bring everything together, it is fair to assert that the objective of designing for sustainment includes the interdependence on all of the design and support activities as noted above. Therefore, the real focus in diagnostic engineering should be to influence the design activity whenever and however possible. It should be inclusive of all design disciplines and not restricted to any specific design domain (e.g. digital). The most optimal dividend of such a solution would be to establish a test tool independent capability, which was the originally intended scope of the full systems testability discipline. Consequently, these are just some of the initial benefits of embracing a much broader vision by today’s DFT community. Fortunately, it is encouraging that some 50 years after its introduction to industry, industry is finally learning to appreciate that Design For Testability really needs to be more broadly encouraged as an essential design influence activity.

Ultimately, DFT needs to be carried out of the production lab environment and integrated into the sustainment environment, but in a way that is directly reused and repurposed from within its integration within the expert captured (diagnostic design) knowledgebase. This must not be design-domain limited, nor exclusive to any independent DFT tools, methods or interpretation of any DFT requirements. DFT can then “Set the Table” for much more comprehensive diagnostic tools to leverage its low-level “Test Coverage” capability across domains, design hierarchies, partnering organizations and a myriad of current and evolving sustainment methods and paradigms.

With ISDD, investment into DFT can be much more broadly (re)used in a Design for Sustainment (DFS) paradigm.

The role of DFT in the process described in the image above, is to provide an output that describes the test coverage of the functions on any of the designs. This “test” data can be either imported and captured in the eXpress diagnostic modeling tool environment. From this point, the diagnostic capability can be fully validated at any point used by the diagnostics as required by the sustainment philosophy of the fielded or operational asset.

Today, semiconductors lie at the heart of ongoing advances across the electronics industry. The introduction of new technologies, especially nanometre technologies with 14 nm or smaller geometry, has allowed the semiconductor industry to keep pace with increased performance-capacity demands from consumers. This has brightened the prospects for future industry growth.

However, new technologies come with new challenges. Smaller die sizes increase the probability of some errors. Errors in ICs are highly undesirable. Here’s a list of some possible issues that arise while manufacturing chips.

The possibility of faults may arise even after fabrication during the packaging process.

With all these issues in mind, it becomes vital to test every chip before it can be shipped and in fact, test it after every level of manufacturing.

Testing does not come for free. Modern microprocessors contain more than 1000 pins. They pack a myriad of functionalities inside them. If any single transistor inside a chip becomes faulty, then the whole chip needs to be discarded. We, consumers, do not expect faulty chips from manufacturers. But identifying that one single defective transistor out of billions is a headache. We may need to test every functionality with every possible combination. If testing is done that way, then the time-to-market would be so high that the chips may never reach the consumers. So, how do we tackle this? We use a methodology to add a feature to these chips. The methodology is called DFT; short for Design for Testability. And the feature it adds to a chip is ‘testability.’

So, does testing guarantee that the chip will never be faulty again?

No, faults can arise even after the chip is in consumer’s hands. A chip may misbehave anytime if it is exposed to a very high temperature or humid environment or due to aging.

Want a live explanation? If you have an unlocked processor, you can try to overclock your CPU using this tutorial. But would you do it? Please don’t!

Overclocking is a method to increase the system frequency and voltage above the rated value.  An improperly configured overclocking can mess up with timing metrics and cause instability. Prolonged overclocking would overheat and stress out your system to shorten the lifespan of your computer. This may cause intermittent faults in the chip and random crashes in the future. Adding to this, it may void your warranty too. This example is just one high-level explanation of how a fault may occur in real life.

Verification proves the correctness and logical functionality of the design pre-fabrication. The process is done after the RTL (Register Transfer Logic) design is coded with hardware description languages like VHDL or Verilog. It is done using a testbench in a high-level language. This is performed only once before the actual manufacturing of chip. In industry, this is done using formal verification processes like UVM (Universal Verification Methodology) using System Verilog. Verification is a vast topic on its own and we will cover it in this VLSI track and link it here soon.

In contrast, testing tries to guarantee the correctness of the manufactured chips at every abstraction level of the chip design process. Testing needs to be performed on each manufactured chip because each one of them has an equal probability of being faulty during the fabrication or packaging process. By doing testing, we are improving the quality of the devices that are being sold in the market.

Let’s segue into the career aspect of these two stages for a moment.

Here are a few terminologies which we will often use in this free Design for Testability course. Don’t fret if you can’t completely understand them yet, we will be covering them in-depth in this course.

Testing: An experiment in which the system is put to work and its resulting response is analyzed to ascertain whether it behaved correctly.

Diagnosis: Process for locating the cause of misbehavior in the circuit if it happened.

Defect: Refers to a flaw in the actual hardware or electronic system.

Fault: It is a model or representation of defect for analyzing in a computer program.

Error: It is caused by a defect and happens when a fault in hardware causes line/ gate output to have a wrong value.

Failure: This occurs when a defect causes misbehavior in the circuit or functionality of a system and cannot be reversed or recovered.

Fault Coverage: Percentage of the total number of logical faults that can be tested using a given test set T.

Defect Level: Refers to the fraction of shipped parts that are defective. Or, the proportion of the faulty chip in which fault isn’t detected and has been classified as good.

where Y is the yield, means the fraction of the chips fabricated that are good.

Testing is carried out at various levels:

There is an empirical rule of thumb that it is ten times more expensive to test a device as we move to the next higher level (chip → board → system). As we move to higher levels, more components are integrated, which makes the fault detection and localization much more difficult and expensive.

Here are a few possible sources of faults:

Faults can be classified into various subcategories.

DFT techniques are broadly classified into two types:

These are a collection of techniques or set of rules (do’s and don’ts) in the chip design process learned from design experience to make design testability more comfortable to accomplish. Basically, these are the rules that have been gathered over time after experiencing various errors.

In this technique, extra logic and signals are added to the circuit to allow the test according to some predefined procedure.

Tests are applied at several steps in the hardware manufacturing flow and, for certain products, may also be used for hardware maintenance in the customer's environment. The tests are generally driven by test programs that execute using automatic test equipment (ATE) or, in the case of system maintenance, inside the assembled system itself. In addition to finding and indicating the presence of defects (i.e., the test fails), tests may be able to log diagnostic information about the nature of the encountered test fails. The diagnostic information can be used to locate the source of the failure.

In other words, the response of vectors (patterns) from a good circuit is compared with the response of vectors (using the same patterns) from a DUT (device under test). If the response is the same or matches, the circuit is good. Otherwise, the circuit is not manufactured as it was intended.

DFT plays an important role in the development of test programs and as an interface for test application and diagnostics. Automatic test pattern generation, or ATPG, is much easier if appropriate DFT rules and suggestions have been implemented.

DFT techniques have been used at least since the early days of electric/electronic data processing equipment. Early examples from the 1940s/50s are the switches and instruments that allowed an engineer to "scan" (i.e., selectively probe) the voltage/current at some internal nodes in an analog computer . DFT often is associated with design modifications that provide improved access to internal circuit elements such that the local internal state can be controlled (controllability) and/or observed (observability) more easily. The design modifications can be strictly physical in nature (e.g., adding a physical probe point to a net) and/or add active circuit elements to facilitate controllability/observability (e.g., inserting a multiplexer into a net). While controllability and observability improvements for internal circuit elements definitely are important for test, they are not the only type of DFT. Other guidelines, for example, deal with the electromechanical characteristics of the interface between the product under test and the test equipment. Examples are guidelines for the size, shape, and spacing of probe points, or the suggestion to add a high-impedance state to drivers attached to probed nets such that the risk of damage from back-driving is mitigated.

Over the years the industry has developed and used a large variety of more or less detailed and more or less formal guidelines for desired and/or mandatory DFT circuit modifications. The common understanding of DFT in the context of Electronic Design Automation (EDA) for modern microelectronics is shaped to a large extent by the capabilities of commercial DFT software tools as well as by the expertise and experience of a professional community of DFT engineers researching, developing, and using such tools. Much of the related body of DFT knowledge focuses on digital circuits while DFT for analog/mixed-signal circuits takes somewhat of a backseat.

DFT affects and depends on the methods used for test development, test application, and diagnostics.

Most tool-supported DFT practiced in the industry today, at least for digital circuits, is predicated on a Structural test paradigm. Structural test makes no direct attempt to determine if the overall functionality of the circuit is correct. Instead, it tries to make sure that the circuit has been assembled correctly from some low-level building blocks as specified in a structural netlist. For example, are all specified logic gates present, operating correctly, and connected correctly? The stipulation is that if the netlist is correct, and structural testing has confirmed the correct assembly of the circuit elements, then the circuit should be functioning correctly.

Note that this is very different from functional testing, which attempts to validate that the circuit under test functions according to its functional specification. This is closely related to functional verification problem of determining if the circuit specified by the netlist meets the functional specifications, assuming it is built correctly.

One benefit of the Structural paradigm is that test generation can focus on testing a limited number of relatively simple circuit elements rather than having to deal with an exponentially exploding multiplicity of functional states and state transitions. While the task of testing a single logic gate at a time sounds simple, there is an obstacle to overcome. For today's highly complex designs, most gates are deeply embedded whereas the test equipment is only connected to the primary Input/outputs (I/Os) and/or some physical test points. The embedded gates, hence, must be manipulated through intervening layers of logic. If the intervening logic contains state elements, then the issue of an exponentially exploding state space and state transition sequencing creates an unsolvable problem for test generation. To simplify test generation, DFT addresses the accessibility problem by removing the need for complicated state transition sequences when trying to control and/or observe what's happening at some internal circuit element. Depending on the DFT choices made during circuit design/implementation, the generation of Structural tests for complex logic circuits can be more or less automated or self-automated. One key objective of DFT methodologies, hence, is to allow designers to make trade-offs between the amount and type of DFT and the cost/benefit (time, effort, quality) of the test generation task.

Another benefit is to diagnose a circuit in case any problem emerges in the future. Its like adding some features or provisions in the design so that device can be tested in case of any fault during its use.

One challenge for the industry is keeping up with the rapid advances in chip technology (I/O count/size/placement/spacing, I/O speed, internal circuit count/speed/power, thermal control, etc.) without being forced to continually upgrade the test equipment. Modern DFT techniques, hence, have to offer options that allow next generation chips and assemblies to be tested on existing test equipment and/or reduce the requirements/cost for new test equipment. As a result, DFT techniques are continually being updated, such as incorporation of compression, in order to make sure that tester application times stay within certain bounds dictated by the cost target for the products under test.

Especially for advanced semiconductor technologies, it is expected some of the chips on each manufactured wafer contain defects that render them non-functional. The primary objective of testing is to find and separate those non-functional chips from the fully functional ones, meaning that one or more responses captured by the tester from a non-functional chip under test differ from the expected response. The percentage of chips that fail test, hence, should be closely related to the expected functional yield for that chip type. In reality, however, it is not uncommon that all chips of a new chip type arriving at the test floor for the first time fail (so called zero-yield situation). In that case, the chips have to go through a debug process that tries to identify the reason for the zero-yield situation. In other cases, the test fall-out (percentage of test fails) may be higher than expected/acceptable or fluctuate suddenly. Again, the chips have to be subjected to an analysis process to identify the reason for the excessive test fall-out.

In both cases, vital information about the nature of the underlying problem may be hidden in the way the chips fail during test. To facilitate better analysis, additional fail information beyond a simple pass/fail is collected into a fail log. The fail log typically contains information about when (e.g., tester cycle), where (e.g., at what tester channel), and how (e.g., logic value) the test failed. Diagnostics attempt to derive from the fail log at which logical/physical location inside the chip the problem most likely started. By running a large number of failures through the diagnostics process, called volume diagnostics, systematic failures can be identified.

In some cases (e.g., Printed circuit boards, Multi-Chip Modules (MCMs), embedded or stand-alone memories) it may be possible to repair a failing circuit under test. For that purpose diagnostics must quickly find the failing unit and create a work-order for repairing/replacing the failing unit.

DFT approaches can be more or less diagnostics-friendly. The related objectives of DFT are to facilitate/simplify fail data collection and diagnostics to an extent that can enable intelligent failure analysis (FA) sample selection, as well as improve the cost, accuracy, speed, and throughput of diagnostics and FA.

The most common method for delivering test data from chip inputs to internal circuits under test (CUTs, for short), and observing their outputs, is called scan-design. In scan-design, registers (flip-flops or latches) in the design are connected in one or more scan chains, which are used to gain access to internal nodes of the chip. Test patterns are shifted in via the scan chain(s), functional clock signals are pulsed to test the circuit during the "capture cycle(s)", and the results are then shifted out to chip output pins and compared against the expected "good machine" results.

Straightforward application of scan techniques can result in large vector sets with corresponding long tester time and memory requirements. Test compression techniques address this problem, by decompressing the scan input on chip and compressing the test output. Large gains are possible since any particular test vector usually only needs to set and/or examine a small fraction of the scan chain bits.

The output of a scan design may be provided in forms such as Serial Vector Format (SVF), to be executed by test equipment.

In addition to being useful for manufacturing "go/no go" testing, scan chains can also be used to "debug" chip designs. In this context, the chip is exercised in normal "functional mode" (for example, a computer or mobile-phone chip might execute assembly language instructions). At any time, the chip clock can be stopped, and the chip re-configured into "test mode". At this point the full internal state can be dumped out, or set to any desired values, by use of the scan chains. Another use of scan to aid debug consists of scanning in an initial state to all memory elements and then go back to functional mode to perform system debug. The advantage is to bring the system to a known state without going through many clock cycles. This use of scan chains, along with the clock control circuits are a related sub-discipline of logic design called "Design for Debug" or "Design for Debuggability".

But with all the technological advancement, the chances of faults and drawbacks have also increased. Therefore design for testability (DFT) enters the arena!

Also read: job opportunities in VLSI and embedded system

DFT in VLSI is an innovative design technique to make testing a chip cost-effective by adding circuitry to the chip. They improve the observability and controllability of internal nodes to increase the testability of all logic in the chip

There are several problems associated with the manufacturing of chips. A few of them are:

Also read: Career growth for a DFT engineer

Therefore, DFT in VLSI helps to have thorough testing of chips and avoid the chances of any fault.

Design for testability (DFT) covers the following areas in the life cycle of a chip:

Helping with all these stages can yield better quality of results, faster development cycle, the better quality of product and easier diagnostics.