Low Cost At-Speed Testing using On-Product Clock Generation Compatible with Test Compression

Transcription

1 Low Cost At-Speed Testing using On-Product Clock Generation Compatible with Test Compression B. Keller, K. Chakravadhanula, B. Foutz, V. Chickermane, R. Malneedi, T. Snethen Cadence Design Systems, USA V. yengar, D. Lackey, G. Grise BM Corp., Burlington, Vermont, USA Abstract At-speed testing with functional speed clocks is often done using On-Product Clock Generation (OPCG). When test compression logic is also embedded within the circuit's DFT architecture, the loading of the OPCG programming bits can impact test compression results. We present an approach to the use of OPCG that enables high-speed testing and is compatible with test compression. t also enables the use of tests that pulse multiple domains to further reduce test time and data volume. t also supports generation of inter-domain and static ATPG tests. We present results on four designs; one design shows an over 35% reduction in patterns due to use of multiple clock domains per test. An additional 1+% savings is possible using side-scan to load the OPCG programming registers. 1. ntroduction The trend towards smaller geometries has placed greater focus on timing defects and their impact on product quality and reliability. At technologies 9nm and below, targeting delay faults has become part of standard manufacturing test flows; however, at-speed delay test brings along with it a unique set of challenges. Performing delay test requires the automatic test equipment (ATE) to supply the high speed clocks used to apply the multiple at-speed clock pulses to the design. Standard ATE not only has a limited number of clock pins, but is also limited in the maximum clock frequencies it can supply. Only very expensive ATE has clock pins capable of running at Gigahertz frequencies. Even so, there may not be enough pins to drive the tens (or possibly hundreds) of internal clock domains..ruu1jlfuuul.. PLL.1/UUU\UUUU Referenc:e Clock Trigger OPCG Logic nternally generated clock / --"1L Figure 1. At-Speed Testing Using OPCG Logic To reduce the cost of test, On-Product Clock Generation (OPCG) logic can be inserted to leverage the functional phase-locked loops (PLLs) in the design and generate the high-speed clock signals on the chip [1-4]. OPCG refers to the testability logic inserted into the functional clock path of PLLs present in the design. OPCG allows for the generation of on-chip launch and capture clocks used to perform atspeed or faster than at-speed testing of the design during delay test A TPG. Figure 1 shows a PLL generating high speed clock pulses from the relatively low frequency reference clock input. The free running oscillator clock from the PLL is intercepted by the OPCG logic. Once the Trigger signal is activated, the OPCG logic allows only a certain number of the free running high speed clock pulses to get through to the clock domains. The block marked OPCG Logic is present on the functional clock path from the PLL, and is bypassed during normal functional operation. An OPCG state machine is typically inserted into each clock domain of a design to generate pulses for that domain. These state machines are usually programmable so that many different clocking sequences can be produced by the logic, based only on loading different programming bits into each state machine. As more designs use test compression [7-11] to help reduce test costs, it can be difficult to deal with loading the many programming bits for OPCG which are a critical component of each test pattern; the programming bits are effectively a large set of care bits required to be loaded for each test. The bandwidth consumed by re-oading OPCG programming bits for each test can impact the efficiency of any test decompression scheme. Another aspect that is important for saving test cost is to keep the number of tests as low as possible. When running at-speed clock pulses it is important to avoid race conditions that may appear across clock domains. When there may be many tens of domains, it is highly inefficient to produce double pulse, intra-domain tests that use one domain per test. t can also be useful to be able to generate inter-domain tests as well as static A TPG tests utilizing the OPCG clocking mechanism simply because it allows use of a single (or a few) test clocks for scanning while utilizing the functional clock domains for capturing. This paper describes the design of OPCG logic that is compatible with test compression. t also presents an automated methodology for insertion of this OPCG logic and generation of at-speed delay test patterns. The key benefits can be summarized as follows. Paper 24.3 NTERNATONAL TEST CONFERENCE $ EEE

