Patent Description:
The design and fabrication of electronic systems, such as very large scale (VLSI) integrated circuits (ICs), is a very complex and thorough process. The design size and complexity of today's chips/circuits make it nearly impossible to design a chip without any mistakes or manufacture a chip without any defects. Therefore, IC designers implement various testing tools and methodologies to help ensure that a logical design of a chip conforms to its functional specification and that manufacturing defects are identifiable after the chip has been fabricated. Examples of these testing tools and methodologies include functional verification and Design for Testability (DFT) techniques. Functional verification tools can be used to confirm the functionality and logical behavior of the chip design by performing static verification, functional simulation, prototyping, and/or emulation operations on the logical design. DFT techniques may be utilized to add testability features, such as DFT logic, to the chip design. The DFT logic allows for tests, which were generated during a DFT stage of the design flow, to be executed on the fabricated chip to confirm whether its fabricated components are defect free.

One important goal of chip design/manufacturing testing is to exercise the tests across as much of the design/chip as possible. Therefore, designers utilize test coverage analysis tools to obtain test coverage metrics that indicate how well their tests have been exercised. Test coverage metrics typically quantify a likelihood of a defect/fault being screened for by a test based on the number of tested nodes in target modules. Ideally, a design/manufacturing test would provide <NUM>% test coverage, i.e., test all possible nodes in all modules to screen for all possible defects/faults. However, obtaining <NUM>% test coverage is generally not feasible or possible with today's IC designs because they have become increasingly complex with greater levels of circuit density. Therefore, achieving "as close to" <NUM>% test coverage has become the industry standard.

Although conventional test coverage analysis tools are able to determine whether a given test is achieving test coverage goals, they are generally not qualitative enough to meet defectivity coverage goals of critical safety-related application spaces such as automotive, medical and aerospace where the test quality requirements are very high, and the expectation is to deliver near zero defective parts per billion (DPPB). In particular, conventional tools generally only provide an abstract metric of test coverage based on overall node counts for tested modules at a high level of the chip design. These tools typically fail to take into account physical design features such as spatial uniformity that can make a node more critical or less critical from a testing perspective. Spatial uniformity is an important concept because areas having an increased density of undetected fault represent a coverage hole at a systemic level. Missing coverage is systemically more prone to causing a problem later as compared to uniformly distributed undetected faults, which do not represent coverage loss at a systemic level. For critical and other markets, test coverage holes/gaps can lead to unscreened defects resulting in customer returns or, in a worst case, critical safety issues that can cause fatalities if not caught in a timely manner.

<NPL> discloses an optimisation method to improve the testability of structural and parametric faults in analogue circuits. The approach consists of finding an optimum sub-set of tests which maximises the fault coverage with a minimum cost. The method is based on covering a discrete set of intervals by taking advantage of strategies. An application example to illustrate the proposal is disclosed studying at the fault coverage obtained using different test sets on a benchmark op-amp.

<NPL> discloses a technique to efficiently estimate the deterministic test coverage for large designs. The test coverage estimation with less than <NUM>% error can be achieved with more than <NUM> compared to the test generation runtime of the entire fault population.

Various optional features are recited in the dependent claims.

Conventional test coverage analysis tools generally provide an abstract test coverage metric that is based on the number of testable and untestable nodes. For example, consider a scenario where a design/chip comprises <NUM>,<NUM>,<NUM> total testable nodes which are connectors of logical cells. The total number of testable nodes can be defined as a total number of nodes in the design (or area of interest) minus a total number of untestable nodes in the design (or area of interest). Nodes can be untestable for various reasons such as, but not limited to, architectural limitations. In this example, <NUM>,<NUM> of the nodes have been tested, and <NUM>,<NUM> of the nodes have not been tested. A conventional test coverage analysis tool would typically utilize only these tested/untested node counts at a modular level to determine that, in this example, the test under analysis has <NUM>% test coverage. The resulting percentage, Pcov, is a representation of a probability of a test program screening a defect, where: <MAT>.

Stated differently, test coverage can be defined as likelihood that a defect/fault will be screened. As the analysis scope level changes in conventional tools, the test coverage percentage (Pcov) will always represent the probability within that scope level to screen the defect assuming spatial uniformity of the untested nodes. However, the spatial distribution of untested nodes is rarely uniform due to the nature of chip and test design. As the spatial distribution of untested nodes becomes less uniform, the likelihood that this traditional test coverage calculation properly reflects the probability to screen a particular defect decreases. Therefore, in the example above, although the <NUM>% test coverage may satisfy a coverage goal, the <NUM>,<NUM> untested nodes may be distributed in a non-spatially uniform manner such that one or more areas of the design have much less than <NUM>% test coverage. Conventional test coverage analysis tools typically fail to identify these test coverage holes because they usually perform their operations only from a logical perspective (as compared to a physical space perspective) and typically do not take the physical space/design of a chip and spatial uniformity of untested nodes into consideration when performing their analysis.

For example, consider the illustrations shown in <FIG>. In these examples, distributions of tested and untested nodes are shown for two different design (or manufacturing) tests across the same high-level generalized chip design <NUM>, 102a. The outer square <NUM>, 104a in each illustration represents the entire chip, and each inner square <NUM>, 106a represents either an entire module/submodule or a portion of a module/submodule in the chip design, where a module is a basic building design block that can comprise one or more submodules. Each open circle within each inner square <NUM>, 106a represents a tested node <NUM>, 108a within its module, and each closed circle represents an untested node <NUM>, 110a within its module. The untested nodes <NUM> in <FIG> are spatially uniform while the untested nodes 110a in <FIG> are non-spatially uniform. For simplicity, only one inner square <NUM>, 106a, one tested node <NUM>, 108a, and one untested node <NUM>, 110a in each design <NUM>, 102a are labeled. The larger cross-hatched circle <NUM>, 112a represents an area where a potential defect/fault can land.

In the examples shown in <FIG>, it is assumed that a first test was performed on the design resulting in the distribution of tested and untested nodes in <FIG>, while a second test was performed on the design resulting in the distribution of tested and untested nodes in <FIG>. Each of the tests was performed at the full-chip level resulting in <NUM> out of the <NUM> total nodes being tested and <NUM> out of the <NUM> total nodes being untested. Therefore, a conventional test coverage analysis tool would indicate that both tests obtain <NUM>% test coverage (<NUM> * (<NUM> - (<NUM>/<NUM>)) = <NUM>%) utilizing Equation <NUM>.

These test coverage results would lead a computer-implemented design tool or a designer into believing that both tests have an equivalent likelihood of screening a defect. However, this is not true because although <FIG> shows the potential defect <NUM> being screened for by the first test, <FIG> shows that the potential defect 112a was not screened for by the second test. Stated differently, the first test tested the nodes on which the potential defect <NUM> could land, but the second test did not test these nodes. This shows that when untested nodes <NUM> are spatially uniform (see <FIG>), the likelihood that defects/faults are screened for by the tests is higher than when the untested nodes 140a are non-spatially uniform (see <FIG>).

The non-spatially uniform untested nodes result in low coverage areas 114a, 116a of the chip design, as shown in <FIG>. This illustrates a concerning technical problem with conventional test analysis tools. In particular, even though conventional tools may indicate that test coverage goals, e.g., <NUM>%, are being satisfied, there may be one or more areas of the design/chip, e.g., areas 114a, 116a, with much less coverage than what is being indicated by the metrics provided by these tools. The failure of conventional test coverage analysis tools to account for these test coverage holes presents a technical problem for IC design, testing and manufacturing industries because these testing holes can lead to unscreened defects resulting in customer returns or, in the worst case, critical safety issues that can cause fatalities if not caught in a timely manner.

As noted above, conventional test coverage analysis tools tend to fail at identifying these test coverage holes because they generally perform their operations only from a logical perspective and typically do not take the physical space/design of a chip and spatial uniformity of untested nodes into consideration when performing their analysis. Spatial uniformity is an important concept that should be considered when performing test coverage analysis. For example, manufacturing defectivity is calculated for fabricated chips by the foundries and is represented by a value known as chip defect density (Do). Chip defect density is universally defined at the wafer-level as the number of defects per die per unit area. A single wafer comprises multiple dies, and within each die, there is an assumption of random defectivity. This means that, at the die-level scope, the defectivity is randomly distributed at a high-level and, therefore, spatially uniform.

However, the untested nodes are rarely spatially uniform due to chip and testing designs. Without accounting for the spatial uniformity/non-uniformity of untested nodes, there may be test coverage holes in areas of the design/chip having non-spatially uniform untested nodes, as illustrated in <FIG>. Test coverage analysis tools would need to be modified with many dependencies to determine that a design (or a manufacturing) test results in low coverage areas, e.g., areas 114a and 116a in <FIG>, when untested nodes are non-spatially uniform. Some of those dependencies include, but are not limited to, re-configuration of the analysis environment, manual intervention alongside deep knowledge, and understanding of functional behavior of logic areas in question, etc. For example, a conventional test coverage analysis tool would need to check test coverage at multiple levels of hierarchy down until the low coverage value is spotted, and all of the untested nodes must be contained within the same module at some X level of hierarchy.

