DFFT : Design For Functional Testability

Transcription

1 DFFT : Design For Functional Testability Haluk Konuk haluk@broadcomcom Leon Xiao leon@broadcomcom Broadcom Corporation Santa Clara, California Abstract Creating functional tests that work on an ATE has always been a significant challenge [1] This paper identifies the fundamental mechanisms for functional test failures of an SOC on an ATE Taking these mechanisms into account during the design process of a chip can substantially reduce the efforts needed to make functional tests work We call this process design for functional testability (DFFT) 10 Introduction Functional tests are an important part of the overall testing methodology of a modern SOC (System-On-Chip), which usually consists of one or more CPUs, large and several memory structures, and many logic interfaces There are many reasons why functional tests cannot be avoided even in a full-scan design in order to achieve high quality levels First, functional tests serve as a complementary test suite to stuck-at tests by significantly increasing defect coverage due to the fact that not all defects can be modeled well by the stuck-at fault model [2] Second, the activity caused inside a chip by functional tests is closer to the conditions that will be seen in its system operation, which can result in localized Vdd drops and certain cross-talk conditions, which, in turn, can stress certain propagation paths more than scan-based at-speed tests This can be particularly useful for speed testing Third, some areas of logic usually becomes untestable during scan-testing mode in order to satisfy certain design rules for ATPG (Automatic Test Pattern Generation) tools These blocks of logic can be exercised by functional tests And finally, some custom CPU designs may still not be full scan, which makes functional tests an essential part of their testing methodology [3] Traditionally, the source of functional tests have been design verification/validation tests Many recent publications [4][5][6][7][8][9][10] describe new formal methods to generate effective functional tests However, all these methods either avoid dealing with chip pins of many communication interfaces, or deal with functional test generation at high levels of abstraction, such as processor instruction level or communication protocol level The task of carrying these tests or regular design verification tests over to an Automated Test Equipment (ATE), and making them work on silicon has been an ad-hoc process, which take many iterations and quite substantial debugging efforts [1], which can significantly impact the time-to-market of a product In this paper, we present the concept of Design for Functional Testability (DFFT) to prevent costly debugging and hacking efforts traditionally performed for functional tests every time for a new chip In this paper we present ten mechanisms, which are usually responsible for functional test problems, which can be avoided if they are considered during the design process and functional test generation These ten mechanisms, which we identified based on our experience with many SOC designs, form the major components of DFFT The reader must keep in mind that it is very difficult to perform functional testing with a completely systematic methodology, which can be done in scan-based testing However, this paper makes an attempt to provide a structure to functional testing Finally, there is no guarantee that the ten failure mechanisms we present here are the only ones, even though we consider them to be the most important ones based on our experience 20 Test Generation Environment Figure 1 illustrates the most commonly used functional test generation flow in the semiconductor design industry today The main idea is to capture the simulation waveforms at the chip pins, including the internal signals that control the directionality of bi-directional pins These waveforms are then converted to ATE files Converting tester files back to Verilog or VHDL stimuli, and re-simulating them again on the chip model, as shown by the dotted arrows in Figure 1, is also utilized to debug functional tests Vector-based design verification uses the RTL (Register Transfer Level) model of the SOC Functional test gen-