2 The OPCG logic has some unique programmable features that allow for generation of inter-domain tests, leading to higher quality patterns, and can also test multiple domains simultaneously, thus lowering the number of tests needed to be applied. The methodology is fully compatible with all test compression architectures. The OPCG logic is programmed via a side-scan mechanism, reloading the programming bits only when the clocking sequence needs to change. This avoids any negative impact on the test compression efficiency from re-oading the OPCG programming bits on each test. The clocking sequences that utilize the OPCG pulses are automatically generated by analyzing the clock domains and the inter-domain paths. The OPCG logic can be used for targeting stuck-at faults as well. Race conditions between asynchronous domains can be avoided by taking advantage of the programmability of the OPCG logic. The OPCG logic is fully stuck-at testable since the OPCG state elements are included within the scan chains during all non-opcg test modes. Launch-off-Scan (LoS) and Launch-off-Capture (LoC) methods of transition fault testing are fully supported. The novel features of this at-speed test methodology also include cross clock domain path blocking that enables the test of multiple asynchronous domains together. f domains are synchronous, we can test them together by enabling crossings. Moreover, the functional clock gating to a downstream clock domain can be either turned on or off. n one scenario, the mission-mode clock gating will control the functional clock going to a downstream sub-domain. n another scenario, functional clock gating is disabled or the clock is forced off no matter what the clock gating does. Furthermore, delay values may be set between the test of two domains that have asynchronous data crossings. f these domain crossings are not blocked, we can stagger their test clock pulses using a delay value. 2. Previous Work The use of OPCG for at-speed test using low cost testers was initially focused on high-speed CPU designs such as described in [1-3]. These required a lot of customization and manipulation of ATPG patterns since the OPCG logic was not fully modeled in the A TPG tools at that time. Some of the implementation challenges and requirements for lowcost tester support are well described in [4]. ATPG advances to recognize these test clock controllers can be referenced in [5-6]. n the area of on-product test data compression [7,9-11] describe the most common embedded test compression structures in production use today. X-masking requirements for at-speed testing are described in [8]. This work builds on top of previously reported foundational work done by BM and Cadence using At-Speed Structural Testing [12], OPCG automation [13] and test data compression [7-8]. The earliest use of OPCG in BM chips that was supported by automation tools was done in the 198's to help support Logic BST that would be applied in the system using on-product generated clocks and also on A TE. The previous work was not directly trying to make the OPCG compatible with compression and did not try to reduce the number of tests by allowing more clocks to fire within the same test, both of which we are showing in this paper. Other work related to the implementation of onproduct clock controllers to address specific issues such as low-cost tester interfaces, multiple clock domains, low power considerations, clock tree design, A TPG selection of launch-capture sequences, etc. are covered in [14-19]. Design and verification aspects of clock-domain crossings are covered in [2]. 3. Cost of Test Considerations for OPCG When using test compression, the scan data feeds the internal chains through some form of decompression logic. When we use programmable OPCG logic, the program bits have to be loaded during test application. The most common way to load OPCG program bits is to place the programming bits into the normal scan chains. This way, once we define what to load into the bits, that data is loaded using the traditional scan paths. That worked well in the past, but as more scan chains are being fed by decompressor logic, loading the OPCG programming may require solving of equations in order to get the right bits loaded (Figure 3. 1 (a)). n addition, the OPCG programming bits begin to compete with A TPG care bits for the decompression bandwidth that is available. When there are multiple tens or hundreds of clock domains, the sheer volume of programming bits for OPCG may cause trouble if loaded via decompression logic. Note that while it may be acceptable for the occasional fault to remain untested due to care bit collisions, all OPCG programming bits must get loaded as expected, lest we produce a clocking sequence that does not match what is expected. We have heard of cases where clock sequences could not be produced due to care bit conflicts just between OPCG programming bits. Coverage loss can easily occur if valid, timing safe clocking sequences cannot be programmed due to such care bit conflicts. S V= SO (b) OPCG Program Register S so Figure 3. 1 Considerations for OPCG Programming Paper NTERNA TONAL TEST CONFERENCE 2

3 One way around this problem is to dedicate scan-in pins to feed OPCG programming registers only, so they will never be competing against A TPG care bits or each other for decompressor bandwidth (Figure 3. 1 (b)). This should work, but it may consume a large percentage of the available scanin bandwidth for OPCG programming. For example, if there are 8 scan-in pins, dedicating 1 scan-in pin to load OPCG programming bits for each test consumes 12.5% of the scanin bandwidth just for OPCG programming. f there are even fewer scan-in pins, the percentage will be even higher. Also, if the number of internal clock domains is high, it may be necessary to use more than one scan chain to contain the programming bits and keep the chains balanced. Designs with very low test pin counts (4 or fewer scan-in pins) are severely impacted if 2+ scan pins must be dedicated to loading OPCG programming bits. The approach we recommend in this paper is that OPCG programming registers are not modified once they are loaded and the programming bits need not be reloaded for each test that uses the same clocking. This affords the ability to load the programming bits separately from the normal scan chains, using a mechanism called side scan, which is similar to how EEE uses different instructions to scan different sets of chains. This mechanism allows us to utilize all of the scan-in pins for loading the programming bits; side scan uses a separate scan procedure that is independent of the normal scan chain loading (Figure 3. 1 (c)). The one expense of using side-scan is that you need either a separate clock to scan these bits, or you must qualify an existing clock to note when it is used for side scan versus when it is used for something else. Even when using test compression, the use of OPCG can cause an increase in test time and data volume. This can happen if the internal domains have some cross-domain paths that can cause race conditions. n many cases the OPCG will be effective at generating double pulse tests for intra-domain testing; however, if domain A talks to domain B, pulsing domains A and B in the same test could easily set up cross domain paths that do not satisfy the timing from the OPCG clocks. To avoid such race conditions, it is common to see tests produced that double pulse a single domain per test. To test all domains will thus require many more tests than when it is possible to double pulse multiple domains per test. To allow multiple domains to be (double) pulsed in the same test, three approaches can be utilized: 1. Domains that do not communicate with each other can be pulsed in the same test. 2. f a delay counter is included in the state machine logic for a clock domain, it becomes possible to delay its clock firing until after a prior domain with which it may communicate. By staggering the clock domains, e.g., double pulse A, pause, then double pulse B, we allow more domains to participate in each test, reducing the number of tests that should be required. 3. Domain input blocking. With analysis to detect where cross-domain paths exist, we can insert logic that will block the receiving flops so they cannot capture data from outside the domain. This logic can be under control of an OPCG program bit for the domain. By loading the programming bits via side scan only when we want to change to a different clocking sequence, we are reducing the bandwidth consumed by OPCG programming on a per test basis. This is also compatible with most test compression/decompression approaches in use in the industry [7-11]. By including more clock domains in each test, we are ensuring that we can apply the tests in the most cost effective manner. 4. Description of OPCG Logic This section describes the OPCG logic. t is assumed that the device will already contain one or more PLLs to allow generation of high frequency clocks internally from a more modest frequency oscillator input from the ATE. A reference clock can be provided either by pulsing that pin one or more times per tester cycle, or by including an oscillator on the load board. Reference Clock Trigger OPCG Domain Macro Figure 4. 1 OPCG logic on the clock path Clock Domain Figure 4. 1 shows OPCG logic (OPCG Domain and Trigger macros) inserted on the functional clock path driven by the on-chip PLL. During the functional mode of operation (TESTMODE = ), the inserted OPCG logic is bypassed and the PLL (or a clock derived from the PLL) directly drives the clock domains. During OPCG test modes (TESTMODE = 1, OPCGMODE = 1), the OPCG state machine generates the high speed capture pulses and the SCANCLK is used during the scan shift operation. The test clock connected to the SCANCLK pin is used for both scan and capture during the non-opcg test modes (OPCGMODE = ). A Trigger Macro is inserted on the primary input Trigger signal to perform glitch removal and to generate reset and run signals sent to the OPCG domain macros. Figure 4.2 shows that once the Trigger signal is asserted, the Trigger Macro first generates the Reset signal to reload the OPCG state machines to the programmed state. A few cycles later the Run signal is generated, which starts the generation of Paper NTERNATONAL TEST CONFERENCE 3