Conventional analysis tools require the untested nodes to be contained within the same module because they are unaware of the module boundaries in a physical space, and, in a physical design module, boundaries are not necessarily always adjacent. The boundaries can be intertwined, which means adjacent nodes can be part of completely different modules. Given the millions/billions of nodes that a typical IC design includes, modifying conventional test coverage analysis tools to include these dependencies is not currently a feasible option given an amount of time, computing resources and financial resources it would take to determine coverage at all of these dependencies. In addition, if the untested nodes are not contained within the same module at some X level of hierarchy, existing test coverage analysis tools typically cannot determine that defects will not be screened because coverage is typically determined on an intra-module basis and not an inter-module basis.

<FIG> illustrate the inefficiency and other disadvantages of conventional test coverage analysis tools when modified with multiple dependencies to identify low coverage areas within the same module. In particular, <FIG> shows the test coverage resulting from the second test discussed above with respect to <FIG> and is directed to conventional test coverage analysis being performed on a first level down from the full chip. For example, the analysis is being performed within an entire module, Module_A <NUM>. In this example, Module_A <NUM> is represented by an outlined rectangle. Module_A <NUM> includes a total of ninety-six (<NUM>) nodes, where both tests resulted in eighty-eight (<NUM>) tested nodes <NUM> and eight (<NUM>) untested nodes <NUM>. Accordingly, a conventional test coverage analysis tool determines that the test coverage for the entirety of Module_A is <NUM>% based on Equation <NUM>. Similar to the full-chip level analysis discussed above with respect to <FIG>, the conventional test coverage analysis for the top-level of Module_A fails to provide any indication that the second test resulted in low-test coverage for one or more areas <NUM>, <NUM> in <FIG>. In at least some embodiments, low-test coverage refers to a percentage of node test coverage for a given area that is less than or equal to a specified threshold percentage. However, in other embodiments, low-test coverage refers to a number of untested nodes within a given area that is greater than or equal to a specified threshold number of untested nodes.

<FIG> shows the conventional test coverage analysis being performed on a second level down from the full chip. For example, the analysis is being performed on a submodule, Module_A1 <NUM>, of Module_A <NUM>. In this example, Module_A1 is represented by an outlined square within Module_A <NUM>. Module_A1 <NUM> includes a total of forty-eight (<NUM>) nodes, where the second test resulted in forty (<NUM>) tested nodes <NUM> and eight (<NUM>) untested nodes <NUM>. Therefore, a conventional test coverage analysis would determine that the second test provided <NUM>% test coverage at this level.

<FIG> shows the conventional test coverage analysis is performed on a third level down from the full chip. For example, the analysis is being performed on a submodule, Module_A2 <NUM>, of submodule Module_A1 <NUM>. In this example, Module_A2 <NUM> is represented by an outlined square within Module_A1 <NUM>. Module_A2 <NUM> includes a total of twelve (<NUM>) nodes, where the second test resulted in four (<NUM>) tested nodes <NUM> and eight (<NUM>) untested nodes <NUM>. Therefore, a conventional test coverage analysis would determine that the second test provided <NUM>% test coverage at this level.

<FIG> shows the conventional test coverage analysis being performed on a fourth level down from the full chip. For example, the analysis is being performed on a submodule, Module_A3 <NUM>, of Module_A2 <NUM>. In these examples, Module_A3 <NUM> is represented by an outlined square within Module_A2 <NUM>. Module_A3 <NUM> includes a total of four (<NUM>) nodes, where the test resulted in zero (<NUM>) tested nodes and four (<NUM>) untested nodes <NUM>. Therefore, a conventional test coverage analysis would determine that the second test (see <FIG>) provided <NUM>% test coverage at this level.

As shown, it took the conventional test coverage analysis tool approximately two to four levels of analysis in this simple example to determine that a low coverage area resides in a sub-level/hierarchy some X levels deep. When the simple example is scaled to a real-life design/chip, it would be nearly impossible to utilize conventional test coverage analysis tools for identifying low coverage areas within lower levels of a module given the complexities of a design/chip, the amount of dependencies that would need to be added to the tool, and the amount of time and resources the tool would require to identify low-test coverage areas. This inherent gap in conventional methods of coverage calculation requires multiple levels of manual analyses because conventional test coverage analysis tools showed that, although there is clearly a low coverage area, the abstract boundaries of modules caused conventional methods to only find the low coverage area after multiple steps in the analysis process.

In addition, even if conventional test coverage analysis tools are modified with multiple dependencies, they would not be able to determine low coverage areas across multiple modules because existing tools typically determine coverage on an intra-module basis and not an inter-module basis. Stated differently, conventional test coverage analysis tools do not analyze across module boundaries taking the physical domain into account. Consider <FIG>, which illustrates another example of tested and untested node distributions resulting from a design (or a manufacturing) test across a high-level generalized chip design <NUM>. Similar to <FIG>, the outer square <NUM> represents the entire chip, and each inner rectangle/square <NUM> to <NUM> defined by a dash/dotted line represents a module or sub-module within the chip design <NUM>. In this example, there are three modules (Module_A <NUM>, Module B <NUM>, and Module_C <NUM>) and five submodules (Module_A_1, <NUM>, Module_B_1 <NUM>, Module_C_1 <NUM>, Module_C_2 <NUM>, and Module_C_3 <NUM>).

<FIG> further shows three low coverage areas <NUM>, <NUM> and <NUM> defined by the solid line boxes. Each of these low coverages <NUM>, <NUM> and <NUM> spans across multiple modules/submodules. For example, the first low coverage area <NUM> spans across Module_A <NUM>, Module_A_1 <NUM>, Module_B_1 <NUM>, Module_C_1 <NUM>, and Module_C_2 <NUM>. The second low coverage area <NUM> spans across Module B <NUM>, Module_B_1 <NUM>, Module C <NUM>, and Module_C_3 <NUM>. The third low coverage area <NUM> spans across Module_A <NUM>, Module_A_1 <NUM>, Module C <NUM>, Module_C_1 <NUM>, and Module_C_2 <NUM>. Conventional test coverage analysis tools would typically fail to identify the low-test coverage areas <NUM>, <NUM> and <NUM> shown in <FIG> even if they are modified with the multiple dependencies discussed above because they generally perform their analysis only at a per-module level as compared to performing the analysis across modules/submodules.

For example, conventional tools are able to determine that the test coverage for Module_A_1 <NUM> is <NUM>%; the test coverage for Module_B_1 <NUM> is <NUM>%; the test coverage for Module_C_1 <NUM> is <NUM>%; the test coverage for Module_C_2 <NUM> is <NUM>%; and the test coverage for submodule Module_C_3 <NUM> is <NUM>% based on Equation <NUM>. However, these test coverage percentages do not take into account or identify the low-test-coverage areas <NUM>, <NUM> and <NUM> because they span across multiple modules/submodules. This illustrates a technical problem associated with conventional test coverage analysis tools because defects/faults are not being screened for in the low-test-coverage areas <NUM>, <NUM> and <NUM>, which can lead to customer returns, critical safety, and/or the like.

Embodiments of the present invention overcome the technical problems discussed above with respect to conventional test coverage analysis tools by utilizing the physical space data of the design/chip, which provides physical locations of chip components, e.g., modules and nodes, in conjunction with node testability data, which identifies nodes and their testability state, e.g., testable or untestable, to accurately and efficiently identify low-test coverage areas without requiring analysis at multiple levels of a module. In addition, embodiments of the present invention are able to quickly determine low coverage areas within the design/chip even when untested nodes are distributed across multiple modules and/or submodules. This allows for test coverage to be increased across the design/chip, which results in a decrease in unscreened defects.

For example, as will be discussed in greater detail below, a low-test coverage identifier receives physical space data and node testability data as inputs. Physical space data, in one embodiment, includes information such as coordinates representing the physical location of nodes on the chip being designed. Node testability data, in one embodiment, comprises information identifying each node in the current chip design and whether the node is tested or untested. The low-test coverage identifier utilizes these inputs to generate a map of the chip design, indicating the physical location of each untested node.

The low-test coverage identifier analyzes the mapped locations of the untested nodes to identify clusters of untested nodes throughout the design. The clusters may include untested nodes within a single module, a single submodule, multiple modules, and/or multiple submodules. The low-test coverage identifier determines one or more of these clusters to be low-test coverage areas for the design. For example, in the example shown in <FIG>, the low-test coverage identifier <NUM> is able to identify areas <NUM>, <NUM> and <NUM> as being low-test coverage areas (e.g., <NUM>%, <NUM>% and <NUM>% test coverage, respectively) based on clustering of untested nodes. These areas are identified as low-test coverage areas even though the untested nodes span across multiple modules/submodules. The low-test coverage identifier utilizes this low-test coverage information to generate test coverage data that identifies areas of an integrated circuit design comprising test coverage gaps that are herein referred to as "optimized test coverage data". The optimized test coverage data, in one embodiment, includes data such as, but not limited to, physical location data associated with low-test coverage areas, identifiers of the untested nodes within a low-test coverage area, module/submodule/instance identifiers associated with the untested nodes, physical location data of the untested nodes within a low-test coverage area and (optionally) their associated module/submodule/instance, and test coverage percentage for the low coverage areas.