2 eration can also use the RTL model, especially when dealing with a large SOC, and many functional tests need to be generated Even though gate-level simulation may identify problems with functional tests earlier, it may not always be feasible to use gate-level simulation especially for very large designs with substantial dependence on functional testing Such a design can easily have over 50 million transistors Design Verification Test or Custom Test this input is unknown, the multiplexer output state will be either A or B depending the actual value of condition If state becomes A, a mismatch will occur on the ATE, because RTL simulation expected state to be B rather than A Since the actual silicon behavior might be different from that of the RTL model, this problem is not only a functional test issue but also a design verification issue The following are some of the approaches used in industry to address this issue: RTL or Gate-level Simulation Simulation Waveforms at Chip Pins Re-simulation Verilog or VHDL Stimulus Files HDL Description if (condition) state <= A; else state <= B; When condition is X during Verilog simulation, state becomes B Conversion Software Convert to Verilog or VHDL condition ATE Files Figure 1: Functional test generation flow 30 Components of DFFT This section describes various mechanisms responsible for functional test problems on an ATE, which we identified based on many SOC designs The design process of an SOC and its associated functional tests need to take these mechanisms into account to replace the adhoc methods in use today for functional test generation 31 Conditional Statements Conditional statements in Hardware Description Languages (HDL s) are one source of problem when it comes to making functional tests work on an ATE The problem arises when the condition expression(s) of a conditional statement evaluate(s) to X, in which case the default clause or the else clause gets executed Consider the example shown in Figure 2 When a functional test executes the if statement in Verilog simulation with condition being X, the else clause will be chosen, which will make state equal to B When this if statement is implemented with a multiplexer in silicon, its select input will be tied to condition When Silicon A B state However, in silicon when condition is X(unknown), state will become either A or B, which can cause a mismatch on the ATE Figure 2: Mismatch caused by conditional statements 1 Use only 0 and 1 values during RTL simulation; never use X or Z Convert unknown states into random 0 s and 1s This technique might work for design verification purposes; however, it will not automatically solve the mismatches on the ATE, because the 0 s and 1 s randomly generated by the RTL simulator for unknown states will not match the silicon behavior 2 Do not use any conditional statement in the RTL code This will definitely solve the problem; but, the designers will be deprived of a powerful HDL construct, which will make the design entry difficult 3 Perform gate-level simulation or re-simulation, as shown in Figure 1, of as many functional tests as possible to find the tests that suffer from this prob-

3 lem early on, and modify the tests to prevent conditions from being X A tool will be ideal to check for this issue comprehensively Even though some commercially available tools claim to catch this kind of problem, gate-level simulation of a few tests is probably the safest way 32 Forced Initializations Many state-holding elements in a chip design do not need to be initialized for the chip to function correctly As a result, RTL simulations may start with many internal nodes at X value When these X s propagate to certain portions of the design that are monitored during simulation, they might confuse the monitoring agents, and cause simulation to die For example, when a data value containing X s is written into an on-chip memory with ECC (Error Checking and Correction) feature, these ECC bits will become X, as well Since an X on an ECC bit might mean a serious design problem, simulation in the design verification environment will terminate the simulation with an ECC error, even though the X in this case might be due to the don t care initial conditions For this reason, such initial X states usually need to be forced to either fixed or random binary (0 or 1) values during RTL simulation Verilog constructs to watch in the RTL code, for example, which may be used for such forced initalizations are $random and synopsys translate_off, which may appear in the RTL code as follows: // synopsys translate_off if (reset) begin state_1 <= $random(seed); end // synopsys translate_on The // synopsys translate_off line is just a comment for Verilog simulation, but the Synopsys synthesis tool interprets this to ignore all code until the // synopsys translate_on line is encountered With this code, in the RTL simulation, state_1 will start with random 0 s and 1 s when the chip is reset, rather than starting with X values However, the value of state_1 in the actual silicon will most likely not match the random numbers used in the RTL simulation, which can easily cause a mismatch for this functional test on the ATE, while this mismatch might be a don t care condition for the operation of the chip in its intended system environment This problem can be addressed as follows: 1 Search for $random and translate_off strings in the source RTL code, and analyze them Or, do not allow them in the RTL code, at all, if possible 2 As in Section 31, perform gate-level simulation of as many functional tests as possible to find the tests that suffer from this problem 33 Clock Domain Crossings It is almost impossible today to find an SOC that has only one clock domain in it Communication across clock domains can be a source of problem for functional tests on the ATE, if it is not explicitly considered The clock signal for a particular domain may be supplied externally through a chip pin, or it may be generated internally inside a chip by a Phase-Lock-Loop (PLL), for instance The following subsections analyze the three cases based on the clock source for two communicating clock domains 331 Both External Clocks This case is illustrated in Figure 3, where externally supplied clocks are used for clock domains d1 and d2 Let s assume that the RTL or gate-level simulation waveforms for the clock signals at the clock ports of the flip-flops and are as shown in Figure 4 Clock edge a makes latch its input data coming from other flipflops of domain d1, and edge b makes latch its input data coming from Note that the separation between edges a and b is pretty small in the simulation waveforms This separation might be a few hundred picoseconds if domain d2 runs, for instance, at 500MHz The propagation delays through the d1 and d2 clock trees in the actual silicon will have variations due to the manufacturing process, temperature, and Vdd variations Therefore, in a particular manufactured part, the ordering of the events a and b can be easily reversed due to these variations, if the simulation waveforms have these events very close to each other, as shown in Figure 4 When this happens, will latch in the data before latches it, which will cause a mismatch on the ATE for this functional test Note that correct system operation of the chip may not depend on the exact ordering of events a and b if the communication between domain d1 and d2 is designed to be asynchronous In this case, only the functional tests will be sensitive to this problem as specific chip response is expected at every cycle on the ATE, which is determined from simulation results