4 pulses from the OPCG state machine. A single Trigger Macro instance can support several domain macro instances. osc Trigger --lr-----s Reset Run ---.J S -1'1- -:- Figure 4.2 Trigger Macro waveforms The OPCG domain macros are intended to be used once for each independent clock domain. They include a state machine that will produce a sequence of clock pulses when the Trigger signal is active. The state machine quiesces once the pulse sequence is completed. The number of pulses to be generated by the OPCG state machine is programmable, including an ability to program it such that no pulses will be generated. Static test generation can also be performed using this OPCG logic since the state machine is capable of generating a single pulse. The state machine itself runs off a supplied oscillator input clock that is sourced from a PLL. Though not shown in the figure, an optional clock divider can also be inserted on the path between the PLL and the Domain Macro. This would be necessary when the PLL driving this clock domain during test is not the same PLL that drives the domain during functional operation. Since the A TE may be limited in the number of reference clocks it can supply, it is possible that a subset of the functional PLLs may be operational in OPCG test modes. RUN -L==F+= Prograrron..,le Register (R.gl.tu Wk*h. Ota..y COWlttr width. b.rotpulstll Figure 4.3 Block diagram of OPCG Domain Macro OPCGCLK Figure 4.3 shows the OPCG domain macro containing a programmable shift register whose most significant bits are allocated for the Optional Delay Counter and the least significant bits are allocated for the Pulse Generator. The domain clock output, OPCGCLK, is a multiplexed clock between the functional clock, scan clock and the at-speed pulse generator. Primarily, the RESET signal from the Trigger Macro is used to reload the functional pulse generator and delay counter registers from the programmable registers in the domain macro. The main function of RUN is to enable the domain macro logic to release the at-speed pulses that have been programmed. t is critical to have the RUN signal (input to the pulse generator) also gate the pulse generator output when it is zero to avoid having to reset the state elements prior to its first programming and running. The optional delay counter runs at half the PLLCLK frequency and can be used to delay the at speed pulse generation. When the delay counter is present, the RUN signal to the pulse generator is delayed until the delay counter gets to all zeros. The delay counter, programmed with a value of n>o, counts 2n - cycles before asserting it's enable output to release the domain output pulses. f the programmed value is n=o, there is no delay before pulses are enabled. n our experience, delay counter sizes of between 4 to 7 bits provide sufficient cycles of delay with a small hardware overhead for the counter. The delay counters allow multiple asynchronous domains to be pulsed in a single test even if these domains may communicate - the delay counter provides sufficient delay to ensure no races between domains are seen. This is illustrated in Figure 4.4 where Domain _ A is driven by the oscillator OSC-d and Domain_B is driven by OSC73. Once the Run signal goes active, Domain_A emits two consecutive pulses without any delay, while Domain_B emits two pulses after a delay of 5 OSC73 cycles. asc Trigger --lr---;--..;----;.-----s Reset ---1'--!--! -----_: :_-- Run OSC+l OSC+3 Domain_A ---;.- : M'-i-: _.;.- Domain_B...;_-+-_;... _ ---n...n Figure 4.4 Domain Macro waveforms with Delay Counter The RTL for the OPCG trigger and domain macros is constructed in a manner such that in a non-opcg test mode, all their state elements are included within normal scan chains - allowing them to be tested along with the functional logic. Figure 4.5 (b) shows the scan path through OPCG Domain Macro state elements that are enabled when OPCGMODE=O. These small scan segments will be concatenated to the front of normal scan chains for non OPCG test modes. For OPCG test modes (OPCGMODE=l), these scan segments are bypassed as shown in Fig 4.5 (a). OPCGMOOE... 1'... 1 SDE_SCANJN SCANN OPCGMODE (a) OPCG Test Mode (OPCGMOOE = 1) SOE_SCAN_OUT SCANOUT SCANN SCANOUT -===--====-- (b) Non.QPCG Test Mode (OPCGMOOE = ) Figure 4.5 Scan configuration within Domain Macro Figures 4.3 and 4.5 also show the side scan path used to program the OPCG logic. The program registers contained Paper 24.3 NTERNA TONAL TEST CONFERENCE 4