The optimized test coverage data is transmitted to, for example, designers and/or design tools such as functional verification tools, DFT tools, or other tools that are able to utilize the low-test coverage data of one or more embodiments to improve the test coverage for the identified low-test coverage areas. The optimized test coverage data may be utilized by the design tools and/or designers to revise and improve the design by updating the test(s) associated with the low-test coverage areas. Once the test has been revised, new or updated node testability data can be provided to the low-test coverage identifier based on the revised test. The test is herein referred to as an "optimized test" because the revised test increases test coverage in one or more areas identified as having test coverage gaps. If the updating/optimization of the test results in the physical space data of the design/chip are changed, then updated physical space data can also be provided to the low-test coverage identifier. The low-test coverage identifier then performs the operations discussed above to identify any low-test coverage areas of the design and generate new optimized test coverage data for the revised/updated test. This process can be performed as many times as needed until the low-test coverage identifier does not detect any more low-test coverage areas.

Once test coverage for the design/chip is determined to be within acceptable limits based on data provided by the test-coverage gap identifier and the remaining design parameters satisfy their goals/thresholds, the revised/updated design can be utilized to fabricate the chip. The revised design is herein referred to as an "optimized design" because the revised design includes increased node test coverage as compared to the previous design. Chips fabricated using designs revised/updated by one or more embodiments of the present invention have reduced or eliminated customer returns and critical safety issues when compared to chips fabricated using designs analyzed by conventional test coverage analysis tools because the revised/updated designs of one or more embodiments have reduced or eliminated low-test coverage areas that tend to cause returns or critical safety issues.

<FIG> illustrates one example of an operating environment <NUM> according to one or more embodiments of the present invention. In one embodiment, the operating environment <NUM> comprises an integrated circuit design system <NUM> and a fabrication system <NUM>. In some embodiments, a network <NUM> communicatively couple one or more components of these systems <NUM>, <NUM> to each other and/or to other systems not shown. The network <NUM> may be implemented utilizing wired and/or wireless networking mechanisms. For example, the network <NUM> may comprise wireless communication networks, non-cellular networks such as Wi-Fi networks, public networks such as the Internet and private networks. The wireless communication networks support any wireless communication standard and include one or more networks based on such standards.

In one example, the integrated circuit design system <NUM> comprises one or more components for designing and testing digital and/or analog integrated circuits. For example, in one embodiment, the system <NUM> comprises one or more: system specification tool <NUM>, architectural design tool <NUM>, functional/logic design tool <NUM>, physical design tool <NUM>, testing tool <NUM>, test coverage analysis tool <NUM>, and low-test coverage identifier <NUM>. Each of these components <NUM> to <NUM> may be implemented in one or more information processing systems <NUM> to <NUM>, either as a hardware or software component.

Although one or more of these components <NUM> to <NUM> are shown as being implemented within separate information processing systems <NUM> to <NUM>, two or more of these components may be implemented within the same information processing system. In addition, one or more of these components may be distributed across multiple information processing systems <NUM> to <NUM> as well. Also, multiple components may be combined into a single component, or combined components may be separated into separate and distinct components. For example, a test coverage analysis tool <NUM> may be part of a testing tool <NUM> as compared to being a separate component. In another example, a low-test coverage identifier <NUM> may be separate from a test coverage analysis tool <NUM> and/or any other tool. In some embodiments, the processes discussed below with respect to two or more of the components <NUM> to <NUM> may be performed in parallel and may also be performed in an iterative loop. Also, it should be understood that embodiments of the present invention are not limited to the configuration of the integrated circuit design system <NUM> shown in <FIG>. For example, embodiments are applicable to any integrated circuit design system that generates/provides physical space data, e.g., Design Exchange Format (DEF) data, and node testability data. In addition, those of ordinary skill in the art have a technical understanding of typical designs flows and components found in integrated circuit design systems. Therefore, only a brief description will be provided for some of the components shown in the integrated circuit design system <NUM> of <FIG>.

In one embodiment, the system specification tool <NUM> generates a system specification for a chip that defines functional specifications/requirements of the chip. The architectural design tool <NUM>, in one embodiment, generates an architectural specification for the chip based on the system specification. The architectural specification specifies, for example, main functional blocks and their relationships, the interface and signals between the functional blocks, timing, performance, area, power constraints, etc. The functional/logic design tool <NUM> transforms the architectural specification into a logical design. The logical design models the circuit at, for example, a register transfer level (RTL), which is usually coded in a Hardware Description Language (HDL). The design includes, for example, details of intellectual property (IP) block instantiations, design connectivity, IC input and output pins, clock and reset strategy, etc..

One or more testing tool <NUM>, such as a design verification tool, can functionally verify the logical design. It should be understood that although <FIG> shows the testing tool <NUM> being separate from the functional/logic design tool <NUM>, the testing tool responsible for functionally verifying the logical design may also be part of the functional/logic design tool <NUM>. The testing tool <NUM>, for example, can emulate an electronic system corresponding to an integrated circuit according to the logical design, and/or simulate the functionality of the logical design in response to various test stimuli.

One goal of functional verification testing is to determine whether the logical design operated differently than expected in response to live data or a test stimulus. When the output from the emulated or simulated logical design is different than expected, a fault/bug is determined to have occurred. The testing tool <NUM> is able to record information associated with identified faults and transmit this data back to the functional/logic design tool <NUM> and/or a designer so that the logical design can be updated/revised to correct any issues. In one embodiment, the testing tool <NUM> and/or the functional/logic design tool <NUM> also generates node testability data <NUM> resulting from the functional verification process. The node testability data <NUM> identifies, for example, each of the nodes in the design, the modules comprising each of the nodes, the value each node can exhibit, and the testability of each node, e.g., tested or untested.

Once the logical design has been updated/revised, functional verification operations can be performed once again. This process repeats not only when the logical design is updated/revised based on fault/bug correction but also for any process in the design flow that can provide netlist/constraints for functional pattern evaluation by the testing tool <NUM>. Examples of these processes include gate-level synthesized design, scan-inserted design, physically placed design (with optimized floorplan), initial clock tree integration, routed design, pre-final design, final taped-out design, and production test program.

The physical design tool(s) <NUM>, in one embodiment, map the RTL generated during the functional/logic design process into actual geometric representations of the various electronic devices that will be part of the chip by the physical design tool(s) <NUM>. One example of a physical design flow associated with the physical design tool(s) <NUM> includes logic synthesis, design-for-test (DFT), floorplanning, physical placement, clock insertion, routing, pre-final design (e.g., design for manufacturability), and final tape-out design.

During logic synthesis, the RTL code is translated into a gate-level netlist. For example, the RTL can be translated into a Boolean equation(s) that is technology independent. The equation can then be optimized, and any redundant logic may be removed. The optimized Boolean equation can then be mapped to technology-dependent gates. Once the gate-level netlist has been generated based on the logic synthesis process, a DFT process may be performed. The DFT process adds testability features, such as DFT logic, to the chip design. The DFT logic allows for tests, which were generated during the DFT stage of the design flow, to be executed on the fabricated chip to confirm whether its fabricated components are defect free or not with the goal of screening out parts from being shipped due to a critical defect found by the test.

DFT can be implemented by, for example, scan path insertion, memory built-in-Self-Test, and automatic test pattern generation (ATPG). ATPG typically generate test sets, which are a collection of test patterns, for testing various types of fault models such as stuck-at, transition, path delay faults, and bridging faults. The ATPG processes, in one embodiment, may be performed by at least one physical design tool <NUM> and/or at least one testing tool <NUM>. In some embodiments, at least one testing tool <NUM> is part of one or more of the physical design tool <NUM>.

In one embodiment, at least one of the physical design tool <NUM> and/or testing tool <NUM> also generates node testability data <NUM> resulting from the DFT processes. The node testability data <NUM> generated based on the DFT processes, in one embodiment, may be similar to the functional verification node testability data <NUM> discussed above. For example, the DFT node testability data <NUM> identifies, for example, each of the nodes in the design, the modules comprising each of the nodes, the value each node can exhibit, and the testability of each node, e.g., tested or untested. The embodiments of the present invention are not limited node testability data generated for functional verification and DFT, and any node testability data generated by any test during integrated circuit design may be utilized by various embodiments.

<FIG> shows one example of node testability data <NUM> according to one embodiment of the present invention. In this example, the node testability data <NUM> comprises the following types of data: node identifier data <NUM>, node value data <NUM>, testability data <NUM>, module identifier data <NUM>, and instance identifier data <NUM>. However, it should be understood that other types of data are applicable as well, and one or more of the illustrated data types can be removed, and/or one or more different data types can be added. Here, a module refers to a basic building design block that can comprise one or more submodules. A module comprises one or more instances, each representing a utilization of given components such as logical very large-scale integration (VLSI) gates, e.g., AND, NAND, OR, NOR, etc. These logical gates can be comprised of transistors, resistors, capacitors, etc., within the module/submodule. Each instance may comprise one or more cells that each includes one or more gates. Nodes are the connectors on each logical cell/gate, and multiple instances then have an opportunity to be connected together via their respective nodes.