4 Since clocks for both domains come directly from chip pins as shown in Figure 3, the ATE can be instructed to keep moving the clk_d2 signal in very small time steps to the left until the functional tests start passing on the ATE The process of changing a chip-pin timing or any other parameter on the ATE automatically in very small steps is called shmooing Note that if the frequency of one clock domain is not an integer multiple of the frequency of the other clock domain, it might be very difficult to guarantee a large enough separation between the rising edges of these two clock signals during simulation In this case, a more careful analysis is necessary, which may require a change in the frequency of one clock domain so that it is an integer multiple of the other (chip pin) (chip pin) clk_d1 C o m b clk_d2 clk@(simulation) clk@(simulation) a b d1_clock tree clk@ L o g i c d2_clock tree clk@ clk@(silicon) clk@(silicon) a b Event order kept Figure 3: Clock domains with external clocks Figure 5: Waveforms indicating a pass on the ATE clk@(simulation) b 332 Both Internal Clocks clk@(simulation) clk@(silicon) clk@(silicon) a b a Event order reversed!!! Clock signals for the two clock domains may be both generated inside a chip from a common source, such as a PLL, as shown in Figure 6 Different frequencies can be achieved by dividing the PLL output using different clock dividers In this case, moving the PLL input ref_clk to the left or to the right in time on the ATE will have no effect on the phase relationship between the clock signals arriving at the flip-flops in Figure 6, since the clock signals of both domains will move together the same amount Figure 4: Simulation and silicon waveforms indicating a potential problem on the ATE When a functional test fails on the ATE, there can be many potential reasons to check, and many different signals to shmoo on the ATE to debug this problem In order to minimize the complexity of this task, it is best to generate functional vectors as robust as possible For this reason, simulation waveforms should have the rising (active) clock edges of two communicating clock domains separated as much as possible from each other, as illustrated in Figure 5, where the order of events a and b are the same both in simulation and in silicon As a result, if rising clock edges switch their order in some manufactured parts, as explained in the preceding subsection, it is not possible to fix this problem by shmooing the ref_clk signal on the ATE, any more However, by manipulating the timing of the reset_d1 and reset_d2 signals, which reset the clock dividers in Figure 6, we can achieve a safe and deterministic communication between the clock domains on the ATE

