Blocking unknown data in non-scan elements

Abstract

Methods, systems, and media comprising: one or more non-scan elements, wherein each non-scan element has respective fanout logic comprising one or more scan flops; and a testing control module configured to block unknown data propagating from the one or more non-scan elements to the scan flops in the fanout logic by providing a scan-enable signal to the scan flops during a capture phase of a testing process.

Description

[0001] BLOCKING UNKNOWN DATA IN NON-SCAN ELEMENTS

[0002] BACKGROUND

[0003] Automatic Test Pattern Generation (ATPG) tools can be used to detect faults in a digital circuit by loading a test pattern of data that is designed to cause the logic circuitry to generate a known output according to the specifications of the logic circuitry. Typically, at-speed testing of digital circuitry has a scan-in phase, in which known data is loaded, and a capture phase that exercises the logic circuitry to generate an output. The contents of scannable components in the design can then be read out to detect problems or to verify the timing and logic functionality of the design.

[0004] However, not all components in a design are scannable. In particular, non-scan memories, which lack logic scan circuitry, are often used to improve the high-speed performance of processing circuits, e.g., for CPUs and GPUs. Non-scan memories, how ever, can become sources of unknown data propagating through the design. It is often difficult or impossible to verify the functionality of a logic circuit in the presence of sources of unknown data. The problem becomes even worse with circuits that are tested using scan compression, w hich is a technique that compresses the outputs of multiple scan chains in the design into a single output stream. When any of the scan chains include a source of unknown data, e.g., a non-scan memory, the scan outputs for hundreds or thousands of components on multiple different scan chains can become corrupted. This increases the complexity of testing and can result in testing coverage loss.

[0005] SUMMARY

[0006] This specification relates to blocking the propagation of unknown data in non- scan elements.

[0007] Typically, in prior ATPG techniques (e.g., “At-Speed” or “Transition” ATPG), scan flops are loaded with known values (“patterns”) that are shifted throughout different level flops (the “fanout logic”) of the non-scan element (e.g., a memory structure). At certain levels, the results of the shift are captured and used to isolate faults in the element. In some examples, ATPG testing performs operations based on two phases: a “scan-in” phase where data is loaded into the flops, and a later “capture” phase where data is captured by the next level flops in the fanout logic. Typically, a compressor replicates the output of a higher-level flop to many lower-level flops in the fanout logic. Occasionally, at the onset of loading the first level flops with a test pattern during the scan-in phase, unknown data can enter the fanout logic and proceed to "mask" faults, leading to a reduction in the total number of recovered ATPG test data values (e.g., “coverage” losses). This unknown data can be referred to as “X” or “X data.” The introduction of X data can be particularly harmful because, in some cases, a first level flop will shift its data to many second level flops during testing (e.g., hundreds or more), such that a single X data value will propagate extensively. To overcome the issue of introducing X data into the fanout logic, in some prior ATPG examples, additional patterns are loaded to recover the masked faults though additional cycles of testing. These additional patterns require additional computation power and processing cycles. Moreover, in some examples, patterns are rejected where masking is not possible, leading to further coverage losses.

[0008] The techniques proposed in this specification block the propagation of X values in the first stage of the fanout logic, preventing these values from masking faults and causing coverage losses. In this technique, the fanout logic of the circuit can be identified to determine first-level flops (the flops where X data is typically introduced) and the scan enable (“SE”) of the first level flops can be overridden by a testing control module such that data capture is performed using a scan-in path (“SI”) of the flop, rather than a data path (“D”) that carries the X data. In some examples, this testing control module is configured to be compatible with ATPG tools, such that the ATPG tool has operational control of the testing control module and can decide when to block function data from a flop.

[0009] Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. Advantages can include higher coverage during ATPG testing without any adverse impact to circuit timing. The reduction in the propagation of X data across the fanout logic also reduces the number of faults that are masked during ATPG testing and increases the speed of testing. Additionally, because the ATPG tool can be given operational control of the testing control module, the ATPG tool can selectively capture data across the entire circuit to best cover faults in different circuit configurations (referred to as “granularity” - examples are presented in FIGS. 3 and 4 below). Finally, these techniques can be implemented efficiently without substantial modification to circuit fanout logic or timing paths. The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

[0010] BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 is an overview of an example device for blocking unknown data propagation in non-scan elements.

[0012] FIG. 2 is an example device control module.

[0013] FIG. 3 is example device with multiple non-scan elements.

[0014] FIG. 4 is example device with multiple non-scan memories where one element includes multiple override control modules.

[0015] FIG. 5 is an example process for blocking unknown data propagation in non-scan elements.