The node identifier data <NUM> comprises a unique identifier/name associated with a given node. The node value data <NUM> comprises the value that the associated node can exhibit, such as "<NUM>" or "<NUM>". The testability data <NUM> identifies whether the associated node is testable or untestable for the associated value, e.g., "<NUM>" or "<NUM>". The module identifier data <NUM> comprises a unique identifier/name associated with the module comprising the node. The instance identifier data <NUM> comprises a unique identifier/name of the instance within the module that comprises the node.

For example, consider a first set of entries <NUM>, <NUM> in the node testability data <NUM>. These entries show that a node having the node identifier "Node_1" is testable for both its values "<NUM>" and " <NUM>". These entries also show that a module having the module identifier "Module_A" comprises an instance having the instance identifier "Inst_A", which comprises "Node_1". In another example, a second set of entries <NUM>, <NUM> shows that a node having the node identifier "Node_10000" is untestable for both its values "<NUM>" and "<NUM>". These entries <NUM>, <NUM> also show that a module having the module identifier "Module_BC_1_2_X" comprises an instance having the instance identifier "Inst_M" that comprises "Node_10000". In this example, Module_BC is the top-level module; BC_1 is a first level submodule within Module_BC; BC_1_2 is a second level submodule within submodule BC_1; and BC_1_2_X is a third level submodule within submodule BC_1_2. In some embodiments, two or more of the node identifier data <NUM>, module identifier data <NUM>, and the instance identifier data <NUM> may be combined.

Referring back to <FIG>, after (or in parallel with) the DFT process, the physical layout of the chip may begin. Physical layout is the transition from the logical view to the physical view of the chip. Physical layout includes processes such as floorplanning, partitioning, physical placement, clock insertion, routing, and design for manufacturability. Floorplanning includes assigning/placing design blocks to physical locations in the die area, pin placement, power optimization, etc. Partitioning includes dividing the die area into functional blocks to help with placement and routing. Physical placement includes assigning gates in the netlist to nonoverlapping locations on the die area. Clock insertion includes introducing clock signal wiring into the design. Routing includes adding wires to the design that connect the gates in the netlist via their respective nodes. Design for manufacturability processes increase the ease of manufacturing the chip while complying with design rules set by the foundry.

The physical layout processes generates physical space/design data <NUM> that represents the physical layout of the chip, such as the netlist and circuit layout. For example, the physical space data <NUM>, in one embodiment, may include data such as the identifiers of nodes within the design, the physical location of each node on the die/chip, the module name associated with each node, the physical location of each module, etc. One example of physical space data <NUM> is a Design Exchange Format (DEF) file.

<FIG> shows one example of physical space data <NUM> according to one embodiment of the present invention. In this example, the physical space data <NUM> comprises the following types of data: die area data <NUM>, node identifier data <NUM>, module identifier data <NUM>, instance identifier data <NUM>, module location data <NUM>, instance location data <NUM> and node location data <NUM>. It should be understood that other types of data are applicable as well, and one or more of the illustrated data types can be removed and/or one or more different data types can be added. For example, additional data types such as "cell name", which describes the type of logical gate the instance is, or "rotation", which indicates how the instance is orientated, may also be included as part of the physical space data <NUM>. In another example, module location data <NUM> is not required and only one of instance location data <NUM> and node location data <NUM> may be included within the physical space data <NUM>.

The die area data <NUM> indicates the bounding box of the die such that locations of modules, instances, nodes, etc., can be determined within this area. The node identifier data <NUM> comprises a unique identifier/name associated with a given node. The module identifier data <NUM> comprises a unique identifier/name associated with the module comprising the node. The instance identifier data <NUM> comprises a unique identifier/name of the instance within the module that comprises the node. The module location data <NUM> comprises coordinates or other location indicating where on the die/chip the corresponding module is physically located. The instance location data <NUM> comprises coordinates or other location data indicating where on the die, the corresponding instance is physically located. The node location data <NUM> comprises coordinates or other location data indicating where on the die the corresponding node is physically located. For example, consider a first entry <NUM> in the physical space data <NUM>. This entry <NUM> shows that Module_A is located from position A to position G along the X-axis of the die and position A to position Z along the Y-axis of the die. The instance Inst_A, in this example, is located from position A to position B along the X-axis of the die and position A to position B along the Y-axis of the die. The node Node_1, in this example, is located at position A on the X-axis of the die and position B on the Y-axis of the die. It should be understood that other conventions for representing locations of modules, nodes, instances, etc., are applicable as well. Also, only one entry <NUM> is labeled in <FIG> for simplicity. Also, in some situations, locations of each node relative to each other within an instance may be trivial in difference. Therefore, in some embodiments, the location data of the instance may be used to establish a coordinate of the multiple nodes related to that instance.

It should be understood that, at least in some embodiments, other inputs in addition to the node testability data <NUM>, <NUM> and physical space design data <NUM> can be utilized by the low-test coverage identifier <NUM> to perform one or more operations described herein. One example of such additional input includes historical customer returned part data that shows a particular node or set of nodes having a high likelihood of failure. This data can be added as input to the low-test coverage identifier <NUM> regardless of testability of the node to highlight "problem areas". The highlighted problem areas can be combined with other untested areas to further highlight a problem. In addition, nodes may be untestable for various reasons such as architectural limitations, and ATPG not being able to find a method to test in time. The low-test coverage identifier <NUM> can filter the node testability data <NUM>, <NUM> based on such data to only consider testability data of interest. Also, the low-test coverage identifier <NUM> can also filter the node testability data <NUM>, <NUM> and physical space design data <NUM> based on module name. For a certain module function, such as test-specific logic, may not be desired a part of the test coverage analysis because, for example, the testability and value of testability on that module is low. Therefore, the low-test coverage identifier <NUM> can filter out input data associated with this module so that subsequently generated optimized test coverage data <NUM> is not misconstrued by such data.

Referring back to <FIG>, the integrated circuit design system <NUM> further comprises one or more test coverage analysis tools <NUM> that perform test coverage analysis operations during the functional/logic design and physical design processes. The test coverage analysis tools <NUM>, in one embodiment, utilize the node testability data <NUM>, <NUM> to determine how well the various tests performed or generated during the logical and physical design processes exercise the design/chip. For example, during functional verification testing, a test coverage analysis tool <NUM> utilizes the corresponding node testability data <NUM> to determine how well the test stimulus, e.g., functional patterns, exercised the functionality of the logical design. In another example, during DFT operations, a test coverage analysis tool <NUM> utilizes the corresponding node testability data <NUM> to determine how well test stimulus, e.g., test patterns generated by ATPG, exercises the design/chip to identify various types of faults.

The test coverage analysis tool <NUM> is able to generate test coverage data for a given test by analyzing the corresponding node testability data <NUM>, <NUM>. This test coverage data, in at least some embodiments, is considered unoptimized because it may only take into consideration node testability data <NUM>, <NUM>, and may comprise of unidentified low-test coverage areas. For example, the test coverage analysis tool <NUM> can generate unoptimized test coverage data determining test coverage based on Equation <NUM> above for a given number of levels within the design.

However, in addition to the test coverage analysis tool <NUM>, the integrated circuit design system <NUM> also comprises one or more low-test coverage identifiers <NUM>. <FIG> shows a more detailed view of the low-test coverage identifier <NUM> according to one embodiment of the present invention. In this embodiment, an information processing system <NUM> is shown as comprising the low-test coverage identifier <NUM>. However, in other embodiments, the low-test coverage identifier <NUM> may be a standalone system. In addition, although <FIG> shows the low-test coverage identifier <NUM> as being separate component within the information processing system <NUM>, it may be a component of the functional/logic design tool <NUM>, the physical design tool <NUM>, the testing tool <NUM>, and/or the test coverage analysis tool <NUM>. In one embodiment, the low-test coverage identifier <NUM> comprises a physical mapping data generator <NUM>, a map analyzer <NUM>, an untested node cluster prioritizer <NUM>, intermediate test coverage data <NUM>, mapping data <NUM>, one or more untested node maps <NUM>, untested node clustering data <NUM>, cluster prioritization data <NUM>, and logical hierarchy/module prioritization data <NUM>. It should be understood that the terms "hierarchy" and "module" are used interchangeably throughout this discussion. Each of these components is discussed in greater detail below. It should be understood that, in other embodiments, two or more of these components may be combined into a single component.

As will be discussed in greater detail below, the low-test coverage identifier <NUM> generates optimized test coverage data <NUM> by utilizing the node testability data <NUM>, <NUM> in combination with the physical space data <NUM> generated during the physical design processes to determine low-test coverage areas within the design/chip. In some embodiments, the unoptimized test coverage data may be combined with low-test coverage data generated by the low-test coverage identifier <NUM> to form the optimized test coverage data <NUM>. In other embodiments, the test coverage analysis tool <NUM> is not required to generate separate test coverage data. For example, the low-test coverage identifier <NUM> is able to determine overall test coverage data at various levels of the design based on corresponding node testability data <NUM>, <NUM> data and then optimize this test coverage data by further determining low-test coverage areas based on a combination of the testability data <NUM>, <NUM> and physical space data <NUM>.