5 reset_d1 divide by M clk_d1 d1_clock tree clk@ PLL ref_clk C o m b L o g i c divide by N clk_d2 d2_clock tree clk@ reset_d2 PLL_clk reset_d1 reset_d2 clk@ clk@ Clock dividers are reset Rising edges line up Danger!!! Figure 7: Waveforms indicating a potential problem on the ATE Figure 6: Clock domains with internal clocks Figure 7 shows one case of simulation waveforms for a functional test, which might fail on the ATE Resetting of a clock divider in Figure 7 means that a rising edge happens at the clock divider output one PLL_clk cycle after the reset signal goes high Note that both domain d1 and domain d2 clock dividers are reset at the same time in the simulation waveforms of Figure 7 As a result, the rising edges of clk@ and clk@ line up or get very close to each other depending on the clock tree delays used in simulation for the d1 and d2 clock trees This creates a big risk for this functional test on the ATE, as described in the preceding subsection Flip-flop may latch its input first followed by in Figure 6 during simulation, but the order can change in silicon due to manufacturing process variations, because the two events are very close to each other in the simulation waveforms When the order changes, the functional test will fail on the ATE One solution to this problem is illustrated in Figure 8, where the two clock dividers are reset one PLL_clk cycle apart This way, we make sure that the rising edges of the two clock signals are separated by one PLL_clk cycle in the simulation waveforms, which can be enough separation to guarantee the same order of events on the ATE If the clock signals of the two clock domains are generated by two independent PLLs with their own input reference clocks, the problem becomes similar to the one described in the preceding subsection, because the two reference clocks can be independently controlled via two different chip pins PLL_clk reset_d1 reset_d2 clk@ clk@ div by M is reset div by N is reset Figure 8: Waveforms indicating a pass on the ATE 333 One Internal and One External Clock As with the preceding two cases, the goal here is again to separate the rising (active) clock edges of the two clock domains The techniques in the preceding two subsections, namely, controlling clock timing via the chip pins and via resetting of clock dividers can both be applied to achieve this goal 34 Bi-Directional Chip Pins Rising edges are now separated 341 Minimum Distance from a Strobe Edge to a Drive Edge When an ATE is programmed to strobe a chip pin at time point t1, the ATE is smart enough to take the propagation delay τ between the chip pin and the tester electronics into account Thus, the comparator on the ATE side, shown in Figure 9, actually samples its input at time t1+τ This is shown with the ES (Effective Strobe)

6 edge in Figure 9 Similarly, when an ATE is programmed to start driving a chip pin at time point t2, the ATE driver shown in Figure 9 actually starts driving at t2-τ to compensate the effect of the propagation delay τ This is shown with the ED (Effective Drive) edge in Figure 9 As a result of this behavior, one can easily that if (t2-τ) is smaller than (t1+τ), the ATE driver will turn on before the comparator samples its input And, when the comparator samples its input, it will sample the value the ATE driver is driving, not the chip pin was driving This will cause a mis-match on the ATE, because the chip pin might be driving a zero while the ATE might instructed to drive a one Therefore, functional tests must satisfy the following timing constraint for a bidirectional chip pin: (t2 - τ) > (t1 + τ) => (t2 - t1) > 2 * τ ATE pin electronics driver propagation delay τ These two edges should not cross over comparator chippin As a result, the transition started at may not reach on time, causing a set-up violation at The result of this incorrect value read by will be observed on the chip outputs at later cycles of the functional test ATE Load Chip in_en out_en Figure 10a: An internal path going through a chip pin ATE Load Chip I1 in_en out_en Figure 10b: Internal path logically broken by I1 Strobe ES ED Drive τ t1 t1+τ t2-τ t2 τ time Chip out_en Figure 9: Strobe-to-Drive must be separated at least 2τ ATE Load M1 342 Tester Load The load an ATE presents to a chip pin is sometimes larger than the load the chip-pin is expected to drive in its functional system environment While a bi-directional chip pin is driving the ATE during a functional test, if the value on this chip pin is also used by the internal logic of the chip, then a mis-match may happen on the ATE during the following cycles of this functional test Consider the example in Figure 10a If the out_en and the in_en signals both become high during a functional test, the path from flip-flop to flip-flop might be slowed down by the ATE load, if the chip pin is expected to drive a smaller load on the system board in_en A1 Figure 10c: Internal path isolated from the chip pin One solution to this problem is shown in Figure 10b If the chip is designed such that the in_en and the out_en signals can be mutually exclusive, then adding the inverter I1 in Figure 10b will guarantee that these two signals do not become high at the same time, thus preventing a transition from propagating from to For the case where in_en and out_en cannot be mutually exclusive, another design solution is shown in Figure 10c The added AND gate A1 detects when both in_en