[0016] DETAILED DESCRIPTION

[0017] FIG. 1 is an overview of an example device 100 for blocking unknown data propagation in non-scan elements. Although this example describes example device 100 with respect to a non-scan memory’ 102, it should be understood that these techniques can be applied to other non-scan elements, for example, non-scan flops. The example device 100 includes a non-scan memory 102, level one flops 106 A, level two flops 106B, a testing control module 108, and an override control module 110 (or override gate). Although the example device 100 is shown with certain numbers of levels and flops in the fanout logic, other suitable devices can have many different levels and flops (e.g., hundreds of flops per level, or more).

[0018] As discussed above, ATPG techniques load flops with data patterns that are shifted throughout the flops of the fanout logic of device 100. At certain levels, the results of the shift are captured and used to isolate faults in the memory structure. This occurs during two phases: ’‘scan-in” phase where data is loaded into the flops, and a later “capture” phase where data is captured and scanned to the next flop in the fanout logic.

[0019] In example device 100, non-scan memory 102 provides data to the first level flops 106A via compressor 104 A. In some examples, flops 106A and 106B include multiple inputs, including scan enable (“SE”), shift path (“SI”), and function data (“D”) inputs. Typically, flops 106A and 106B receive data from the proceeding flop or non-scan memory via the function data input. For example, after test data from non-scan memory 102 has been loaded into flops 106A during a scan-in phase of ATPG testing, the loaded data is shifted into the function data input of the next flop 106B via compressor 104B. Occasionally, X data is introduced to the flops 106 A when data is initially loaded in during this process. Without any further action, any X data present in the data loaded into flop 104A would propagate to every flop 106B that receives an input from compressor 104B.

[0020] To block the propagation of X data, the testing control module 108 controls which input from flops 106A is used to capture data during the capture phase of ATPG testing. If the testing control module 108 determines that X data has reached flops 106A from the non-scan memory 102. the testing control module 108 sends a signal to flops 106 A via override control module 110 to capture data from the shift path instead of the function data input. This prevents X data, typically introduced via the function data input of the flop 106A, from propagating to compressor 104B and all downstream flops 106B. Additionally, testing control module 108 is configured to control the propagation through the fanout logic of device 100. such that this signal is provided to every flop 104A that receives an input from override control module 110. In some examples, the testing control module 108 is under control of an ATPG tool which determines when X data blocking is appropriate. In some examples, override control module 110 also accepts input directly from a scan enable function 112 which can also be used to toggle the input that is used to capture data from flops 106A during the capture phase. The input to override control module 110 can be managed by appropriate circuit logic, for example, an OR gate. In some examples, coverage of functional logic 114 can also be obtained by using the function data input of flops 106A.

[0021] FIG. 2 is diagram of an example device testing control module 108. The example testing control module 108 includes a Test Data Register (TDR) ModeControl Bit 202, scan flops 204A-N, and AND gates 206A-N. In some examples, the TDR ModeControl Bit 202 is configured to toggle a signal to the AND gates 206A-N that provide the CaptureModeControl output 208A-N. For example, if the TDR ModeControl Bit 202 is enabled, a high signal is sent to the AND gates 206A-N. Additionally, in this example, AND gates 206A-N also receive input from a particular scan flop 204A-N. In some examples, one scan flop 204A-N provides an output to one AND gate 206A-N that generates a CaptureModeControl output 208A-N. In this example, when TDR ModeControl Bit 202 is enabled, and the AND gate’s 206A-N respective scan flop 206A- N output is high, the CaptureModeControl output 208A-N is high and the capturing of data from downstream flops in the non-scan memory is shifted to the shift path input. If the output of CaptureModeControl 208A-N is low (either TDR ModeControl Bit 202 is disabled or the associated scan flop 204A-N is low), the capturing of data from downstream flops in the non-scan memory is performed using the function data input.

[0022] The structure of the testing control module 108 allows for different control granularities. For example, a particular CaptureModeControl output 208A can be sent to one memory structure while CaptureModeControl output 208B can be sent to another, allowing the testing control module 108 to differentially control the blocking of X data between these two memory structures. In some examples, CaptureModeControl outputs 208 A-N can be sent to particular flops within the fanout logic of a non-scan memory, allowing the testing control module 108 to block X data for particular memory paths. In some examples, each memory structure can have a dedicated testing control module 108. Other configurations are possible, to include a combination of the above examples. FIGS. 3 and 4 describe particular examples in greater detail below. In general, the configuration of testing control module 108 can be altered to best suit the needs of the serviced device or non-scan memories.