5 within the various macros are stitched into multiple side scan chains by concatenating segments of different domain macros. The side-scan approach allows multiple chains to be sourced directly from the scan-in pins for the test mode. These chains are balanced to minimize the number of cycles required to load new OPCG clock sequence programming. The side scan chains are activated only during the OPCG modes of operation (OPCGMODE=). The scan clock for these registers (SDE_SCAN _ CLK) is separate from that used to run the normal scan chains, or an existing clock can be gated to ensure the program register values don't change during the normal scan operation. The side scan chains are loaded independently from the normal scan chains and are used to load the programming for a clocking sequence only when a new clocking sequence is needed. These side chains use the full bandwidth of the scan-in pins and do not use test compression logic to decompress the programming bits. By loading the OPCG program bits separately from the normal scan data we leave the full scan-in bus and decompressor bandwidth for use in loading the A TPG care bits for each test. This can be extremely important when dealing with programming bits for hundreds of internal clock domains. 5. Automatic Sequence Generation There are three types of sequences needed to run OPCG tests: 1. Test mode initialization sequence. 2. OPCG program loading sequence. 3. OPCG launch & capture clocking sequence. The mode initialization sequence brings the circuit into the basic state needed to run the tests for that test mode. This may include loading configuration bits via EEE scan or other means. n the case of OPCG test modes, the circuit setup will also normally include programming and setup of the PLLs so that they begin to run from an input reference oscillator signal and lock onto the frequency and phase of that reference signal. t is important not to generate any tests that use the PLL output if the PLL has not locked onto the reference clock signal or you risk having the tests fail or become un-repeatable. For OPCG test modes we check that any PLLs in use to run the OPCG logic have been started and that there is a wait for locking to occur prior to exiting the mode initialization sequence. Because we expect the mode initialization sequence to get the PLLs up and running and because the A TPG automation is not currently knowledgeable about how to do this for the wide variety of PLL P blocks that exist, this sequence must be supplied by the end user (except for the additional BM automation described later that generates this sequence as well). We call the sequences used to load OPCG programming setup sequences. A setup sequence defines how to load the programming for a given clocking sequence that pulses the internal domains for launch and/or capture events between scan load and unload. These sequences include a special event called Load OPCG Controls that lists the OPCG registers by name and assigns them values to be loaded. The registers can be one or more bits long each and may be used to define: The number of pulses to be issued for the domain and relative placement of those pulses. Any delay to be applied that will wait some number of domain cycles between when the run signal is received and the first pulse appears at the domain clock tree root. Control bits that may configure blocking of inputs from other domains, or that may override functional clock gating, etc. An example setup sequence might look like this: Definesequence <sequence_name> type=setup Load OPCG Controls : Domain A pulsegen = 11 Domain=A=delay = Domain_B_pulsegen = 11 Domain_B_delay = 11 ; Test sequences for OPCG test modes denote pulses on the internal clock domains as pulses on the pseudo-primary inputs (PPs) that have been defined to represent the roots of each domain's clock tree. Such test sequences for OPCG test modes will normally include a reference to a specific setup sequence that shows how to load the OPCG programming to make the test sequence's clocking work as defined. Only tests that do not issue the OPCG trigger signal would not be required to reference a setup sequence (e.g. a scan chain test might never launch release or capture clocks, so it would not require a setup sequence). When test sequences are output into the set of tests to be applied by A TE, they are collected into sets that use the same clocking and will be preceded by the setup sequence that loads the OPCG programming for the set. t is important to note that it is not possible to jump to a test in the middle of a set without first applying the setup sequence that precedes the set. To make a set of effective and cost effective clocking sequence templates for use by A TPG, we analyze the internal clock domains to see how they communicate and also to note the amount of logic that is available for testing when using intra-domain clocking, inter-domain clocking or static A TPG clocking sequences. The automatic test sequence generation attempts to pulse multiple clocks in each test, using knowledge that the domains do not communicate with each other or by setting the domain input blocking control bit if it exists for a domain or by staggering the clocks with delay between them if necessary to allow for cross domain paths to settle out before continuing with more clock pulses. Paper NTERNA TONAL TEST CONFERENCE 5