7 and out_en become high, and selects the upper input of the added multiplexer M1, thus preventing the transition originated at from being exposed to the ATE load 343 Stop-Driving Edge Section 341 discussed the case for a bi-directional chip pin changing its direction from output to input, or an ATE channel changing its function from strobe to drive during a functional test When the direction of a pin changes from input to output, on the other hand, ATE needs to be instructed at what time point it should stop driving the pin before it samples the voltage at that pin by a strobe edge The time point for ATE to stop driving is called the stop-driving edge Proper placement of this edge is also critical to the correct operation of functional tests on an ATE ATE pin electronics clk out_en Drive Chip T1 in_en It is almost impossible to find an SOC today without at least one PLL (Phase Lock Loop) on it PLLs are usuout_en Stop- Driving Figure 11 illustrates the stop-driving edge with an example The clk signal is assumed to be a chip pin There are basically two timing constraints the stop-driving edge needs to satisfy: 1 The time difference between the rising edge of clk and the stop-driving edge for this bi-di pin, which is shown as T1 in Figure 11, must be equal to or greater than the hold time specification for this pin 2 The time difference between the stop-driving edge and the next rising edge of clk, which is shown as T2 in Figure 11, must be large enough to allow the path T2 Strobe Figure 11: The Stop-Driving edge on an ATE clk FF3 clk clk time from the bi-di pin to flip-flop to stabilize before captures its input This constraint assumes that the in_en can be high together with out_en, and the ATE drive strength is much larger than the bi-di pin s drive strength, which is usually the case 35 Chip Pin Timing on the ATE 351 Input Direction The software tool used to convert the simulation waveforms into tester files will determine the logic value for each pin for every tester cycle When a pin is in input mode for a given tester cycle, the logic value determined for that cycle needs to be applied by the ATE to the chip pin The exact time point within the tester cycle at which the ATE starts driving this value, in other words, the ATE drive edge needs to satisfy the setup time constraint for this pin In addition, this drive edge also needs to satisfy the hold time constraint for this pin in case the previous cycle is also input mode If these setup and hold time values are given in the hardware data sheet of the chip, then they can be directly used to specify the ATE input timing for every chip pin If the setup and hold times are not specified for a pin group, because these pins receive asynchronous data in their system operation, then timing analysis can be used to calculate the setup and hold times based on the actual flip-flops inside the chip, which are capturing the incoming data Note that even though asynchronous communication between two clock domains, or between external data and the chip can be supported during the system mode, the chip needs to behave synchronously on the ATE due to the fact that every tester cycle is expecting specific data from the chip, and a slip of even one cycle will cause mis-matches on the ATE 352 Output Direction The electrical load each chip pin is exposed to on the ATE is quite difficult to characterize accurately due to the fact that the physical medium between a chip pin and the ATE pin electronics has several different components, such as the test board traces, cable connections to the pin electronics, wafer probes, etc For this reason, it is best to come up with the exact placement of the strobe edges on the ATE using shmooing as described in Section PLL Output Determinism

