Patent Application
20080091981
Failure Type Classification
Semiconductor test programs are typically organized such that scan tests are divided into three areas: Chain Integrity Tests, Stuck-At Tests, and AC-Scan tests. Chain Integrity Tests validate that the scan chains are operational and can be used by the Stuck-At and AC-Scan Tests to check logic. The Stuck-At Tests validate that all logic paths are operational and are not stuck to either a high or low state. The AC-Scan Tests validate that logic paths can be transitioned in suitable time to meet the mission of the device design.
The flow chart in
The flow chart adds a decision after Chain Integrity Test failures: Analyze Chain? If this decision is true, the Blocked Chain Analysis process will be invoked to find the position in the scan chain where the block occurs. If the chain break position is found, the failures can be categorized as RESOLVED BROKEN CHAIN.
The flow chart adds a decision after AC-Scan Test failures: Analyze Speed? If this decision is true, the SpeedScan process will be invoked to find path delay values. Once the failing paths are measured, the failures can be logged as PATH DELAY.
Defect Location
Since available data files do not identify the potential defect locations clearly, the invention comprises a process to create a useful database consisting of the following computer implemented methods:
Multiple Name Space Resolution and Navigation
In order to pinpoint the region on a die where a circuit structure exists, it is necessary to traverse the relationship between the implemented component list and the physical dimensions of the die. This relationship is found in the combination of DEF and LEF files. These file formats are defacto standards generally known and used by those skilled in the arts of semiconductor equipment manufacturing and electronic design automation software development. In practice this approach is too slow to be economically useful. An embodiment of the present invention uses a special built data structure.
Parsing the LEF Files
Tracing the layout efficiently becomes feasible by first converting the library information into a query-able format. A process technology for a chip may have on or more LEF files. Information such as MACRO size, port location, and port direction can be found in this file system. In addition, via descriptions can also be found in the LEF files.
Parsing the DEF Files
The next step in enabling trace operations of a circuit from layout data is to convert the DEF files into a query-able format. There may be one or more DEF files that describe the chip. If more than one DEF file is needed to describe the chip, a relationship must be identified between the MACRO name and the name of the DEF file that it is associated. The present DEF file syntax does not provide a way to communicate this relationship. Once the MACRO to DEF file relationships have been learned, the DEF files must be merged to together. For simplicity, each MACRO to DEF relationship defines a DEF module.
The process of parsing the LEF and DEF files, comprises the methods following: Merging DEF Files, Concatenating Hierarchy, Recalculating XY Coordinates, Recalculating Orientation Facings, and Merging Nets.
Merging DEF Files
Several pieces of information must be managed when merging 2 or more DEF files together. The process of merging DEF files consists of a recursive method which begins at the top DEF module. The process takes the learned list of DEF modules and compares the list against component MACRO names found in the DEF file. When a DEF module is encountered, the DEF module is then converted into a database format. This process continues recursively until there are no other DEF modules being instantiated at the leaf boundary. All DEF blocks and statements are stored in the database. Once the last leaf DEF module has been processed, the parent DEF module entries are then revised with the child DEF module expanded.
The integration of the child module into its parent module takes place in the form of several processing steps. These steps include
Concatenating Hierarchy
In order to reflect the full netlist hierarchy as it was intended by the original Verilog or VHDL netlist, MACRO instance names that are found in the COMPONENTS section of the DEF are concatenated together. However, the resultant name could be encoded to either shrink the size of the stored database or to provide a level of security against the interpretation of circuit intent (i.e., IP protection)
In addition to updating the instance name in the COMPONENTS section of the DEF, the instance names found in the connection lists of the NETS and SPECIALNETS sections must also be modified.
Recalculating XY Coordinates
The ultimate goal of XY coordinate recalculation is to understand an entity's placement with respect to the origin of the complete die boundary. The die boundary is given in the top DEF module as the DIEAREA statement. The entities in a DEF file that have XY coordinates are components, nets, specialnets, vias, and obstructions.
In order to recalculate the XY coordinates associated with each of those entities, XY coordinate transform equations were developed. Inputs to these equations are
Recalculating Orientation Facings
In order to get the correct orientation facing, conversion tables use the current child component orientation and the child DEF module orientation target as lookup indexes with the conversion output being the orientation with respect to the parent module. Thus, the orientation conversion table consists of 64 possible index combinations where each index can be one of the following eight orientation facings:
Merging Nets
In general, nets names live a double life. On one hand, a net name can be obfuscated like “W21” and on the other hand, the net name could be self-documenting such as “CLK2_net”. When it comes to merging a child DEF module with a parent DEF module, an issue arises where two nets meet at a module boundary. To get around this issue, a merging process monitors the port directions on the net. The name of the net chosen depends on the origination of the port driving the net.
If the port driving the net originates from the parent module, then the net name of the parent is used and the connection list of the child module is appended to the parent's connection list. The same is said of the XY coordinate list and via content of the route. If the port driving the net originates from within the child module, then the result of concatenating the hierarchical path to the child module and the net name of the child is used as the new net name. The new net name is stored in the parent modules database. The parent port connection list is concatenated with the child nets connection list and is associated with the new net name. Likewise, the XY net coordinate and via content in the original parent net entry are concatenated with the child net XY coordinates and via content. After the parent net information has been merged with the child net information, the original parent net entry in the parent database is deleted. The XY coordinate data of the child nets are recalculated during the merge operation.
Content
Each major syntax block (NETS, COMPONENTS, SPECIALNETS, MACRO, etc.) that is contained in any LEF file and/or any DEF file comprises specific block type entry statements. These statements are stored in a key-value context by using the item name as the key and the LEF or DEF description statement as the value.
Various pieces of information about items at an instance name level are stored by the present invention. The keys that are stored comprise:
Values to the above keys are comprise one of a key to other database and a full content description of a DEF or LEF entry.
Store Process
Various cross reference relationships are created throughout several associative arrays (key-value) database files. At least one of the database files created is a multi-dimensional database which enables an optimized multi-dimensional query of the LEF MACROs, PIN names, and I/O direction.
Other storage architecture enhancements include content encryption and/or content compression.
Optimizations of the Invention
The present embodiment of the invention is creating query-able relationships across several database files. This manages the volume of information contained in the layout files. An embodiment of the storage architecture reduces and/or eliminate content duplication across the overall database structure.
Automatic trace control (scancell macro, PI/PO, and blackbox) is controlled in-part by the method of caching macro names that have been used as a ScanCell. The combination of ScanCell name matching and DEF component name to MACRO relationship mapping enables a third, much smaller database to be created (at compile time) which only contains scancell MACRO names. This creates a far faster lookup process than sifting through potentially hundreds of thousands of scancell names.
Since the instance names of nets, ports, and components are manipulated to use normalized hierarchy separators at compile time, this enables faster hierarchy dissection during trace operations.
The method of storing the full DEF or LEF description of major statement entries intact in particular database structures optimizes the assembly process of mini-DEF and mini-LEF for SPLAT representation.
The method of storing the component names and their ports in a query-able form comprises the steps of storing the full DEF or LEF description of major statement entries intact, manipulating the instance names of nets, ports, and components to use normalized hierarchy separators at compile time, caching macro names as a scancell, matching scancell names, and mapping DEF component names to MACRO names. This provides the present invention a platform across multiple name spaces resolving the differences between files created for unique applications and enabling simplified access from failing scan cells identified in the test name space to the wires and components attached to them in the physical or fabrication name space.
The Trace Engine is an optimized system for gathering circuit structures from a device design focused on electrical faults. The Trace Engine extracts design and layout information from STIL, LEF, and DEF files which are de jure and de facto industry standards.
The Methods (Processes) used to gather pertinent circuit structures are: Fan-In, Fan-Out, Net-Print, and Tree-Trace.
Fan-In Objective
When a scan test (stuck-at or ac) fails, the information reported at the tester is typically in pin and cycle-count. Once this pin and cycle-count data is converted into scan chain and bit position (scancell), the list of failing scancells can be fed into the Trace Engine using the Fan-In Method starting at the D-Input to the failing scancell(s). The Trace Engine will return only the circuit structures in layout format that lead into the failing scancell. The electrical fault likely exists within this small set of circuit structures.
Fan-Out Objective
When a scan chain is blocked, and if the test equipment can identify the scancell where the blockage occurs, the failing scancell for each blockage can be fed into the Trace Engine using the Fan-Out Method starting at the Scan-Output from the failing scancell(s). The Trace Engine will return only the circuit structures in layout format between this scancell and the next stage in the scan chain.
Net-Print Objective
When a diagnosis of failing scan data is performed and returns a fault candidate in the form of component and port, the component and port can be fed into the Trace Engine using the Net-Print Method starting at the component and port. The Trace Engine will return only the circuit structures in layout format of the net associated with the component and port.
Tree-Trace Objective
When an AC, scan-shift verification or delay-based scan test fails, and if the problem is identified to be related to the clock delivery, reset or the power system, then the Tree-Trace method can be used to localize some portion of the wide-fanin/fanout buffered tree-structures that connect to the clock, reset, or power-ground ports of the identified failing scancells. The Trace-Engine will return only the circuit structures involved with the widely-distributed net that are between the failing scancell and the drive scancells, or that are common to the multiple identified failing scancells.
Gathering of data for the purpose of yield analysis means that data will be collected in a production environment. Any significant decrease in production throughput will reduce the benefits of potential yield improvement. Thus, a critical component of the invention is the focus on optimization.
Buffer Level Limitation Optimization
By allowing a user-definable buffer level limit for the Trace Engine, tradeoffs between circuit detail and throughput can be made
On-Demand Execution Optimization
Once a specific trace operation is performed for a design, that trace is remembered in a history. Thus, subsequently encountered failures that make a repeated trace request will not pay the penalty of the repeating the trace. So, the size of the database can be limited to only the trace operations where failures have occurred while optimizing throughput to only perform each requested trace operation once.
Focus of Circuit Structure Optimization
While the Trace Engine output identifies a region of the die that contains many other circuit structures, such as other wire routes, vias, gates, etc., the Trace Engine is focused to only output the circuit structures that can be related to the fault.
All trace operations begin with a port name. Two ways to get the port name are.
All trace operations can keep a running list of statistics about the trace result. Examples include but are not limited to:
Fanin Process
The Fanin trace operation is a recursive process. Given an input port or inout port, a Fanin operation comprises the following steps:
FanOut Process
The FanOut trace operation also is a recursive process. Given an output port or inout port, a FanOut operation comprises the following steps:
NetPrint Process
This is a fundamental and essential operation. NetPrint looks up the port name and finds the name of the net attached to it. The net name is used as a lookup index in the database to retrieve the route XY coordinates, vias, and component port connection list.
Tree Trace Process (
A method comprising the following steps:
Trace Control—The trace engine has methods to control the trace operation:
Trace Control Points
The trace control point is what could be called a first level control mechanism. Basically, any primary I/O, any macro that has been used as a scan cell, and any blackbox modules. The primary I/O is learned from the PINS sections of the top level DEF file. The scan cells macros are learned from interrogating the ScanChain descriptions from an Automatic Test Pattern Generation (ATPG) tool or other sources.
Blackbox modules, in some cases, are inferred and in other cases require some form of user guidance either in the form of blackbox candidate specifications for LEF MACROS or by identifying either the blackbox instance name or the name of it's instantiated MACRO.
Trace Limit Governors
Level 2 controls set limits for the trace activity to stop. Examples of this are logic level depth, the number of ports accumulated during the trace operation, the number of nets, the number of components, and the list goes on.
Trace Control Filters
Level 3 controls specifications to modify the result of the trace in some way. An example of this would be to list in sorted order the nets by the number of vias contained in the net. Or, report the trace results only if metal 7 layer is used in the net connections.
Netlist Circuit Structure
When a circuit is designed, the netlist is typically developed in a modular fashion. Basic circuit modules are instantiated to create a bigger module. These modules are, in turn, used to create even bigger modules until the entire chip has defined. To identify a port on a basic module, one would describe the absolute hierarchy path to the port. The problem with electronic design automation (EDA) tools is that they do not all use the same hierarchy delimiter symbols. An test tool which operated on only the Verilog netlist may describe the port to a flip flop as “\top.core.reg1.A” and the layout tool for the same circuit may describe the same circuit location as “/top/core/reg1/A”. Still, a second test tool may describe the very same port location as “/core\.reg1.A”.
In order to correlate observation point failures of a test pattern to the physical space, the circuit representation that was used in the creation of the test pattern must be correlated to the component list description found in the DEF file(s). For this to occur, the hierarchical name representation must be normalized to use a common hierarchy delimiter symbol. Once the component names are in a common delimited format, then hierarchy matching methods can be applied to locate
Normalizing Hierarchy Symbols
To normalize the hierarchy symbols of the hierarchical reference to a component or a port name, a computer-implemented process picks apart the hierarchy name based on typical hierarchy delimiter symbol combinations and then re-assemble the hierarchy name with a default hierarchy delimiter symbol. Examples of a default hierarchy delimiter would be a period ‘.’ or a forward slash ‘/’.
Matching Deviant Hierarchy Names
As mentioned above, hierarchy names to a port or component may vary from one EDA tool to another. In order to compare circuit attributes from one EDA tool to the circuit attributes given by another tool, a hierarchy match process must take place. As an example, assume that a test tool has referenced a scancell as “/Level0/Level1/Level2/d1”. The “d1” is actually a port name. Now, assume that the component name in a DEF file for that same circuit is represented like this “/Level1/Level2”.
The first observation of the example above is that a direct lookup of the scan cell name in the DEF database will yield no positive match. It is for this reason, the following computer-implemented method was developed.
To find a name match, perform the following steps:
The present invention is a method for determining an area on a wafer containing a fault. A test pattern failure, observed on automatic test equipment, creates a data log of failing output from the pattern. A series of transformation steps converts each failure to its corresponding test scan cell and thence to an instance of a physical component on a die on a wafer. Electrically, a number of wires and vias spanning multiple metal layers and components are implicated by the failing scan cell. The present invention computes a bounding box containing these failing circuit structures suitable for analysis by yield management systems.
As each scan cell may be tested tens of thousands of times, and fail a substantial number of them this process effects significant data reduction by computing one bounding box for each failing scan cell rather than each test failure.
As manufacturing processes increase potential productivity, new processes are needed to address sources of faults which threaten to reduce yield. While visibility of particulate defects is near the limit of optical inspection tools, design-introduced electrical faults which are yield limiting at these tighter geometries begin to be significant. The present invention efficiently augments manufacturing test procedures to enable the economic analysis of electrical faults and organizes geometric information of components in a database appropriate to production test volumes and speeds. A substantial economic benefit may result from identifying causes for low yield in semiconductor manufacturing early in the product life cycle of a new process to reduce costs and improve profit.
The scope of the invention should be determined by the appended claims and their legal equivalents, rather than the examples given to provide illustrations of presently preferred embodiments.
The present application claims the benefit of priority under 35 USC .sctn. 119(e) from U.S. provisional patent application 60/829,317 filing date Oct. 13, 2006 first named inventor Dokken, titled: “A process for improving design limited quality by filtering production test data through a yield monitoring system to localize electrical faults on semiconductor wafers.”
| Number | Date | Country | |
|---|---|---|---|
| 60829317 | Oct 2006 | US |