6 Once the set of clocks to be pulsed is detennined, along with any control bit settings and possible delay count values, the setup sequence is also defined and paired with the test sequence. When A TPG uses the test sequence, it will automatically include the setup sequence to precede it in the output pattern set. The test sequence produced will typically look something like what is shown to the left in Figure 'T""""&:an Lo.d."...",""{ use ttlesame clocking sequence 2. Assert Trigger Signal 3. Pulse Domain Clock 4. Pulse Domain Clock 5. Wait ror logic to quiesce 6. De-assert Trigger Signal / 7. Scan Unload ATPG Test Patterns Setup Sequence Test Sequence Modeinit Sequence Test Sequence - '" Setup Sequence i'r est sequence Test Sequence -- r- Program and lock PLL Progl"8m Demllin Macro Stan LoadNnload ld generate n OPCG pulses Change ckx:king - sequencb Repeat for a diff.",nt programming of OPCG Domain Macros Figure 5. 1 Overview of generated A TPG tests t should be noted that even if we utilize the domain input blocking control for a domain, it is possible that, due to some error in implementation, not all inputs from other domains are blocked. This is verified during analysis for each domain. n spite of any such errors, we still try to utilize the domain input blocking, but simulation will use generated timing constraints from this analysis to note that if any unsafe path gets sensitized, predict X at the capture flop. f the clock domains are defined with the ability to produce 3 or more pulses each, an option is available to exploit this when generating double-pulse, intra-domain tests. The hafspeed option will insert an empty clock cycle between the first and third pulses for each domain to be double pulsed within the test sequence. This effectively provides a simple means to run some tests at half the nonnal speed of the domain. This can be useful if tests fail at functional speed. f the tests continue to fail even when run at half speed, the fails may not be due to running the domain too fast; the tests may show a hold time (short path) violation or some other problem. f the half speed tests work, the reference clock and/or PLL timing can then be played with to see at what speed they start to fail. Output from ATPG, the sequences will be arranged in order as shown in Figure The mode initialization always comes first and then a setup sequence precedes any tests that use OPCG programming. f the OPCG program bits are within the nonnal scan chains, their values will be copied from the setup sequence into the scan_load events within the every test sequence using that setup sequence. The preferred implementation uses side-scan to preload the OPCG program bits prior to the tests that use them. 6. Domain-Aware Testing for BM ASCs n this section, we describe a specific application of OPCG for contract-manufactured application-specific integrated circuits (ASCs). Each functional clock domain in the ASC is clocked by a low-skew clock fonnatter circuit, known as a deskewer, that selects between test wavefonns (e.g., 2 atspeed pulses) generated by a test wavefonn generator (TWG) in at-speed structural test (ASST) mode, and functional clock wavefonns generated by the customerdesigned clock generation logic in mission mode. The TWG and deskewer are combined into a single core that can be instantiated at the roots of clock trees during a customer's clock design phase. More details about the ASST methodology for ASC design are provided in [21]. One of the key requirements for the ASCs is to support domain-aware testing of asynchronous domains. Figure 6. 1 illustrates the problem. Three clock domains are shown colored red, yellow and blue respectively. The arcs shown represent inter-domain signal paths in the test mode. The flops within each domain can be divided into two categories. The "domain input flops" may receive data from primary inputs or other domains as well as from within the same domain. The "internal" flops only receive data from within the same domain. A robust ASC at-speed test methodology requires the ability to manage and deal with races between asynchronously communicating domains. Domain nput Flops - these flops receive data from a different domain o nternal/outout Floos - these floos onlv receive data from the same domain Figure 6. 1 Domain-aware testing 6.1 Testing asynchronous domains Two features within the OPCG domain macro described in Section 4 give A TPG the ability to deal with asynchronous domain signal transitions. First, a domain macro can be programmed to not participate in the launch/capture sequence. This gives ATPG the ability to tum-off one of two interacting domains, eliminating races between them. n the worst case, all but one domain can be shut-down and each domain can be tested one at a time in isolation. Another feature that can be used to deal with races is the delay Paper 24.3 NTERNA TONAL TEST CONFERENCE 6