8 ally used to generate high-frequency internal clocks by multiplying low speed external clock inputs Figure 12 shows a PLL that is used to clock the embedded processors, memories and logic of an SOC When the chip is first powered on, the PLL requires a certain amount of time before it locks, and its output becomes stable During this lock time, the chip needs to be held at reset state After the PLL locks, the phase of its output clock needs to be deterministic with respect to the phase of its input clock for functional tests to run properly on an ATE This is because the PLL output is clocking many major blocks in the SOC, and an ATE can only control the PLL input For instance, in Figure 12, when the Reset pin is de-asserted after the PLL locks on the ATE during a functional test, flip-flop FF-1 clocked by the PLL output detects this de-assertion edge, and informs the rest of the chip to start running Therefore, it is critical that FF-1 detects the Reset de-assertion on the ATE at the same cycle as the simulation waveforms indicate so that the chip starts running at the exact clk cycle as the functional tests expect it to Otherwise, mismatches can happen later on during the functional test Thus, functional tests need to satisfy the setup and hold times at flip-flop FF-1, which means that the phase of the PLL output needs to be deterministic If the PLL output has a random phase, every time it locks, with respect to its input, then we cannot guarantee that the ATE timing for the PLL input will satisfy the FF-1 setup and hold times In a modern complex SOC, there are several logic blocks, as shown in Figure 12, used to implement different high-speed communication protocols, such as HyperTransport [11], GigaBit Ethernet, PCI-X, Memory Controller, etc Each such block usually has its own external clock signal(s) provided through chip pins, as illustrated by Ext_clk1 and Ext_clk2 in Figure 12 These clock domains need to communicate with the embedded processors(s) that are clocked by a PLL output As discussed in Section 33, this communication needs to be synchronous and cycle-by-cycle deterministic on the ATE for functional tests to work properly Therefore, the PLL output phase needs to be deterministic to satisfy this requirement Figure 13 illustrates the basic blocks of a typical PLL [12] The phase frequency detector block makes sure that its two inputs are phase and frequency aligned That is, the clock divider output div_out becomes identical to PLL input signal in, when the PLL locks The difference between these two signals becomes negligible on the ATE, because the ATE can provide a pretty tightly controlled power supply to the PLL In order to guarantee that the PLL output phase is always the same every time the PLL locks, the delay through the clock divider T needs to remain the same d_1_0 d_1_m Ext_clk1 d_2_0 d_2_n Ext_clk2 PLL_in_clk Reset Interface Logic-1 Interface Logic-2 PLL clk Embedded Processors, Memories, and Logic reset FF-1 Figure 12: Mixture of PLL and external clocks in an SOC in PLL in div_out out phase frequency detector div_out clock divider voltage controlled oscillator out T T needs to be the same every time PLL locks Figure 13: PLL output phase needs to be deterministic 37 Deterministic Reset of Clock Dividers A modern complex SOC usually has several clock dividers to drive different clock domains with programmable frequencies Each such divider may take the output of a PLL, and generate various lower frequencies When the chip starts running with the de-assertion of the Reset pin, as explained in the preceding Section, all the

9 clock dividers need to be reset a deterministic number of clock cycles after the Reset de-assertion occurs Otherwise, the phases of the clock divider outputs will be unknown with respect to the phases of the PLL inputs, which can result in mis-matches on the ATE for functional tests This may not be a problem for system operation of the chip, because many clock domains do not need to be synchronized to each other due to the fact that they use a handshaking mechanism to communicate with each other However, functional tests may fail, because the ATE will be expecting a specific chip output at every clock cycle 38 Chip Pin Speeds and ATE Memory ATEs [13][14] usually have a master clock, which advances the tester cycle on all the pins synchronously The period of a tester cycle is programmable, and multiple Drive and Strobe edges can be placed within one tester cycle with a limit on the maximum number of edges depending on the particular ATE Even tough edge placement can be done per-pin basis, it is often required that the same edge placement is used for all the tester cycles for the same pin These ATE constraints imply that the pins with the highest frequency clock or data rate determine the length of the tester period for a functional test, and the clock and data periods of all other chip pins need to be integer multiples of the highest frequency pin period These constraints need to be taken into account during functional test generation and even during the design of the chip itself For instance, the main chip PLL might be bypassed for some functional tests, such that the main chip clock is driven from chip pins If a slightly time shifted version of the main clock, such as a quarter period shifted clock, is also needed within the chip, the PLL could be easily designed to provide this, and in PLL-bypass mode a clock divider together with some additional logic can generate this shifted clock phase However, the chip pin, P1, providing the clock signal in PLL-bypass mode needs to run at a higher frequency than the main chip clock, because a clock divider is used to generate the shifted clock phase In this case, P1 is the highest frequency chip pin during the functional test On the other hand, if another chip pin, P2, is used to directly provide the shifted clock phase from ATE rather than using an internal clock divider, the frequencies on P1 and P2 will be the same as the main clock frequency This will result in fewer number of transitions on P1 and P2 during the functional test, which will result in using less ATE memory Since ATE memory is a limited resource, using less memory per test allows us to put more tests on the ATE, which increases the defect coverage of the SOC The main idea here is to make the clock and data speeds on the chip pins as balanced as possible in order to utilize the tester memory as efficiently as possible Another example might be to use a large PLL multiplier value during a functional test, which uses PLL, to generate the main chip clock This way, the PLL input coming from a chip pin will have a lower frequency while maintaining the main clock frequency at-speed This can also save tester memory if all other chip pins run at the same or lower frequencies than the PLL input clock 39 Internal Loopback If a particular communication interface of an SOC, as illustrated in Figure 12, is too fast to be sampled on the particular ATE being used, internal loopback may be designed into that interface, as shown in Figure 14 The main idea here is to capture the output data, which is shown by Tx_data in Figure 14, as the input data to the interface In this internal loopback mode, the ATE does not need to provide data to the Rx_data pin, and it does not need to sample the Tx_data pin Note that even though this is similar to the I/O wrap technique [15][16], the internal loopback mode here can be used during the functional testing of the chip without using the boundary scan If the Rx_clk is also bypassed by looping-back the transmit clock to drive the receiving flip-flop FF-1, as shown in Figure 14, data and clock arrival times at FF-1 in loopback mode need to be verified with timing analysis to make sure that they satisfy the setup and hold time constraints of FF-1 Otherwise, functional tests using internal loopback mode may fail due to violation of these constraints at FF-1 loopback FF-1 clock loopback data-loopback Rx_data Rx_clk Tx_data Figure 14: Timing analysis should be performed with both data and clock loopbacks turned on