[0023] FIG. 3 is an example device 300 with multiple non-scan elements. FIG. 3 includes similar components as in FIG. 1, with the exception that device 300 includes multiple non-scan memories 302A and 302B. Like FIG. 1, it should be understood that these techniques can be applied to other non-scan elements besides non-scan memory, for example, non-scan flops. In some examples, it is desirable to use one testing control module 108 to block unknown data across multiple non-scan memories 302A and 302B. In this example, the control module 108 is configured to separately block or not block unknown data in two different domains - one for each non-scan memory 302A and 302B, respectively. The override control modules 110A and HOB control the scan enable signal using an OR gate that is high either during the scan-in phase of testing or during the capture phase due to the override signal provided by the control module 108.

[0024] By extending the testing control module 108 to multiple memory structures, the testing control module 108 can block unknown data with greater granularity and allow “per memory” blocking of unknown data. For example, it may be desirable to block unknown data in non-scan memory' 302 A, but not 302B. In this example, testing control module 108 can toggle the data capture input of the first level flops in non-scan memory 302A via override control module 110A while leaving the data capture of non-scan memory 302B undisturbed (the output of override control module HOB would be low in this case).

[0025] FIG. 4 is diagram of an example device 400 with multiple non-scan elements where one element includes separate override control modules for different first level flops 106A and 107A. Like FIGS. 1 and 3, it should be understood that these techniques can be applied to other non-scan elements besides non-scan memory, for example, nonscan flops. FIG. 4 includes similar components as in FIG. 1, with the exception that device 400 includes a non-scan memory 402A with multiple override control modules. In some examples, it is desirable to override the capture of data from one set of first level flops 106A in a non-scan memory 402A (but not a second set of first level flops 107 A). In this example device 400, two override control modules 110A and 110B receive input from the testing control module 108 and each override a set of first level flops 106A and 107B, respectively. In some examples, this granularity of control allows X data blocking to be performed for a specific output port or memory path of non-scan memory 302A that has more critical timing requirements. In some examples, other non-scan memories 402B can have a differing number of override control modules, for example, a single override control module 110C. The number of override control modules per non-scan memory can be configured depending on the needs of the device or application.

[0026] FIG. 5 is an example process 500 for blocking unknown data propagation in non- scan memory. The example process 500 includes loading data into a first set of flops of a non-scan memory during a scan-in phase of testing (510). In some examples, the loading of data is performed using ATPG techniques, for example, “At-Speed,” “Transition,” or “Stuck- At” ATPG techniques. Prior to loading data, the fanout logic of the non-scan memory can be identified to determine the appropriate first level flops.

[0027] The examples process 500 includes identifying that the loaded data includes unknown data (520). Occasionally, unknown data is introduced during a scan-in phase of ATPG testing. The introduction of unknown data can be determined by a testing control module, an ATPG tool, or a combination of both.

[0028] The example process 500 includes toggling the capture of data from the flops during a capture phase of testing to a shift path input (530). Typically, the capture of data during the capture phase of ATPG testing is performed using the data function input of a flop. By toggling the capture of data to the shift path input, this prevents unknow n data from propagating to the next level flops. The example process 500 then concludes by capturing data from the shift path input of the flops and sending the captured data to a second level of flops (540).

[0029] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Alternatively or in addition, the program instructions can be encoded on an artificially- generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus.

[0030] The term “data processing apparatus” refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0031] A computer program which may also be referred to or described as a program, software, a software application, an app, a module, a software module, a script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data, e.g., one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code. A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a data communication network.

[0032] For a system of one or more computers to be configured to perform particular operations or actions means that the system has installed on it software, firmware, hardware, or a combination of them that in operation cause the system to perform the operations or actions. For one or more computer programs to be configured to perform particular operations or actions means that the one or more programs include instructions that, when executed by data processing apparatus, cause the apparatus to perform the operations or actions.

[0033] As used in this specification, an ‘'engine,” or “software engine,” refers to a software implemented input / output system that provides an output that is different from the input. An engine can be an encoded block of functionality', such as a library', a platform, a software development kit (“SDK”), or an object. Each engine can be implemented on any appropriate ty pe of computing device, e.g., servers, mobile phones, tablet computers, notebook computers, music players, e-book readers, laptop or desktop computers, PDAs, smart phones, or other stationary' or portable devices, that includes one or more processors and computer readable media. Additionally, two or more of the engines may be implemented on the same computing device, or on different computing devices.

[0034] The processes and logic floyvs described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic floyvs can also be performed by special purpose logic circuitry-, e.g., an FPGA or an ASIC, or by a combination of special purpose logic circuitry and one or more programmed computers.