7 counter. As discussed in Section 4, the delay counter can be used to pulse two interacting domains in the same test; however, with sufficient delay between the pulses to avoid any races between the two domains. These two domain macro features are sufficient to allow A TPG to generate race free tests in almost all cases. OPCG Domain Macro SCANEN t-----\ TESTMODE ----i BLKDOMAN A third approach that provides additional flexibility in dealing with asynchronous paths is to block these signals at the capture point. Figure 6.2 shows an example of logic that implements this technique. There is a special domain specific scan enable "BLKDOMAN" which is used to select the scan input instead of the functional input of a domain input capturing flop. When it is possible for a flop to capture a possibly transitioning signal from another domain, BLKDOMAN is asserted and the transitioning data is blocked. A TPG efficiency can be improved even further by the inclusion of a "toggle mux" as shown in Figure 6.2. This mux recycles the inverted value back into the flop, forcing a transition to be launched from the flop during every test. The select signal for the toggle mux is typically the global scan enable signal; however, it can be connected to a separately controlled signal (denoted Edge_Mode here) for even greater flexibility. BLKDOMAN Scan Mux (Flop) sysclock sysclock Figure 6.2 Blocking asynchronous domain crossings Each OPCG domain has its own BLKDOMAN signal that can be used to isolate flops from other domains. Typically, each flop in a domain is analyzed and the flops which are capturing paths from other domains are connected to the BLKDOMAN signal and have a toggle mux inserted. As shown in Figure 6.3, the BLKDOMAN signal is generated from within the OPCG domain macro from a new bit in the programming register. The BLKDOMAN signal is generated by logically Ring the blocking bit with the global scan enable signal. This additional blocking bit gives A TPG the flexibility to isolate a domain from receiving data from other domains. This allows the concurrent pulsing of the clocks for two interacting domains that otherwise would be timing unsafe. Figure 6.3 Generation of the BLKDOMAN signal Note, that the use of the BLKDOMAN signal and toggle mux does not introduce any additional delay along the functional paths of the chip, other than what would normally be encountered for scan. Another advantage of this technique is that it can be applied to random logic without regard to the hierarchy present. The same is not true for techniques that block inter-domain paths using wrappers, which can be used most conveniently when clock domains are separated by logical hierarchy. During a static (DC) test, there can be two passes as follows:. Test all domains, with crossings between domains blocked; 2. Test each domain (or each group of non-interacting domains) separately, with no blocking between domains. During both passes, all flip-flops receive scanned patterns using a common test clock. Pass is intended to result in the most efficient pattern set, providing maximum coverage of faults internal to domains for all domains in parallel. Pass 2 is intended to detect the remaining faults that occur in paths between domains, but in a race-free manner by only clocking one domain or a group of non-interacting domains at a time. Blocking of domain crossings occurs during Pass, and this is accomplished by feeding a separate "fencing" scan enable (called BLKDOMAN above) to those flops that capture data from other domains. During Pass, the "fencing" SE is held high not only during scan, but during test data capture as well; thus these domain-input flops safely capture from the skew-safe scan or toggle path rather than the functional path that is vulnerable to race conditions at the domain crossing. For Pass, all the clock controllers are programmed to pass along the test clock. Then, during Pass 2, the "fencing" SE, like a "normal" SE to flops internal to the domain, is active only for scan and not data capture. Thus, in Pass 2, domain crossings are not blocked, but this is race free as the clock controllers are programmed to allow only one domain or group at a time to be clocked. For non-opcg delay (AC) testing, a sequence of two clock pulses can be provided by the tester with certain timing control, and similar to DC testing as described above, Pass can be used to test transition delays within all domains in parallel. n Pass 2 an AC test is provided for the interdomain crossings. Some domains can be provisioned with a Paper NTERNA TONAL TEST CONFERENCE 7

8 secondary test clock and be unfenced. All other domains can receive the primary test clock and need to be fenced. A timed sequence of the two test clocks can be provided by the tester to create a transition delay test for all transitions going to a specific domain(s) from all other domains that interact with that domain(s). 6.3 Directed clock generation using testplans For each ASC, a testplan can be either generated automatically or customized using the list of GPCG registers on the chip. n the case of the custom testplan, these registers are organized according to the deskewer and PLL macros that contain them. The registers are programmed in the testplan with the values from a clock spreadsheet provided by the ASC customer. The clock spreadsheet lists the domains and their frequencies, which PLLs drive them, and which domains can be tested together. A testplan is made up of one or more experiments. There are two constraints on each PLL ref clock frequency in the testplan. First, the refclock frequency must be low enough so that a) scan is not run too fast, and b) the scan enable is not kept low for too many tester cycles. Scan is generally run between 2-5 MHz. The refclock frequency can be up to an 8X multiple of the tester frequency. There is one scan cycle per tester cycle. Hence, tester cycle must be between 2-5 MHz. 7. Experimental Results Experiments performed on four designs show the benefits of the proposed at-speed test methodology. Table 1 describes the designs that were used to generate these results. All the designs had high transition fault coverage requirements of around 9%. Design Table 1. Designs used for experiments Num Num Clock Max Domain Flops Domains Frequency A MHz B 22K 8 15 MHz C 172K MHz D 14K 57 16MHz Table 2 presents results for intra-domain tests showing the benefits of the side-scan approach when compared to dedicating one or more scan pins for programming the GPCG registers. For designs A and B, it was assumed that at most 5 scan-in pins could be used; 8 scan-in pins were used for design D This is a reasonable assumption given the very low pin count requirements for current designs. The last column in Table 2 shows the increase in pattern count when programming the GPCG registers via dedicated scan pin(s) as compared to using side-scan chains. Table 2. Comparing compression using side-scan chains and dedicated program chains Dedicated Program Side-scan chains Chain Pattern Design Num Num Count Scan Num Num Scan Num Num ncrease n Chains Patts n Chains Patts Pins Pins A % B % D , , % To generate results using the side-scan approach, compression was inserted into these designs using all 5 scan-in pins. For design A, four of the scan-in pins each fan out to one of the four GPCG domain macros. To generate results using a dedicated chain for GPCG programming, compression was inserted using only 4 scan-in pins. For design A, the remaining scan-in pin fed the four GPCG domain programming registers concatenated together. The number and length of internal (compressed) chains was kept the same in both scenarios. While fault coverage was the same for both scenarios, using a dedicated chain for GPCG programming results in much higher pattern count. A similar approach was taken with design B, resulting in over 3% increase in pattern count when one scan pin was dedicated to programming the GPCG registers. Design D is a low pin count ASC design originally implemented using only 2 scan-in pins. Since for the purpose of these experiments it would not be practical to dedicate one (or both!) of the two scan-ins to programming the GPCG logic, the design was re-synthesized to use 8 scan-in pins. Since this design has 57 clock domains and each domain has 6 programming bits within it (4-bit delay counter and 2-bit pulse generator), the total number of GPCG bits to be programmed is 342. This is more than the length of each internal chain, which is around 25 bits. When dedicating only one scan-in pin to load the GPCG programming bits, then each test would require more cycles to load the GPCG bits (342 cycles) compared to loading the test data into the internal chains (25 cycles). Hence two scan-in pins were used to load the GPCG registers, reducing to 171 the number of cycles required. This allowed each test to be loaded using the original number of 25 cycles. Results show a 1% increase in pattern count when dedicating 2 scan-in pins to program the GPCG logic. With the original 2 scan-in pin limit for the design, dedicating 1 scan-in pin to load a 342 bit long GPCG scan register would have led not only to ( 25%) more tests, but each test would have taken 92 ( 37%) more shift cycles for scan loads; the two increases compounding to create an over 7% increase in scan cycles. Results were also generated to illustrate the benefits of using a delay counter within the GPCG domain macros. The Paper NTERNATONAL TEST CONFERENCE 8