10 310 Test Exits Based on Internal States Design verification patterns might declare a pass or a fail for a particular test as a result of observing only internal signals, rather than waiting for proper values to propagate to chip pins This can be useful in the verification environment by decreasing simulation time; however, it obviously creates a problem for functional tests where a defective chip can pass on ATE because the test is terminated before faulty values appear on the chip pins The way verification tests are terminated should be well understood in order to avoid this problem 40 Conclusion In this paper we introduced the concept of design for functional testability by describing various mechanisms that are usually responsible for functional test problems on an ATE By taking these mechanisms into account during the design process and functional test generation, these tests can have a smooth transition to an ATE rather than spending lengthy debugging efforts using ad-hoc techniques to make them work on an ATE References [1] PC Maxwell, I Hartanto, L Bentz; Comparing Functional and Structural Tests, International Test Conference, 2000 [2] PC Maxwell, RC Aitken; Test Sets and Reject Rates: All Fault Coverages are not Created Equal, IEEE Design & Test of Computers, March 1993, pages: [3] C Stolicny, R Davies, P McKernan, T Truong; Manufacturing Pattern Development for the Alpha Microprocessor, International Test Conference, 1997 [4] Li Chen, S Dey; Software-Based Self-Testing Methodology for Processor Cores, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, March 2001, pages: [5] RS Tupuri, A Krishnamachary, JA Abraham; Test Generation for Gigahertz Processors Using an Automatic Functional Constraint Extractor, Design Automation Conference, 1999 [6] K Jayaraman, VM Vedula, JA Abraham; Native Mode Functional Self-Test Generation for Systems-on-Chip, International Symposium on Quality Electronic Design, 2002 [7] JShen, JAbraham; Native Mode Functional Test Generation for Processors with Applications to Self-Test and Design Validation, International Test Conference, 1998 [8] NA Touba, B Pouya; Testing Embedded Cores Using Partial Isolation Rings, IEEE VLSI Test Symposium, 1997 [9] C A Papachristou, F Martin, M Nourani, Microprocessor Based Testing for Core-Based System on Chip, Design Automation Conference, 1999 [10] N Kranitis, A Paschalis, D Gizopoulos, Y Zorian, Effective Software Self-Test Methodology for Processor Cores, Design, Automation and Test in Europe Conference and Exhibition, 2002 [11] HyperTransport TM Technology I/O Link: A High Bandwidth I/O Architecture, Advanced Micro Devices, Inc, 2001 [12] RE Best, Phase-Locked Loops: Design, Simulation, and Applications, McGraw-Hill Professional; 4th edition, 1999 [13] Technical Specifications, Agilent SOC Series P-model, Agilent Technologies 2001 [14] Technical Specifications, J973 VLSI Test System, Teradyne Inc, [15] RW Bassett et al Low-Cost Testing of High- Density Logic Components, IEEE Design and Test of Computers, April 1990 [16] S Oakland, J Monzel, R Bassett, P Gillis; An ASIC Foundry View of Design and Test, International Test Conference 1991