[0035] Computers suitable for the execution of a computer program can be based on general or special purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory' or both. The essential elements of a computer are a central processing unit for performing or executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special purpose logic circuitry'. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to. or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device, e.g., a universal serial bus (USB) flash drive, to name just a few.

[0036] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory', media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g.. internal hard disks or removable disks; magnetooptical disks; and CD-ROM and DVD-ROM disks.

[0037] To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and pointing device, e.g, a mouse, trackball, or a presence sensitive display or other surface by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's device in response to requests received from the web browser. Also, a computer can interact with a user by sending text messages or other forms of message to a personal device, e.g., a smartphone, running a messaging application, and receiving responsive messages from the user in return.

[0038] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application sen’ er, or that includes a front-end component, e.g., a client computer having a graphical user interface, a web brow ser, or an app through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back-end, middlew are, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[0039] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received at the server from the device.

[0040] In addition to the embodiments described above, the following embodiments are also innovative:

[0041] Embodiment 1 is a device comprising one or more non-scan elements, wherein each non-scan element has respective fanout logic comprising one or more scan flops; and a testing control module configured to block unknown data propagating from the one or more non-scan elements to the scan flops in the fanout logic by providing a scanenable signal to the scan flops during a capture phase of a testing process.

[0042] Embodiment 2 is the device of embodiment 1, wherein the capture phase of the testing process exercises a data path of scan flops that are outside of the fanout logic of the one or more non-scan elements.

[0043] Embodiment 3 is the device of embodiment 2, wherein the testing process comprises a scan-in phase and the capture phase, and wherein the device is configured to provide a scan-enable signal to all scan flops during the scan-in phase.

[0044] Embodiment 4 is the device of any one of embodiments 1-3, wherein providing the scan-enable signal to the scan flops in the fanout logic of the one or more non-scan elements during the capture phase of the testing process prevents the unknown data in the one or more non-scan elements from propagating through a data path of the scan flops.

[0045] Embodiment 5 is the device of any one of embodiments 1-4, wherein the device comprises a separate testing control module for each of the one or more non-scan elements.

[0046] Embodiment 6 is the device of any one of embodiments 1-5, wherein the device comprises multiple testing control modules for different respective portions of the fanout logic of a single non-scan elements. Embodiment 7 is the device of any one of embodiments 1-6, wherein the device comprises a single testing control module for all non-scan elements of the device.

[0047] Embodiment 8 is the device of any one of embodiments 1-7, further comprising an override gate that performs a bit-wise OR between a global scan enable signal and an output of the testing control module.

[0048] Embodiment 9 is the device of any one of embodiments 1-8, wherein the testing control module comprises a plurality of configuration flops that respectively enable or disable blocking of the unknown data propagating from a plurality of non-scan elements.

[0049] Embodiment 10 is the device of any one of embodiments 1-9, wherein the testing control module comprises a mode control bit that enables or disables blocking of unknown data for each of the one or more non-scan elements.

[0050] Embodiment 11 is a method performed by a device comprising one or more non- scan elements, each non-scan element having respective fanout logic comprising one or more scan flops, the method comprising: providing, by a testing control module, a scanenable signal to the scan flops during a capture phase of a testing process, wherein providing the scan-enable signal blocks unknown data from propagating from the one or more non-scan elements to the scan flops in the fanout logic.

[0051] Embodiment 12 is the method of embodiment 11, wherein the capture phase of the testing process exercises a data path of scan flops that are outside of the fanout logic of the one or more non-scan elements.

[0052] Embodiment 13 is the method of embodiment 12, wherein the testing process comprises a scan-in phase and the capture phase, and wherein the device is configured to provide a scan-enable signal to all scan flops during the scan-in phase.

[0053] Embodiment 14 is the method of any one of embodiments 11-13, wherein providing the scan-enable signal to the scan flops in the fanout logic of the one or more non-scan elements during the capture phase of the testing process prevents the unknown data in the one or more non-scan elements from propagating through a data path of the scan flops.

[0054] Embodiment 15 is the method of any one of embodiments 11-14, wherein the device comprises a separate testing control module for each of the one or more non-scan elements.

[0055] Embodiment 16 is the method of any one of embodiments 11-15, wherein the device comprises multiple testing control modules for different respective portions of the fanout logic of a single non-scan element. Embodiment 17 is the method of any one of embodiments 11-16, wherein the device comprises a single testing control module for all non-scan elements of the device.

[0056] Embodiment 18 is the method of any one of embodiments 1 1-17, further comprising an override gate that performs a bit-wise OR between a global scan enable signal and an output of the testing control module.