9 interaction between the 4 domains for design C is shown in Figure The weight of each edge is the number of gates along paths between the domains (inter-domain), and the weight of the self-loop edge is the number of gates along intra-domain paths within that domain. 11,929 D an3 E? 3286 Domain 2 Domain ,651 1,9,423 Figure 7. 1 Domain communications in design C Figure 7.2 illustrates the different clocking sequences possible for design C. Without a delay counter, the first clock sequence generated would double-pulse domain 1 only; a second sequence double-pulses domains 2, 3 & 4 simultaneously since these domains do not communicate with each other. Using a delay counter, all four domains are double-pulsed in the same clock sequence, staggering pulses of domains 2, 3, & 4 away from the double pulses of domain 1. When domain input blocking logic is present, then all the four domains can be pulsed simultaneously. With Delay Counter r cl;;.;ki g s;.q ; #; i i Domain_l ---1l11 i : Domain 2 -""1..L...--: i Domain-3 -""1..L...-- i! Domain=4 -""1.."""t--! No Delay Counter r cl.;,;ki g s ;;; ;; ;il 1 :Domainl : l r cl.;,;ki g s ;;; ;; #2 1 l Domain_2 -Ll...- l : Domain 3 -Ll...-: L ;...! With Domain Blocking i C;;.;ki g s ;; ; #; 1 i Domain_l ---1l11 i idomain2 i : Domain-3 : :Domain-4 : : : j Figure 7.2 Different clocking sequences for design C The results from test generation show that when a delay counter is used, 23.5% fewer test patterns can achieve the same fault coverage compared to when a delay counter is not used. Not only is this a significant reduction in the test data volume, the time required for test generation was also lower when using a delay counter. Table 3 shows that allowing multiple domains, even communicating ones, to be pulsed simultaneously can lead to significant reduction in pattern counts. Four separate test generation runs were done to generate intra-domain tests for design D by simultaneously pulsing a maximum of 1, 5, 1 and 15 domains respectively in each of the test generation runs. The conventional approach of pulsing one domain at a time is used as a baseline against which the other runs are compared. f P n is the number of patterns generated when n domains are pulsed simultaneously, then the percentage reduction in pattern count is calculated as ((P - Pn)/P])* 1. Results show that over 35% reduction can be easily achieved by pulsing domains simultaneously, though the benefit tapers off with higher number of domains. Table 3. Pulsing clock domains simultaneously (design D) Number of domains pulsed simultaneously % Reduction in % Reduction Pattern Count in CPU Time 1 (baseline) The OPCG logic requires minimal area overhead. For ASC design C, the OPCG logic consumed less than.5% of the total area of the design. This includes the Trigger macro and 4 OPCG macros each containing 4-bit delay counter and 2- bit pulse generator registers. Even if this design were to have about 1 independent domains, the area overhead would still be around 1 % or less. The bandwidth used to load OPCG programming registers is negligible with side-scan, as just a short scan is needed whenever the clocking sequences change. Traditionally, the registers would be reloaded on each and every test. 8. Conclusions This paper presents an On-Product Clock Generation (OPCG) methodology that enables high-speed testing and is compatible with test compression. t also enables use of tests that pulse multiple domains as well as inter-domain and static A TPG tests. Key contributions can be summarized as follows. 1. By loading OPCG programming bits independently from the normal scan chains, we avoid decompress or collisions between programming bits and A TPG care bits. t also reduces bandwidth for loading OPCG programming per test. Results for compression test modes show that using dedicated scan pins to load OPCG programming can increase the pattern count by over 15% when compared to using side-scan chains. 2. Delay counters provide a means to improve the efficiency of tests by staggering clocks that might otherwise cause timing race conditions. t also enables cross-domain testing even when the two domains are Paper NTERNA TONAL TEST CONFERENCE 9