The optimized test coverage data <NUM>, in one embodiment, may be transmitted to one or more of corresponding integrated circuit design tools, such as the functional/logic design tools <NUM> and/or physical design tools <NUM>; may be stored in one or more local and/or remote storage devices; may be transmitted to one or more local and/or remote information processing systems via the network <NUM>; and/or a combination thereof. The optimized test coverage data <NUM> enables the functional/logic design tools <NUM> and/or physical design tools <NUM> and/or a designer to modify, for example, the logical and/or physical design so that the low-test coverage areas of the design identified by the optimized test coverage data <NUM> are addressed.

For example, the data utilized by functional pattern generators for functional verification testing and/or the data utilized during the DFT process for automatic test pattern generation can be updated/revised based on the optimized test coverage data <NUM> to increase test coverage in the identified low-test coverage areas. The above processes can be iteratively performed until the low-test coverage identifier <NUM> no longer identifies low-test coverage areas within the design. In one embodiment, this determination is made based on analyzed areas having test coverage satisfying a given test coverage threshold.

The completion of the above design processes and test coverage analysis operations result in a pre-final design for the chip. The above processes may be repeated numerous times and may be performed in parallel even after a taped-out design is obtained by adding additional stimuli that exercise more nodes than previously may have been done. After the logical and physical designs/tests of the chip have been revised based on the optimized test coverage data <NUM> and all design requirements have been satisfied, a taped-out design is obtained and sent to a fabrication system, e.g., a foundry, such as the fabrication system <NUM> illustrated in <FIG>. The semiconductor fabrication plant <NUM> is responsible for the manufacturing and packaging of semiconductor devices and utilizes the taped-out design to fabricate the design chip. In one embodiment, the semiconductor fabrication plant <NUM> comprises one or more information processing systems <NUM>; fabrication and packaging stations/components <NUM> to <NUM>; and semiconductor wafers <NUM>.

The information processing system <NUM> controls the one or more fabrication/packaging stations and their components. In one embodiment, the information processing system <NUM> may comprise at least one controller <NUM> that may be part of one or more processors or may be a component that is separate and distinct from the processor(s) of the information processing system <NUM>. The one or more fabrication and packaging stations <NUM> to <NUM> may include a cleaning station <NUM>, a deposition station <NUM>, a photolithography station <NUM>, an inspection station <NUM>, a dicing station <NUM> and/or a packaging station <NUM>.

In some embodiments, two or more of fabrication/packaging stations are separate from each other, where a semiconductor wafer <NUM> is moved from one station to a different station after processing. However, in other embodiments, two or more of these stations may be combined into a single station. In addition, one or more of the stations/components <NUM> to <NUM> may not be a physical station per se but may refer to a fabrication or packaging process(es) performed by components of the fabrication plant <NUM>. It should be understood that the semiconductor fabrication plant <NUM> is not limited to the configuration shown in <FIG>.

An integrated circuit, in one embodiment, may be fabricated according to the taped-out design that is based on the optimized test coverage data <NUM> as follows. First, a semiconductor wafer <NUM> is inspected for any defects. After the wafer <NUM> has been inspected, the wafer <NUM> is processed by the cleaning station <NUM>. The cleaning station <NUM> removes any contaminants from the surface of the wafer <NUM> using, for example, a wet chemical treatment. Then, the wafer <NUM> is processed by the deposition station <NUM>. The deposition station <NUM> deposits, grows, and/or transfers one or more layers of various materials are onto the wafer using processes such as chemical vapor deposition (CVD), physical vapor deposition (PVD) and atomic layer deposition (ALD).

After the desired materials have been deposited, the wafer <NUM> is processed by the photolithography and etching station <NUM>. For example, the wafer <NUM> may be cleaned and prepared by removing any unwanted moisture from the surface of the wafer <NUM>. An adhesion promoter may also be applied to the surface of the wafer <NUM>. A layer of photoresist material is then formed on the surface of wafer <NUM> (or the adhesion promoter layer is formed). A process such as, but not limited to, spin coating may be used to form the photoresist layer. Excess photoresist solvent may be removed by pre-baking the coated semiconductor wafer <NUM>. The photoresist coated wafer <NUM> is then exposed to one or more patterns of light. The patterns may be formed by projecting the light through a photomask (also referred to herein as "mask") created for the current layer based on the taped-out design obtained from the design processes discussed above. The taped-out design, in one embodiment, comprises all shapes/patterns that are intended to be printed on the wafer taped-out design for a given layer.

The bright parts of the image pattern cause chemical reactions, which result in one of the following situations depending on the type of resist material being used. Exposed positivetone resist material becomes more soluble so that it may be dissolved in a developer liquid, and the dark portions of the image remain insoluble. Exposed negative-tone resist material becomes less soluble so that it may not be dissolved in a developer liquid, and the dark portions of the image remain soluble.

A post-exposure bake (PEB) process may be performed that subjects the wafer <NUM> to heat for a given period of time after the exposure process. The PEB process performs and completes the exposure reaction. The PEB process may also reduce mechanical stress formed during the exposure process. The wafer <NUM> is then subjected to one or more develop solutions after the post-exposure bake. The develop solution(s) dissolves away the exposed portions of the photoresist. After development, the remaining photoresist forms a stenciled pattern across the wafer surface, which accurately matches the desired design pattern. An etching process is then performed that subjects the wafer <NUM> to wet or dry chemical agents to remove one or more layers of the wafer <NUM> not protected by the photoresist pattern. Any remaining photoresist material may then be removed after the etching process using, for example, chemical stripping, ashing, etc. It should be understood that semiconductor fabrication is not limited to the above-described process, and other fabrication processes are applicable as well.

The photolithographic process results in a layer of patterned features (also referred to herein as a "layer of patterns", "layer of features", "pattern of features", "patterns", and/or "pattern"). After the current layer of features has been patterned, the wafer <NUM> is processed by one or more defect inspection stations <NUM>. In one embodiment, the defect inspection station <NUM> inspects the current layer of patterned features for defects and corrects/manages any defects using one or more methods known to those of ordinary skill in the art. The above-described processes are then repeated until all of the desired layers of patterned features have been formed, and fabrication of the wafer <NUM> has been completed.

As discussed above, the low-test coverage identifier <NUM> optimizes test coverage performed by various testing tools <NUM> for an integrated circuit design by identifying areas within the design that are not adequately covered by the tests. Stated differently, the low-test coverage identifier <NUM> identifies areas of the design having low-test coverage or test coverage gaps. <FIG>, in flow chart form, illustrates one example implementation of an overall process performed by the low-test coverage identifier <NUM> for determining areas of an integrated circuit design comprising test coverage gaps in accordance with some embodiments. The low-test coverage identifier <NUM> at block <NUM> obtains input such as one or more sets of node testability data <NUM>, <NUM>, and physical space/design data <NUM> discussed above with respect to <FIG> and <FIG>.

The low-test coverage identifier <NUM> at block <NUM> generates overall or intermediate test coverage data based on at least the one or more sets of node testability data <NUM>, <NUM>. The intermediate test coverage data <NUM>, in one embodiment, can be stored locally, stored remotely, and/or transmitted to one or more information processing systems such as a server or user device. In at least some embodiments, generation of the intermediate test coverage data <NUM> is optional. <FIG> shows one example of overall/intermediate test coverage data <NUM> according to one embodiment of the present invention. In this example, the intermediate test coverage data <NUM> comprises data such as module identifier <NUM>, module name <NUM>, partition identifier <NUM>, detected node/fault count <NUM>, testable node/fault count <NUM>, test coverage measurement <NUM>, undetected node/fault count <NUM>, node/fault coverage measurement <NUM> and total node/fault count <NUM>.

The module identifier <NUM> comprises a unique identifier associated with a given module. This data, in one embodiment, is obtained from the node testability data <NUM>, <NUM>. The module name <NUM> comprises a name associated with the given module. The partition identifier <NUM> comprises a unique identifier associated with the partition comprising the given module. The detected node/fault count <NUM> comprises the number of testable faults/nodes detected within the given module by the test associated with the node testability data <NUM>, <NUM> used to generate the intermediate test coverage data <NUM>. The testable node/fault count <NUM> comprises the number of testable nodes within the given module. The number of testable nodes/faults can be determined by subtracting the number of untestable nodes/faults from the total number of nodes/faults. The test coverage measurement <NUM> indicates the amount of test coverage measured for the given module based on a ratio of the detected node/fault count <NUM> and the testable node/fault count <NUM>. The undetected node/fault count <NUM> comprises the number of nodes/faults within the given module that was not tested. The node/fault coverage measurement <NUM> indicates the amount of node/fault coverage measured for the given module based on a ratio of the detected node/fault count <NUM> and the total number of nodes/faults <NUM> in the given module. Consider a first entry <NUM> for the intermedia test coverage data <NUM>. In this example, the first entry <NUM> shows Module_A has a hierarchy/module identifier of "<NUM>", a partition identifier of "<NUM>", a total of <NUM>,<NUM> detected nodes, a total of <NUM>,<NUM> testable nodes, a total test coverage of <NUM>%, a total of <NUM>,<NUM> undetected nodes, a fault coverage of <NUM>%, and a total of <NUM>,<NUM> faults. For example, Module A comprises many nodes Node_1 to Node_X, as shown in <FIG> and <FIG>. The combination of all of these nodes summate together to produce the numbers shown in the DETECTED and UNDETECTED columns <NUM>, <NUM> of the test coverage data <NUM>, and are utilized to identify the percentage of coverage for the respective Module_A.