[0057] Embodiment 19 is the method of any one of embodiments 11-18, wherein the testing control module comprises a plurality of configuration flops that respectively enable or disable blocking of the unknown data propagating from a plurality of non-scan elements.

[0058] Embodiment 20 is one or more non-transitory computer storage media encoded with computer program instructions that when executed by one or more computing devices comprising one or more non-scan elements, each non-scan element having respective fanout logic comprising one or more scan flops, the instructions comprising: providing, by a testing control module, a scan-enable signal to the scan flops during a capture phase of a testing process, wherein providing the scan-enable signal blocks unknown data from propagating from the one or more non-scan elements to the scan flops in the fanout logic.

[0059] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0060] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain cases, multitasking and parallel processing may be advantageous.

[0061] What is claimed is:

Claims

CLAIMS1. A device comprising: one or more non-scan elements, wherein each non-scan element has respective fanout logic comprising one or more scan flops; and a testing control module configured to block unknown data propagating from the one or more non-scan elements to the scan flops in the fanout logic by providing a scanenable signal to the scan flops during a capture phase of a testing process.

2. The device of claim 1, wherein the capture phase of the testing process exercises a data path of scan flops that are outside of the fanout logic of the one or more non-scan elements.

3. The device of claim 2, wherein the testing process comprises a scan-in phase and the capture phase, and wherein the device is configured to provide a scan-enable signal to all scan flops during the scan-in phase.

4. The device of any one of claims 1-3, wherein providing the scan-enable signal to the scan flops in the fanout logic of the one or more non-scan elements during the capture phase of the testing process prevents the unknown data in the one or more non-scan elements from propagating through a data path of the scan flops.

5. The device of any one of claims 1-4, wherein the device comprises a separate testing control module for each of the one or more non-scan elements.

6. The device of any one of claims 1-5, wherein the device comprises multiple testing control modules for different respective portions of the fanout logic of a single non-scan elements.

7. The device of any one of claims 1-6. wherein the device comprises a single testing control module for all non-scan elements of the device.

8. The device of any one of claims 1-7, further comprising an override gate that performs a bit-wise OR between a global scan enable signal and an output of the testing control module.

9. The device of any one of claims 1-8, wherein the testing control module comprises a plurality of configuration flops that respectively enable or disable blocking of the unknown data propagating from a plurality of non-scan elements.

10. The device of any one of claims 1-9, wherein the testing control module comprises a mode control bit that enables or disables blocking of unknown data for each of the one or more non-scan elements.

11. A method performed by a device comprising one or more non-scan elements, each non-scan element having respective fanout logic comprising one or more scan flops, the method comprising: providing, by a testing control module, a scan-enable signal to the scan flops during a capture phase of a testing process, wherein providing the scan-enable signal blocks unknown data from propagating from the one or more non-scan elements to the scan flops in the fanout logic.

12. The method of claim 1 1 , w herein the capture phase of the testing process exercises a data path of scan flops that are outside of the fanout logic of the one or more non-scan elements.

13. The method of claim 12, wherein the testing process comprises a scan-in phase and the capture phase, and wherein the device is configured to provide a scan-enable signal to all scan flops during the scan-in phase.

14. The method of any one of claims 11-13, wherein providing the scan-enable signal to the scan flops in the fanout logic of the one or more non-scan elements during the capture phase of the testing process prevents the unknown data in the one or more non- scan elements from propagating through a data path of the scan flops.

15. The method of any one of claims 11-14, wherein the device comprises a separate testing control module for each of the one or more non-scan elements.

16. The method of any one of claims 11-15, wherein the device comprises multiple testing control modules for different respective portions of the fanout logic of a single non-scan element.

17. The method of any one of claims 11-16, wherein the device comprises a single testing control module for all non-scan elements of the device.

18. The method of any one of claims 11-17, further comprising an override gate that performs a bit-wise OR between a global scan enable signal and an output of the testing control module.

19. The method of any one of claims 11-18, wherein the testing control module comprises a plurality of configuration flops that respectively enable or disable blocking of the unknown data propagating from a plurality of non-scan elements.

20. One or more non-transitory computer storage media encoded with computer program instructions that when executed by one or more computing devices comprising one or more non-scan elements, each non-scan element having respective fanout logic comprising one or more scan flops, the instructions comprising: providing, by a testing control module, a scan-enable signal to the scan flops during a capture phase of a testing process, wherein providing the scan-enable signal blocks unknown data from propagating from the one or more non-scan elements to the scan flops in the fanout logic.

Images