283 Digital Logic Testing and Simulation , Second Edition , by Alexander Miczo ISBN 0-471-43995-9 Copyright © 2003 John Wiley & Sons, Inc. CHAPTER 6 Automatic Test Equipment 6.1 INTRODUCTION Digital circuits have always been designed to operate beyond the point where they could be reliably manufactured on a consistent basis. It is a simple matter of eco- nomics: By pushing the state of the art—that is, aggressively shrinking feature sizes, then testing them and discarding those that are defective—it is possible to obtain greater numbers of ICs from a single wafer than if they are manufactured with more conservative feature sizes (cf. Section 1.8 for more discussion on this practice). This strategy depends on having access to complex, and sometimes very expen- sive, test equipment. This strategy also depends on being able to amortize tester cost over many hundreds of thousands, or millions, of ICs. As ICs become more complex, running at faster clock speeds, with greater numbers of I/O pins, requirements on the tester become greater. More pins must be driven and monitored. Tolerances grow increasingly tighter, and there is less margin for error. Clock skew and jitter must be controlled more tightly, and the increasing amount of logic, running at ever higher clock speeds, requires the ability to switch greater amounts of current in less time. Early testers were quite simple: Input pins were driven by stimuli stored in memory. After some predetermined clock cycle the output pins were strobed and their responses compared to expected responses (cf. Figure 6.1). Many early testers were designed and manufactured by end users, particularly mainframe vendors. With time, however, and the increasing complexity of the ICs and PCBs being tested, it became prohibitively expensive to design and build these testers. Compa- nies were formed for the explicit purpose of designing and building complex testers and, although these testers were quite expensive, it was nevertheless more economi- cal to buy than to build in-house. Over the years, many tester architectures and test strategies have evolved in order to locate defects in ICs and PCBs and provide the highest possible quality of delivered goods at the lowest possible price.This chapter provides a very brief over- view of some of the more important highlights and concepts involved in applying test stimuli to digital circuits and monitoring their response. Space does not permit a 284 AUTOMATIC TEST EQUIPMENT Figure 6.1 Basic test configuration. more thorough investigation of the many tester architectures and strategies that have been devised to test digital devices during design debug and manufacturing test. 6.2 BASIC TESTER ARCHITECTURES Functional testers apply stimuli to input pins of a device-under-test (DUT) and sample the response at output pins after sufficient time has elapsed to permit signals to propagate and settle out. The tester then compares sampled response to expected response in order to determine whether the DUT responded correctly to applied stimuli. Depending on their capabilities, these testers can be used to test for correct function, characterize and debug initial parts, and perform speed binning. 6.2.1 The Static Tester Functional testers can be characterized as static or dynamic. A static tester , such as the one depicted in Figure 6.1, applies all signals simultaneously and samples all output pins at the end of the clock period. Device response is compared to the expected response and, if they do not match, the controlling computer is given relevant information such as the vector number and the pin or pins at which the mismatch was detected. The static tester does not attempt to accurately measure when events occur. Therefore, if a signal responds correctly but has excessive propa- gation delay along one or more signal paths, that fact may not be detected by the static tester. These testers are primarily used for go–nogo production testing. A general-purpose tester must have enough pins to drive the inputs and to monitor the outputs of the DUT. In fact, in order to be general purpose, the tester must have enough pins to drive and sample the I/Os of the largest DUT that might be tested by that tester. Furthermore, since it is not known how many of the I/Os on the DUT are inputs, and how many are outputs, it must be possible to configure each of the tester pins as an input or as an output. If a device has more pins than the tester, it may be possible to extend the capabilities of the tester through the use of clever techniques such as driving two or more inputs from a single tester channel and/or multiplexing IC output pins to a single tester channel where they may be sampled in sequence. DUT s t i m u l i CPU r e s p o n s e e x p e c t Pass/Fail Test pgm BASIC TESTER ARCHITECTURES 285 When considering a tester for purchase, its maximum operating speed may be an important consideration, depending on the purpose for which it is being purchased. But other factors, including accuracy, resolution, and sensitivity, must be given equal weight. 1 Accuracy is a measure of the amount of uncertainty in a measure- ment. For example, if a voltmeter is rated at an accuracy of ±0.1% and measures 5.0 V, the true voltage may lie anywhere between 4.95 V and 5.05 V. Resolution refers to the degree to which a change can be observed. Referring again to the volt- meter, if it is a digital voltmeter, its resolution is expressed as a number of bits. How- ever, the last few bits may not be meaningful if measurements are being taken in a noisy environment. If the noise is random and there is a need for greater resolution, samples can be averaged. This is done at the expense of sampling rate. Sensitivity describes the smallest absolute amount of change that can be detected by a measurement. For the voltmeter, sensitivity might be expressed in millivolts or microvolts. Note that these three factors do not necessarily depend on one another. A device may have high resolution or high sensitivity but may not necessarily meet accuracy requirements for a particular application. Moreover, a device may have high sensitivity, but its ability to measure small signal changes may be limited by other devices in the test setup such as the cables used to make the measurements. Tester programming is another important consideration. Test programs that are used to control testers are normally created on general-purpose computers. They may be derived from design verification vectors, from an ATPG, or from vectors specifically written to exercise all or part of a design in order to uncover manufactur- ing defects. When the developer is satisfied that the test program is adequate, it is ported to the tester. The tester will have facilities similar to those found on a general-purpose com- puter, including tape drives, a modem and/or network card, and storage facilities such as a hard drive. These facilities allow the tester to read a final test program that exists in ASCII form and compile it into an appropriate form for eventual execution on the tester. Other facilities supported by the computer include the ability to debug tester programs on the tester. This may include features such as printing out failing response from the DUT, altering input values or expect values, masking failing pins and switching mode from stop on first failure to stop after n failures, for some arbi- trary n . When the compiled program is needed, it is retrieved from hard disk. The part of the test program that defines input stimuli and expected response is directed to pin memory . Behind each channel on the tester there is a certain amount of pin memory capable of storing the stimuli and response for that particular channel. The goal is to have enough memory behind each tester channel to store an entire test sequence. However, testers may allow pin memory to be reloaded with additional stimuli and response from the hard drive. When refreshing pin memory, each memory load may require an initialization sequence, particularly if the DUT contains dynamic parts. Some parts may also run very hot, and the additional time on the tester, waiting for pin memory to be updated, may introduce reliability problems for the part. Many of the pins on a typical DUT may be bidirectional pins, acting sometimes as inputs and sometimes as outputs. Therefore, on a general-purpose tester, it must 286 AUTOMATIC TEST EQUIPMENT be possible to dynamically change the function of the pins so that during execution of a test a tester channel may sometimes drive the pin that it is connected to, and sometimes sample that same pin. This and other pieces of information must be pro- vided in the test program developed by the test engineer. Other information that must be provided includes information such as voltage and current limits. A subse- quent section will examine a tester language designed to configure tester channels and control the tester. 6.2.2 The Dynamic Tester It is increasingly common for ICs to be designed to operate in applications where, in order to operate correctly with other ICs mounted on a complex PCB, they must adhere closely to propagation times listed in their data sheets. In such applications, excessive delays can be a serious problem. Isolating problems on a PCB caused by excessive propagation delays is especially difficult when all the ICs have passed functional test and are assumed to be working correctly. It is also possible that cor- rect behavior of an IC involves outputting short-lived pulses that are present only briefly but are nevertheless necessary in order to trigger events in other ICs. These situations, excessive delay and appearance of pulses at output pins, are not handled well by static testers. Other challenges to static testers include application of tests to devices such as dynamic MOS parts that have minimum operating frequencies. To exercise devices at the clock frequency for which they were designed to oper- ate, to schedule input changes in the correct order, and to detect timing problems and pulses, the dynamic tester is employed. It is also sometimes called a high-speed functional tester or a clock rate tester . It can be programmed to apply input signals and sample outputs at any time in a clock cycle. It is more complex than the static tester since considerably more electronics is required. Whereas many functions in the static tester are controlled by software, in the dynamic tester they must be built into hardware in order to provide resolution in the picosecond range. The dynamic tester solves some problems, but in doing so it introduces others. Whereas the static tester employs low slew rates (the rate at which the tester changes signal values at the circuit inputs), the dynamic tester must employ high slew rates to avoid introducing timing errors. However, high slew rates increase the risk of overshoot, ringing, and crosstalk. 2 Programming the tester also requires more effort on the part of the test engineer, who must now be concerned not only with the signal values on the circuit being tested but also with the time at which they occur. The task is further complicated by the fact that these timings are also dynamic, being able to change on a vector-by-vector basis, as different functions inside the IC control or influence the signal directions and logic values on the I/O pins. The architecture of a dynamic tester is illustrated in Figure 6.2. 3 The test pattern source is the same set of patterns that are used by the static tester. However, they are now controlled by timing generators and wave formatters. The test patterns are initially loaded into pin memory and specify the logic value of the stimulus or the expected response. The remaining circuits specify when the stimulus is to be applied or when the response is to be sampled. The system is controlled by a master clock BASIC TESTER ARCHITECTURES 287 Figure 6.2 Architecture of shared-resource tester. that determines the overall operating frequency of the board and controls a number of timing generators. Each of the timing generators employs delay elements and other pulse-shaping electronics to generate a waveform with programmable place- ment of leading and trailing edges. The placement of these edges is determined by the user and can be specified to within a few picoseconds, depending on the accu- racy of the tester. The number of timing generators used in a functional tester depends on whether it is a shared resource or tester-per-pin architecture. A shared resource tester (Figure 6.2) contains fewer timing generators than pins and employs a switching matrix to distribute the timing signal to tester pins, whereas the tester-per-pin archi- tecture (Figure 6.3) employs a timing generator for each tester pin. Programming the shared resource tester requires finding signals that have common timing and con- necting them to the same tester channel so that they can share wave formatters and pin electronics. The switching matrix in the shared resource tester can contribute to skewing problems, so eliminating the switching matrix makes it easier to deskew and thus improve the accuracy of the tester. 4 Another factor that makes the tester- per-pin more accurate is the fact that there is always one fixed-length signal path to the DUT, so the timing can be calibrated for that one path. Figure 6.3 Architecture of tester-per-pin tester. Master clock DUT Timing generators N × M Switching matrix Wave formatters Pin electronics Master clock DUT Timing generators Wave formatters Pin electronics 288 AUTOMATIC TEST EQUIPMENT The programming of a tester for a given DUT requires a file containing logic stimulus values to be applied and expected values at the DUT outputs. However, other files are required, including a pin map and a file with detailed instructions as to how the waveforms are to be shaped by the pin electronics. The pin map identifies the connectivity between the tester and the DUT. The input stimuli and the expected output responses are stored in tester memory in some particular order. For example, pins 1 through 8 of the DUT may be an eight-bit data path. Furthermore, this data path may be bidirectional. When the pins on the DUT are connected to channels on the tester, it is important that the 8-bit data path on the DUT be associated with the eight channels that are driving or sampling that data path. 6.3 THE STANDARD TEST INTERFACE LANGUAGE Tester programming languages have tended to be proprietary. Because testers from different companies emphasize different capabilities, it was argued that proprietary languages were needed to fully and effectively take advantage of all of the unique features of a given tester. A major problem with this strategy was that if a semicon- ductor company owned testers from two or more tester companies, test program portability presented a major problem. If the company wanted to use both of these testers to test a device in a production environment, its engineering staff had to have experts knowledgeable in the test languages provided by each of these testers. For a small company, this could be a major drain on assets, and a single-test engineer might find it difficult to keep up with all the nuances, as well as changes, revisions, and so on, for multiple-test programming languages. The Standard Test Interface Language (STIL) was designed to provide a common programming language that would let test engineers write a test program once and port it to any tester. It has been approved by the Institute of Electrical and Electronic Engineers (IEEE) as IEEE-P1450. 5 Its goal is to be “tester independent.” 6 This is achieved by having the language represent data in terms of its intent rather than in terms of a specific tester. 7 Thus, it is left to the tester companies to leverage to full advantage all of the features of their particular testers, given a test program written in STIL. STIL provides support for definition of input stimuli and expected response data for test programs. But it also provides mechanisms for defining clocks, timing infor- mation, and design-for-test (DFT) capabilities in support of scan-based testing. One of its capabilities is a ‘UserKeywords’ statement that supports extensibility by allowing the user to add keywords to the language. STIL was initiated as a tool for describing test programs for testers, but its flexibility and potential have made it attractive as a tool for defining input to simulation and ATPG tools. It also offers an opportunity to reduce the number of data bases. Rather than have several data bases to capture and hold data and results from different phases of the design, test, and manufacturing process, STIL offers an opportunity to consolidate these data bases with a potential not only to reduce the proliferation of files, but also to reduce the number of opportunities for errors to creep into the process. Already there is a THE STANDARD TEST INTERFACE LANGUAGE 289 growing interest in adding enhancements to facilitate the use of STIL in areas where it was not originally intended to be used. 8 An example of usage of STIL is presented here to illustrate its use. The circuit will be an 8-bit register with inputs D 0 – D 7 and outputs Q 0 – Q 7 . It will have an asynchronous, active low clear, an active-high output OE, and a clock with active positive edge. When OE is low, the output of the register floats to Z. Example STIL 0.0; // 8-bit Reg. with clock and clear Signals { CLK In; CLR In; OE In; D0 In; D1 In; D2 In; D3 In; D4 In; D5 In; D6; In; D7 In; Q0 Out; Q1 Out; Q2 Out; Q3 Out; Q4 Out; Q5 Out; Q6 Out; Q7 Out; } SignalGroups { INBUS ‘D0 + D1 + D2 + D3 + D4 + D5 + D6 + D7’; OUTBUS ‘Q0 + Q1 + Q2 + Q3 + Q4 + Q5 + Q6 + Q7’; ALL ‘CLK + CLR + OE + INBUS + OUTBUS’; } Spec timingspec { Category prop_time { tplh { Min ‘2.00ns’; Typ ‘3.00ns’; Max ‘4.00ns’; } tphl { Min ‘2.00ns’; Typ ‘3.00ns’; Max ‘4.00ns’; } tpzl { Min ‘5.25ns’; Typ ‘6.00ns’; Max ‘7.00ns’; } tpzh { Min ‘4.50ns’; Typ ‘5.50ns’; Max ‘6.50ns’; } tplz { Min ‘3.45ns’; Typ ‘4.20ns’; Max ‘5.75ns’; } tphz { Min ‘3.45ns’; Typ ‘4.20ns’; Max ‘5.75ns’; } strobe_width ‘3.00ns’; } } Selector typical_mode { tplh Typ; tphl Typ; tpzl Typ; tpzh Typ; tplz Typ; tphz Typ; 290 AUTOMATIC TEST EQUIPMENT } Timing timing_info { WaveformTable first_group { Period ‘50ns’: Waveforms { CLR { 0 { ‘0ns’ ForceDown; }} CLR { 1 { ‘0ns’ ForceUp; }} OE { 01 { ‘0ns’ ForceDown/ForceUp; }} CLK { 01 { ‘0ns’ ForceDown/ForceUp; CLK_edge: ‘25ns’ ForceUp/Forcedown; }} INBUS { 01 { ‘0ns’ ForceDown/ForceUp; }} OUTBUS { L { ‘0ns’ X; ‘CLK_edge+tpzl’ l; ‘@+strobe_width’ X;} H { ‘0ns’ X; ‘CLK_edge+tpzh’ h; ‘@+strobe_width’ X;} D { ‘0ns’ X; ‘CLK_edge+tplz’ t; ‘@+strobe_width’ X;} U { ‘0ns’ X; ‘CLK_edge+tpzh’ t; ‘@+strobe_width’ X;} F { ‘0ns’ X; ‘CLK_edge+tphl’ l; ‘@+strobe_width’ X;} R { ‘0ns’ X; ‘CLK_edge+tplh’ h; ‘@+strobe_width’ X;} X { ‘0ns’ X; } } } // end Waveforms } // end WaveformTable first_group } // end Timing PatternBurst stimuli { PatList { exercise_part; } } PatternExec { Timing timing_info; Selector typical_mode; Category prop_time; PatternBurst stimuli; } // end PatternExec Pattern exercise_part { W first_group; // first vector must define states on all signals V { ALL=00000000000XXXXXXXX; } // clear the reg’s, // don’t measure V { CLR=1; OUTBUS=XXXXXXXX; } // release the clear, // don’t measure V { ALL=01100000000LLLLLLLL; } // outputs enabled THE STANDARD TEST INTERFACE LANGUAGE 291 V { CLK=0; INBUS=FF; OUTBUS=RRRRRRRR; } // all switching // to high V { INBUS=55; OUTBUS=FHFHFHFH; } // some switch to low } // end patterns The first line in an STIL program identifies the STIL version. That is followed by a comment. Comments in STIL follow the format employed in the C programming language. A pair of slashes (//) identify a comment that extends to the end of a line. Comments spanning several lines are demarcated by /* . */. Immediately following the comment is a block that identifies the I/O signals used in the design. Each signal in the design is identified as an In, Out, or InOut. Signals may be grouped for convenience, using the SignalGroups block. The inputs D0 through D7 to the individual flip-flops of the 8-bit register are grouped and assigned the name INBUS. In similar fashion the outputs of the 8-bit register are grouped and given the name OUTBUS. Then, the entire set of input and output signals are grouped and assigned the name ALL. These groupings prove convenient later when defining vectors. The Spec block defines specification variables. The Spec block is assigned a name, but it is for convenience only; the name is not used in any subsequent refer- ence. In this example a Category is defined and assigned the name prop_time. Several categories can be defined and used at different places in the test program. Six of the variables in category prop_time are propagation delays that will be used later when defining the WaveformTable. The names of the Spec entries are arbitrary and, in fact, any number of entries could be used in the Spec block. For example, a user may have a legitimate reason to define unique propagation times from X to Z, 0, and 1. Three values, a minimum, typical, and maximum, are assigned to each of the six variables in the Spec block. A seventh variable called strobe_width has one value that defines the duration of a strobe measurement on an output. The Selector block determines which of the Spec values to use. There are four possibilities: Min, Typ, Max, or Meas. Meas values are determined and assigned during test execution time; they are not explicitly specified in the Spec information. The Timing block follows the Selector block. It is given the name timing_info. It contains definitions for one or more WaveformTables. In the example presented here there is just one WaveformTable, and it is assigned the name first_group. The first statement assigns a period of 50 ns to all the test vectors that use first_group. Then, some Waveforms are defined. The first one is for CLR, the clear signal. The number 0 follows the signal name CLR. It is called a WaveformChar, abbreviated WFC. Although any character may be used to represent the waveform following the WFC, it is good practice to use a character that has some recognizable meaning because the WFC will be used in the ensuing vectors. A signal may have several waveforms, but each one must have a different WFC. In STIL a waveform is a series of time/event pairs. In the waveform for CLR the keyword ForceDown follows the time 0 ns. So, at time 0 a ForceDown event occurs; CLR is driven low if it had previously been at a high value. If a signal is in the off (Z) state, it is turned on and driven low. Notice that in the example given above, 292 AUTOMATIC TEST EQUIPMENT there are two waveforms for CLR that have identical timing, so they could actually be merged. However, they were kept separate for illustrative purposes. Merging is illustrated by the waveform for the output enable OE. At 0 ns OE could switch to either 0 or to 1. Therefore a single WFC 01 represents this time/ event pair, and both possibilities are described on that one line. The first entry, ForceDown, corresponds to WFC 0. The second entry, following the slash, corre- sponds to WFC 1. The character string 01 is called a WFC_LIST. The next waveform defines the behavior for CLK. Like OE, the CLK signal uses a WFC_LIST. One new thing to note here is the introduction of an event_label defi- nition called CLK_edge. Labels defined in this way are scoped to the Wave- formTable in which they are defined. The label is useful in relating subsequent events to the clock edge. The CLK waveform is followed by a waveform for INBUS. It also has a rather simple waveform. However, one distinction here lies in the fact that the waveform applies to all the signals D0 through D7. The last entry in the WaveformTable is for OUTBUS. Recall that it is the set of outputs Q0 through Q7. There are seven entries for OUTBUS, and each has its own WFC. The first entry for OUTBUS has an L as its WFC. At time 0 ns the tester is told to look for an X on the output. This is simply a way to tell the tester not to mea- sure at this time. Then, at time CLK_edge + tpzl the tester is told to expect l (the let- ter l ), which is a compare logic low window. In the CLK waveform CLK_edge was defined to occur at 25 ns. So, the tester should start monitoring the OUTBUS at 25 ns + tpzl. Since Typ values were selected by the Selector, and the Typ value for tpzl was defined to be 6.00 ns, the tester should start monitoring at 31.00 ns. The next field begins with the @ symbol. The @ symbol is used to refer to present time, which was defined to be CLK_edge + tpzl in the previous field. So @+strobe_width is 31.00 ns + 3.00 ns, meaning that the tester should continue to monitor OUTBUS until 34.00 ns. Each of the first six entries for OUTBUS corresponds to one of the six entries in the Spec block. The seventh entry is for those vectors where the output is unknown, and the tester is instructed not to strobe. The letters l , h , and t are called events and indicate a window strobe. The letter t is used when the response is supposed to be high imped- ance during the entire strobe window. Several other events are defined in P1450. The PatternBurst block, with the name “stimuli,” specifies a list of patterns that are executed in a single execution. The example contains one PatList called “exercise_part.” There could be several pattern lists, with the user choosing different sets of patterns for different runs. One of the pattern lists could be a common initial- ization sequence that several designers or test engineers use to ensure consistency across several test programs. The PatternExec follows the PatternBurst block; it con- tains the commands that pull together all the information needed to perform a test run. The PatternBurst entry is required, the other three entries are optional. If there are multiple entries for Category, Selector, or Timing, then the entry is required in the PatternExec block to avoid ambiguity. In the example above, these blocks only had single entries, so they could have been omitted. It might, however, be good cod- ing practice to include them as reminders for possible expansion of the test program in the future. [...]... fails to operate correctly at any frequency, then it is logical to assume that there is either a physical failure that occurred during the manufacturing process or a design error If several parts are available and if all of them fail in an identical fashion, then the logical assumption is that there is a design error that occurred during either the logic design process or the physical design process USING... to 30 ns 0 ns 50 ns 100 ns 150 ns TG1 PD1 PW1 TG2 PD2 PW2 Figure 6.6 Nonreturn and return-to-one waveforms 200 ns 296 AUTOMATIC TEST EQUIPMENT Pin data PD1 and PD2 are identical; a logic 1 in pin memory is followed by a logic 0, another 1, and then a 0 However, because the timing generators are different and the waveform formats chosen are different, the resulting pin waveforms PW1 and PW2 are very... signals on the board under test When test plans are written using symbolic names, these symbolic names will be linked to corresponding channel numbers It is also necessary to define voltage levels for logic 1 and logic 0, as well as voltage ranges or tolerances, since these values will vary depending on the technology used In addition, they may vary if it is required that a board be tested at operating margins... tester have knowledge of each physically accessible IC pin and test points, including their physical location and the expected logic values for each input vector applied As with edge pins, the tester may require information defining the probe voltage levels corresponding to logic 1 and 0 A circuit interconnection file is necessary if a guided probe is used to trace error signals from an output pin back... that the incorrect response occurred on the vector with the shrunken cycle Recall from Chapter 2, where simulation was discussed, that typically only a small percentage of elements in a circuit exhibit logic activity on any given vector So, knowing on which vector the error occurred can significantly reduce the scope of the search for the problem In fact, this knowledge, along with information obtained... search down to just a few critical signal paths At that point an E-beam can help to further isolate the problem or confirm suspicions as to what path is causing the failure Armed with this knowledge, the logic designer can approach the redesign effort with greater confidence that the next iteration will be successful The stretch-and-shrink test in Figure 6.7 is referred to as the ripple technique Other... to put the device into a state that permits the desired measurements to be made A functional program may be run until arriving at a desired output state Then the measurement is taken Alternatively, a logic designer or test engineer may write a program whose sole purpose is to drive the circuit into the desired state For an output leakage test, it is necessary to put the circuit into a state in which... location on the die and the waveform at that point is constructed by strobing while the die is clocked through a number of states This mode of operation is quite similar to that of an oscilloscope or logic analyzer In the image mode a picture of the complete die, or some designated part of the die, is constructed by scanning an area of interest By repeating this operation, several images can be obtained... correct The e-beam system is not intended to be used as a production tester It is slow compared to a conventional tester and may need several hours to acquire enough information to diagnose a problem The logic states provided by the e-beam at the top-level interconnects may not be sufficient to diagnose problems; analog waveforms at components underneath the top level may also be required To analyze a die... these values to construct a waveform corresponding to the voltage at that point on the die In fact, waveforms corresponding to several (x, y) positions can be created and displayed simultaneously in a logic analyzer format This kind of integrated design debug system may become routine as more and more complete systems are integrated onto single pieces of silicon 6.6 MANUFACTURING TEST To this point . AUTOMATIC TEST EQUIPMENT Pin data PD 1 and PD 2 are identical; a logic 1 in pin memory is followed by a logic 0, another 1, and then a 0. However, because the timing. in an identical fashion, then the logical assumption is that there is a design error that occurred during either the logic design process or the physical