Referring back to <FIG>, the low-test coverage identifier <NUM> at block <NUM> further utilizes the one or more sets of node testability data <NUM>, <NUM> and physical space/design data <NUM> to generate mapping data <NUM> identifying the physical location data of each identified untested node on the die/chip and to also generate one or untested node maps <NUM>. In more detail, the physical mapping data generator <NUM> of the low-test coverage identifier <NUM> can analyze the node testability data <NUM>, <NUM> to determine any nodes that were untested such as Node_975000. In one example, the physical mapping data generator <NUM> determines that Node_975000 is untested based on the node testability data <NUM>. Therefore, the physical mapping data generator <NUM> analyzes the physical space data <NUM> to determine the physical location of Node_975000 on the die/chip. In this example, the physical mapping data generator <NUM> determines that Node_975000 is located at die/chip x-coordinate XBD and y-coordinate YBD. The physical mapping data generator <NUM>, in this example, can also determines Module_ABC_2 comprising Node_975000 is located at die/chip x-coordinates XBB to XBN and y-coordinates YBC to YBE, and further determines that the instance Inst_XY comprising Node_975000 is located at die/chip x-coordinates XBB to XBG and y-coordinates YBC to YBE.

The physical mapping data generator <NUM> stores the determined location data as mapping data <NUM> in local and/or remote storage and, in at least one embodiment, utilizes this data <NUM> to generate one or untested node maps <NUM>. The untested node maps <NUM>, in one embodiment, visually represent one or more untested nodes at the corresponding physical location on the die/chip. In some embodiments, the physical mapping data generator <NUM> can generate the untested node maps <NUM> directly from the node testability data <NUM>, <NUM> and the physical space/design data <NUM> with needing to first generate the mapping data <NUM>. The untested node map <NUM> can be stored locally, stored remotely, and/or transmitted to one or more information processing systems such as a server or user device.

<FIG> shows one example of an untested node map <NUM> generated by the physical map generator <NUM> based on node testability data <NUM>, <NUM> and physical space data <NUM>. In this example, the map <NUM> comprises an X-axis <NUM> and a Y-axis <NUM>, each including a coordinate scale such as micrometers, nanometers, etc. The map <NUM> further comprises an outline <NUM> defining the boundaries of the die/chip. Untested nodes, such as nodes <NUM> to <NUM>, are represented as, for example, solid circles/blobs at their physical location on the die/chip, while areas that are <NUM>% tested are unfilled/unshaded (e.g., white) areas. For example, if labeled node <NUM> represents Node_975000 from the node testability data <NUM>, <NUM>, then node <NUM> can be shown in the map <NUM> as a solid circle at x-coordinate XBD and y-coordinate YBD based.

It should be understood that in the example shown in <FIG>, the solid shaded areas are a result of the illustrated map viewing level and the distribution density of the untested nodes. If the map <NUM> is zoomed into, the separation (if any) between untested nodes becomes more evident. For example, a zoomed-in view <NUM> of an area <NUM> of the die/chip is shown where individual nodes <NUM> are more clearly visible. When the untested node map <NUM> is being presented to a user, the user is able to zoom in or out of the map to change the viewing level.

In at least one embodiment, one or more of the displayed nodes <NUM> to <NUM> are selectable to present additional information to the user. For example, the identifier of the selected node, the location information of the selected node, the identifier of the module comprising the node, the location information of the module, the identifier of the instance comprising the node, the location information of the instance, and/or combination thereof, can be displayed to the user responsive to the user selecting the node. In one example, a window (not shown in <FIG>) can be presented to the user comprising the aforementioned information. In some embodiments, responsive to a user selecting a node, areas on the map <NUM> representing the modules and/or instances comprising the selected nodes can be highlighted. It should be understood that embodiments are not limited to the representation of an untested node map illustrated in <FIG>, and other methods/techniques for representing an untested node map are applicable as well. Also, the data presented in the untested node map <NUM> can be filtered to only show untested nodes of interest. For example, nodes being untestable for a specific reason (e.g., specific architectural limitations) and modules having a specific function can be filtered out and not represented in the untested node map <NUM>.

Referring back to <FIG>, the low-test coverage identifier <NUM> utilizes the mapping data <NUM> (including any generated maps <NUM>) to identify low node test coverage areas of the circuit design. For example, the physical map analyzer <NUM> at block <NUM> analyzes the mapping data <NUM> and/or untested node map(s) <NUM> to determine clusters of untested nodes. A cluster of untested nodes, in one embodiment, is defined as two or more untested nodes located within a defined area at given distance from each other or from a central node. A cluster of untested nodes may reside within the same module or submodule or may be distributed across multiple modules and/or submodules. Clustered nodes are of interest because a close grouping of untested nodes increases the probability of test coverage for the area comprising the clustered nodes being inaccurate when determined by conventional test coverage mechanisms. Also, when analyzing test coverage from a physical perspective rather than a conventional module/hierarchical perspective, physical clustering of untested allows for the low-test coverage identifier <NUM> to determine low coverage physical points. Data <NUM> associated with untested node clusters, in one embodiment, can be stored locally, stored remotely, and/or transmitted to one or more information processing systems such as a server or user device. Examples of data included within the untested node cluster data <NUM> include a unique identifier for one or more clusters; physical location data associated with one or more clusters such as a range of coordinates; an identification of one or untested more nodes within a given cluster; untested node count for a cluster; and physical location data associated with each node such as a range of coordinates. The clustering operations performed at block <NUM> are discussed in further detail with respect to <FIG> and <FIG>.

Once clusters of untested nodes and their locations on the die/chip have been determined, the cluster prioritizer <NUM> at block <NUM> prioritizes the clusters according to one or more prioritization parameters. In one embodiment, the cluster prioritizer <NUM> prioritizes clusters based on, for example, the number of untested nodes (e.g., density) within the clusters, standard deviations associated with the density of untested nodes in the clusters and/or a combination thereof. In one example, clusters having a higher density of untested nodes, a higher number of contributing modules/submodules, a higher standard deviation and/or a combination thereof, are designated as a higher priority over clusters having a lower density of untested nodes, contributing modules/submodules, standard deviation, etc. Priority data and/or designations associated with one or more clusters can be stored as part of the untested node cluster data <NUM> and/or separately as cluster prioritization data <NUM>. It should be understood that embodiments of the present invention are not limited to the prioritizing parameters or criteria discussed herein.

<FIG>, in flow chart form, illustrates one example implementation of a process performed by the low-test coverage identifier <NUM> for clustering areas of untested nodes and prioritizing the untested node clusters. The physical map analyzer <NUM> of the low-test coverage identifier <NUM> at block <NUM> processes the mapping data <NUM> and/or untested node map(s) <NUM>. The physical map analyzer <NUM> at block <NUM> partitions the mapping data <NUM>/<NUM> into a grid comprising multiple cells of a given size. The physical map analyzer <NUM> at block <NUM> determines a plurality of cells from the multiple cells that comprise untested nodes. The physical map analyzer at block <NUM> identifies the plurality of cells as a plurality of untested node clusters. Once the clusters have been identified, the cluster prioritizer <NUM> of the low-test coverage identifier <NUM> at block <NUM> determines the density of each untested node cluster. The cluster prioritizer <NUM> at block <NUM> designates the highest density cluster as a reference cluster. The cluster prioritizer <NUM> at block <NUM> determines clusters that have a density greater than or equal to a given density threshold that has been defined based on the reference cluster. The clusters identified by the cluster prioritizer <NUM> at block <NUM> are designated by the cluster prioritizer <NUM> as priority clusters at block <NUM>. The priority clusters can be further prioritized with respect to each other based on their untested node densities at block <NUM>.

<FIG>, in flow chart form, illustrates another example implementation of a process performed by the low-test coverage identifier <NUM> for clustering areas of untested nodes and prioritizing the untested node clusters. The physical map analyzer <NUM> of the low-test coverage identifier <NUM> at block <NUM> processes the mapping data <NUM> and/or untested node map(s) <NUM>. The physical map analyzer <NUM> at block <NUM> partitions the mapping data <NUM>/<NUM> into a grid comprising multiple cells of a given size. The physical map analyzer <NUM> at block <NUM> determines the mean location within each grid cell, where the mean location represents where the weight of the distribution lies, i.e., the centroid. The physical map analyzer <NUM> at block <NUM> re-associates each untested node's cluster based on the untested node's proximity to the centroid. The physical map analyzer <NUM>, in at least one embodiment, performs the operations at blocks <NUM> and <NUM> a number of times, e.g., three times. The physical map analyzer <NUM> at block <NUM> determines a plurality of untested node clusters based on the operations performed at blocks <NUM> and <NUM>.