10 asynchronous. Experimental results show up to 25% reduction in the number of intra-domain tests generated when the delay counter was used. 3. Domain input blocking allows many domains to fire simultaneously without a race condition. Our results show that pulsing multiple domains simultaneously can reduce the number of intra-domain tests by over 35% while still achieving the target fault coverage. 4. The proposed OPCG clocking can also be used for static A TPG testing. When there are large numbers of internal clock domains, they typically must share test clock primary inputs and this can cause race conditions for shared test clocks. Using the OPCG mode to create static tests avoids this problem. Future work will add support for more specialized OPCG control registers, such as clock domain gating overrides. t is important to recognize the function of each OPCG register so that test clocking sequences can be automatically generated, although custom clocking sequences will likely always be needed for special cases. 9. Acknowledgements Many people helped to generate information for this paper. We would like to thank Nitin Parimi, Nilabha Dev, Priyanka Dasgupta, Subhasish Mukherjee, Vinayak Kadam, Prashant Narang, James Sage and Paul Yuan for their help. 1. References [1] B. Bailey et a., "Test methodology for Motorola's high performance e5 core based on PowerPC instruction set architecture," Proc. EEE nt. Test Con!, 22, pp [2] T.L. McLaurin and F. Frederick., "The testability features of the MCF547 containing the 4th generation ColdFire microprocessor core," Proc. EEE nt. Test Con!, 2, pp [3] N. Tendolkar et a., "Novel techniques for achieving high at-speed transition fault test coverage for Motorola's microprocessors based on PowerPC instruction set architecture," 22, Proc. EEE VLS Test Symp., pp [4] J. Saxena et a., "Scan-based transition fault testing - mplementation and low cost test challenges," Proc. EEE nt. Test Con!, 22, pp [5] X. Liu et a., "Novel ATPG algorithms for transition Faults," Proc. European Test Workshop, 22, pp [6] Y. Shao,. Pomeranz, and S.M. Reddy. On generating high quality tests for transition faults. Proc. Asian Test Symposium, pp. 1-8, 22. [7] C. Barnhart et a., "OPMSR: The foundation for compressed A TPG vectors," Proc. EEE nt. Test Con!, 21, pp [8] V. Chickermane, B. Foutz, & B. Keller, "Channel Masking Synthesis for Efficient On-Chip Test Compression," Proc. nternational Test Conference, 24, pp [9] J. Rajski, et. a., "Embedded Deterministic Test for Low Cost Manufacturing Test", Proc. nternational Test Conference, 22, pp [1] S. Mitra, K.S. Kim, "X-Compact: An Efficient Response Compaction Technique for Test Cost Reduction", Proc. nternational Test Conference, pp , 22 [11] P. Wohl, J.A. Waicukauski, S. Patel, M. Amin, "X Tolerant Compression and Application of Scan-A TPG patterns in a BST architecture", Proc. nternational Test Conference, pp , 23 [12] V. yengar, et a, "At-Speed Structural Test For High Performance ASCs," Proc. EEE nt. Test Conference, 26, paper 2.4. [13] A. Uzzaman, et ai, "Automated handling of programmable on-product clock generation (OPCG) circuitry for delay test vector generation," Proc. EEE nt. Test Conference, 27, paper [14] K. Hatayama, M. Nakao and Y. Sato, "At-Speed Builtin Test for Logic Circuits with Multiple Clocks," Proc. EEE Asian Test Symposium, 22, pp. 18-2, 22 [15] M. Beck, et ai, "Logic Design for On-Chip Test Clock Generation - mplementation Details and mpact on Delay Test Quality," Proc. Conference on Design, Automation and Test in Europe (DATE), 25, pp [16] H. Furukawa, et.al., "A Novel and Practical Control Scheme for nter-clock At-Speed Testing," Proc. EEE nt. Test Conference, 26, paper [17] X. Fan, Y. Hu, and L.-T. Wang, "An On-Chip Test Clock Control Scheme for Multi-Clock At-Speed Testing", Proc. EEE Asian Test Symposium, 27, pp [18] B. Nadeau-Dostie, K. Takeshita, and J.-F. Cote, "Power-A ware At-Speed Scan Test Methodology for Circuits with Synchronous Clocks," Proc. EEE nt. Test Conference, 28, paper 9.3. [19] X. Lin and M. Kassab, "Test Generation for Designs with On-Chip Clock Generators", Proc. EEE Asian Test Symposium, 29, pp [2] "Clock Domain Crossing," Cadence Design Systems, wp.pdf [21] V. yengar et a., "At-Speed Structural Test for Flexible-Scan Advanced-Nanometer Designs," Proc. nternational Test Conference, 21, paper L 1.2. Paper NTERNATONAL TEST CONFERENCE 1