Once the clusters have been identified, the cluster prioritizer <NUM> of the low-test coverage identifier <NUM> at block <NUM> determines a standard deviation of the number of untested nodes for each cluster of the plurality of clusters based on a uniform distribution of a total number of untested nodes across the plurality of clusters. The cluster prioritizer <NUM> at block <NUM> then prioritizes the untested node clusters based on their standard deviation. For example, if the design includes <NUM>,<NUM>,<NUM> untested nodes, and the mapping data is divided into a grid of two hundred cells, then each grid can be expected to have <NUM>,<NUM> untested nodes following a uniform distribution. The cluster prioritizer <NUM>, in this example, identifies clusters having a <NUM>-sigma or higher standard deviation from the <NUM>,<NUM> untested nodes, clusters having a standard deviation between <NUM>-sigma and <NUM>-sigma, and clusters having a standard deviation between <NUM>-sigma and <NUM>-sigma. The clusters having a <NUM>-sigma or higher standard deviation are assigned the highest priority, while the clusters having a standard deviation between <NUM>-sigma and <NUM>. <NUM>-sigma are assigned the lowest priority.

In at least one embodiment, the low-test coverage identifier <NUM> implements one or more machine learning techniques to improve/optimize the cluster identification and prioritization processes performed by the low-test coverage identifier <NUM>. For example, the size of the grid cells, the density threshold, the number of iterations to perform each block, and the standard deviation values used for prioritization can be automatically updated by the low-test coverage identifier <NUM> based different executions of the cluster identification and prioritization processes. One example implementing machine learning includes utilizing prior historical data based off multiple runs of a tool using a sweep of parameter values to perform machine learning and establishing the most effective return of clusters based off a given set of parameters. These parameters could also be modified by bringing in other data analysis points such as product return data that could highlight problem areas, and then use the parameter sweeping to determine the most effective set of parameters for a given design. Also, modules that historically cause more issues than other modules can be given a higher weight when determining how to prioritized modules for the optimized test coverage data <NUM>.

Referring back to <FIG>, in addition to prioritizing the untested node clusters, the low-test coverage identifier <NUM> can also prioritize the modules contributing to each cluster. For example, the low-test coverage identifier <NUM> at block <NUM> determines the logical modules contributing to one or more of the prioritized untested node clusters. In at least one embodiment, a logical module contributes to a cluster if an untested node within the module is part of the cluster. In one embodiment, the low-test coverage identifier <NUM> analyzes the untested node cluster data <NUM> (or any other dataset); the node testability data <NUM>, <NUM>; the physical space/design data <NUM>; and/or a combination thereof; to determine the logical modules that contribute a given untested node cluster. For example, low-test coverage identifier <NUM> compares the identifier of a node within a given cluster to the node identifiers associated with each module to determine if the node is part of the module. In another example, the low-test coverage identifier <NUM> compares physical location data of a module with the physical location data of the cluster and/or each node within the cluster to determine if at least a portion of the module is located within the cluster and to also determine the particular nodes associated with the portion of the module located within the cluster. The low-test coverage identifier <NUM> can then update the untested node coverage data <NUM> to include module identifier data for a given cluster, module count for the given cluster, and/or the like.

The low-test coverage identifier <NUM> at block <NUM> prioritizes one or more of the contributing logical modules identified at block <NUM> according to one or more prioritization parameters. In one embodiment, module prioritization is performed on a per-cluster basis and based on the number of untested nodes within each module contributing to the cluster. Consider one example where Module_1, Module_2, and Module_3 each contribute to Cluster_1. In this example, Module_1 comprises <NUM>,<NUM> untested nodes within Cluster_1, Module_2 comprises eight hundred (<NUM>) untested nodes within Cluster_1, and Module_3 comprises <NUM>,<NUM> untested nodes within Cluster_1. The low-test coverage identifier <NUM>, in at least one embodiment, considers modules having a higher number of untested nodes in the cluster as a higher priority over modules having a lower number of untested nodes in the cluster because the probability of defects occurring increases as the number of untested nodes increases in a given area, i.e., cluster. Therefore, in this example, the low-test coverage identifier <NUM> determines that Module_1 is the highest priority module for Cluster_1, Module_2 is the next highest priority module for Cluster_1, and Module_3 is the lowest priority module for Cluster_1. Priority data and/or designations associated with one or more logical modules can be stored as part of the untested node cluster data <NUM> and/or separately as logical module prioritization data <NUM>.

The low-test coverage identifier <NUM> at block <NUM> generates optimized test coverage data <NUM> based on the previously generated data such as the intermediate test coverage data <NUM>, mapping data <NUM>, untested node map(s) <NUM>, untested node clustering data <NUM>, cluster prioritization data <NUM>, module prioritization data <NUM> and/or a combination thereof. The low-test coverage identifier <NUM>, in at least one embodiment, is considered optimized because this data was generated utilizing both node testability data <NUM>, <NUM> and physical space data <NUM> to identify areas of the design comprising low-test coverage that is not typically identified by conventional test analysis tools.

The low-test coverage identifier <NUM>, in at least one embodiment, can generate the optimized test coverage data <NUM> in various forms. For example, in at least one embodiment, the low-test coverage identifier <NUM> utilizes one or more of the generated sets of data <NUM> to <NUM> to update the mapping data <NUM> and/or generate additional untested node maps <NUM>. For example, the untested node map <NUM> shown in <FIG> can be updated to visually highlight areas comprising priority clusters and/or modules. For example, <FIG> shows one example of an updated untested node map <NUM>. In this example, the map <NUM> has been updated to highlight the top-N percent of untested node clustered areas in the design. In this example, the map <NUM> comprises an X-axis <NUM> and a Y-axis <NUM>, each including a coordinate scale such as micrometers, nanometers, etc. In this example, the top-N percent of untested node clustered areas are visually represented in a different manner to distinguish these areas from the remaining untested node clustered areas. For example, the top-N percent of untested node clustered areas, as areas <NUM>, are represented as black shaded areas, whereas the remaining clustered areas, such as area <NUM>, are represented as areas having a different shading intensity.

<FIG> shows another example of a map <NUM> generated by the low-test coverage identifier <NUM> based on the cluster data <NUM>, cluster prioritization data, module prioritization data <NUM>, a combination thereof, and/or the like. In this example, the map <NUM> is a "heat" map that visually distinguishes areas of untested nodes having a different number of untested nodes and/or different priorities. The map <NUM> comprises an X-axis <NUM> and a Y-axis <NUM>, each including a coordinate scale such as micrometers, nanometers, etc. The map <NUM> further comprises an untested node density scale <NUM>. In this example, areas having a higher number of clustered untested nodes or a higher priority are shaded with a darker intensity than areas having a lower number of clustered untested nodes or a lower priority. For example, area <NUM> is shaded with a darker intensity than area <NUM> because area <NUM> has a greater density of untested nodes. Similar to the untested node map <NUM> discussed with respect to <FIG>, the maps <NUM>, <NUM> of <FIG> and <FIG> can also be interactive maps that display addition data to users when different areas of the maps are selected. For example, a window (not shown in <FIG>) can be presented to the user comprising the aforementioned information. In some embodiments, responsive to a user selecting a node, areas on the maps <NUM>, <NUM> representing the modules and/or instances comprising the selected nodes can be highlighted.

<FIG> shows one additional example of optimized test coverage data <NUM>. In an example illustrated in <FIG>, the optimized test coverage data <NUM> comprises cluster priority data <NUM>, cluster identifier data <NUM>, undetected nodes/faults data <NUM>, modules and contribution data <NUM>, cluster location data <NUM>, and/or the like. However, other types of data are applicable as well and one or more of the illustrated data types can be removed and/or one or more different data types can be added.

The cluster identifier data <NUM> comprises the unique identifier associated with the corresponding cluster. The cluster priority data <NUM> comprises a priority assigned to the cluster by the low-test coverage identifier <NUM>, according to one or more operations discussed above. The undetected nodes/faults data <NUM> comprises the total number of undetected nodes/faults in the cluster. The modules data <NUM> comprises the identifier of each module contributing to the cluster. In another example, the identifiers for a given number of the highest priority modules are included in the modules data <NUM>. The modules data <NUM>, in one embodiment, also comprises the number of untested nodes/faults contributed to the cluster by each module. The cluster location data <NUM> comprises physical location data of the clusters, such as coordinates on the die/chip. In at least one embodiment, consider a first entry <NUM> in the optimized test coverage data <NUM>. This entry shows that a cluster with cluster identifier "<NUM>" has a cluster priority of "<NUM>" (with "<NUM>" being the highest priority), a total number of <NUM>,<NUM> undetected or untested nodes/faults, and is located on the die/chip at Location_1. The first entry <NUM> also shows that modules Module_A, Module_AB_4,. , Module_BB each contribute untested to this cluster, where Module_A contributed <NUM>,<NUM> untested nodes, Module_AB contributed <NUM>,<NUM> untested nodes, and Module_BB contributed <NUM>,<NUM> untested nodes.

<FIG> shows a further example of optimized test coverage data <NUM>. In this example, the optimized test coverage data <NUM> comprises data associated with one or more of the modules of the design and one or more clusters associated with the modules. The low-test coverage identifier <NUM>, in at least one embodiment, can obtain module data from the intermediate test coverage data <NUM>, the untested node cluster data <NUM>, the module prioritization data <NUM>, directly from the node testability data <NUM>, <NUM>, the physical space data <NUM>, a combination thereof, and/or the like.

In one example, the optimized test coverage data <NUM> of <FIG> includes module data <NUM>, test coverage measurement <NUM>, total node/fault data <NUM>, node/fault coverage measurement <NUM>, undetected node/fault data <NUM>, and clustered untested node/fault data <NUM>. In the example shown in <FIG>, data associated with the top-N overall contributing logical modules are shown, wherein the overall contribution of a logical module is determined based on the total number of untested nodes contributed by the module for all untested node clusters associated with the module, or based on the total number of untested nodes contributed by the module for a given number of the highest priority untested node clusters.

The module data <NUM> comprises, for example, an identifier of the given module, the name of the module, and/or the like. The test coverage measurement <NUM> indicates the amount of test coverage measured for the given module based on a ratio of the detected node count <NUM> (see <FIG>) and the testable node count <NUM> for the module. The total fault data <NUM> comprises the total number of nodes/faults <NUM> in the given module. The node/fault coverage measurement <NUM> indicates the amount of node/fault coverage measured for the given module based on a ratio of the detected node count <NUM> and the total number of nodes <NUM> in the given module. The undetected node/fault data <NUM> comprises, for example, the number of nodes/faults within the given module that were not tested. The clustered untested node/fault data <NUM> comprises, for example, the total number of nodes/faults contributed by the module to all untested node clusters associated with the module to a given number of the highest priority untested node clusters.

Consider a first entry <NUM> in the optimized test coverage data <NUM>. This entry shows module Module_A has an overall test coverage of <NUM>%, a total of <NUM>,<NUM> nodes/faults, a total fault coverage of <NUM>%, a total of <NUM>,<NUM> untested (undetected) nodes/fault and contributed a total of <NUM>,<NUM> untested/nodes faults to one or more untested node clusters. When this data is analyzed by a testing tool and/or by a designer, a determination can be made that even though the overall test coverage is <NUM>%, which is generally acceptable under current industry standards, the number of clustered nodes associated with this module is high when compared to other modules. Therefore, the design tool and/or designer is able to determine that the design/manufacturing test(s) and/or design for this module needs to be revised to increase test coverage for this module even though the total fault coverage is within acceptable limits.

Referring back to <FIG>, after the optimized test coverage data <NUM> has been generated, the flow returns to block <NUM>, where the low-test coverage identifier <NUM> waits to receive new input for repeating the operations discussed above with respect to blocks <NUM> to <NUM>. The test coverage optimization processes may be repeated numerous times after additional stimuli that exercise more nodes than previously may have been done to generate new node testability data <NUM>, <NUM>. After the logical and physical designs/tests of the chip have been revised based on the optimized test coverage data <NUM> and all design requirements have been satisfied, the optimized design is sent to the fabrication system <NUM> for fabrication of the designed chip.

<FIG>, in flow chart form, illustrates another example implementation of an overall process performed by the low-test coverage identifier <NUM> for determining areas of an integrated circuit design comprising test coverage gaps in accordance with some embodiments. A designer and/or a design tool at block <NUM> performs one or more design operations and implements a physical design flow at block <NUM>. A physical database map at block <NUM> is generated. Also, a verification engineer and/or a verification tool at block <NUM> and a functional pattern generator at block <NUM> perform one or more operations. A design-for-test engineer and/or a design-for-test tool at block <NUM> and an automatic test pattern generator at block <NUM> perform one or more operations. The operations performed at blocks <NUM> to <NUM> generate one or more sets of node testability reports at block <NUM>.

The low-test coverage identifier <NUM> at block <NUM> obtains the physical database map and determines coordinates of nodes within the circuit design. The low-test coverage identifier <NUM> at block <NUM> obtains the node testability report(s) and determines testability information of the nodes within the circuit design. The low-test coverage identifier <NUM> at block <NUM> merges the coordinate and testability data to generate a map of untested nodes at block <NUM>. In some embodiments, other opportunities for feeding in additional inputs at block <NUM> exist that can be utilized as inputs for machine learning at block <NUM> during the generation of untested node maps. Also, optional testability class filters at block <NUM> and optional module name filters at block <NUM> can be utilized during the merge data operations at block <NUM>.

<FIG> is a block diagram illustrating an information processing system <NUM> that can be utilized by one or more embodiments discussed herein. The information processing system <NUM> is based upon a suitably configured processing system configured to implement one or more embodiments of the present invention, such as the information processing system <NUM> of <FIG>. Any suitably configured processing system, including specialized processing systems, can be used as the information processing system <NUM>.

The components of the information processing system <NUM> can include but are not limited to, one or more processors or processing units <NUM>, a system memory <NUM>, and a bus <NUM> that couples various system components including the system memory <NUM> to the processor <NUM>. The bus <NUM> represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus.

Although not shown in <FIG>, the main memory <NUM> includes the low-test coverage identifier <NUM>. The low-test coverage identifier <NUM> can also reside within the processor <NUM>, or be a separate hardware component. The system memory <NUM> can also include computer system readable media in the form of volatile memory, such as random access memory (RAM) <NUM> and/or cache memory <NUM>. The information processing system <NUM> can further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, a storage system <NUM> can be provided for reading from and writing to a non-removable or removable, non-volatile media such as one or more solid-state disks and/or magnetic media (typically called a "hard drive"). A magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected to the bus <NUM> by one or more data media interfaces. The memory <NUM> can include at least one program product having a set of program modules that are configured to carry out the functions of an embodiment of the present disclosure.

Program/utility <NUM>, having a set of program modules <NUM>, may be stored in memory <NUM> by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules <NUM> generally carry out the functions and/or methodologies of embodiments of the present disclosure.

The information processing system <NUM> can also communicate with one or more external devices <NUM> such as a keyboard, a pointing device, a display <NUM>, etc.; one or more devices that enable a user to interact with the information processing system <NUM>; and/or any devices, e.g., network card, modem, etc., that enable computer system/server <NUM> to communicate with one or more other computing devices. Such communication can occur via I/O interfaces <NUM>. Still yet, the information processing system <NUM> can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network, e.g., the Internet, via network adapter <NUM>. As depicted, the network adapter <NUM> communicates with the other components of the information processing system <NUM> via the bus <NUM>. Other hardware and/or software components can also be used in conjunction with the information processing system <NUM>.

The term "coupled", as used herein, is defined as "connected" and encompasses the coupling of devices that may be physically, electrically or communicatively connected, although the coupling may not necessarily be directly and not necessarily be mechanical. The term "configured to" describes hardware, software, or a combination of hardware and software that is adapted to, set up, arranged, built, composed, constructed, designed, or that has any combination of these characteristics to carry out a given function. The term "adapted to" describes hardware, software, or a combination of hardware and software that is capable of, able to accommodate, to make, or that is suitable to carry out a given function.

The terms "a" or "an", as used herein, are defined as one or more than one. Also, the use of introductory phrases such as "at least one" and "one or more" in the claims should not be construed to imply that the introduction of another claim element by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an". The same holds true for the use of definite articles. Unless stated otherwise, terms such as "first" and "second" are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The term "coupled", as used herein, is not intended to be limited to a direct coupling or a mechanical coupling, and that one or more additional elements may be interposed between two elements that are coupled.

As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method, or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit" or "system".

The invention 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 invention.

In one embodiment, the computer program product includes a non-transitory storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A computer-readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media, e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer-readable program instructions for carrying out operations of the invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as Smalltalk, C++, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely or partly on a user's computer or entirely or partly on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry, in order to perform aspects of the invention.

Aspects of the invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention.

These computer-readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, create means for implementing the functions/acts specified in the flowchart and/or block diagram blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The description of the present disclosure has been presented for purposes of illustration and description but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claim 1:
A method of using an information processing system, comprising a processor, a memory communicatively coupled to the processor, and a test coverage analyzer (<NUM>) communicatively coupled to the processor and the memory, to determine test coverage for a circuit design, the method comprising:
by means of the test coverage analyzer: obtaining node testability data (<NUM>) and physical location data (<NUM>) for each node of a plurality of nodes in a circuit design;
determining one or more low test coverage areas (<NUM>) within the circuit design comprising untested nodes based on the node testability data and the physical location data of each node of the plurality of nodes; and
generating test coverage data for the circuit design comprising at least an identification of the one or more low test coverage areas; and
updating the circuit design based on the one or more low test coverage areas identified in the test coverage data, wherein updating the circuit design increases test coverage in at least one of the one or more low test coverage areas.