A manufacturing-oriented digital stimulus/response test instrument - VXIbus mainframe computers, VMEbus Extensions for Instrumentation - Technical

This digital functional tester consists of pattern I/O, timing, and command modules configured in a VXIbus mainframe. The maximum pattern rate is 20 MHz and pin-to-pin skew is less than 6 ns.

Test engineers and system integrators have used analog instrumentation for years in their automated functional test systems. Until now, however, there has been little in the way of cost-effective, manufacturing-oriented digital instrumentation with which to round out their toolkits. The HP 75000 Model D20 was created to fill this void. The decade of the 1980s saw an explosive increase in the amount of digital circuitry used in all manner of electronic assemblies. Today, an estimated 80% of all circuit boards are manufactured with substantial digital content. In the 1990s, the use of digital circuitry will continue to increase, as will the use of advanced packaging such as fine-pitch surface mount technology (SMT) and multichip modules (MCMs). Also, the proliferation of open architectures will require testing to rigid specifications. The effect of these developments will be a greater emphasis on digital functional testing in future manufacturing schemes.

Functional testing involves the transfer of information to and from the device under test (DUT). A stimulus is sent to the DUT to evoke some response, which is then analyzed to deten-nine if the DUT is operating correctly. If the stimulus and response are digital, then it is a digital functional test. If some part of the stimulus or response is not digital (i.e., analog or mechanical), then it can be said to be a mixed-signal test. In functional testing, the stimulus application and response measurement are generally performed through the assembly's edge connectors; connections to internal nodes are kept to a minimum.

The uses for functional testing can vary considerably. Some manufacturers use it simply to verify connections from connector pins to internal components. Others use it to exercise the functions of their assemblies in go/no-go tests. Still others develop complex fault isolation and diagnostic tests to pinpoint failed components within their assemblies. Regardless of test complexity, there is a need for digital instrumentation that can be integrated with analog instruments like voltmeters and counters.

A General Model for Digital Interfaces

Digital interfaces come in myriad forms. There are standard backplanes (like VXIbus) and proprietary backplanes specific to certain products. There are also nonbackplane interfaces, both standard (like SCSI) and proprietary. However different, all digital interfaces share certain characteristics which can be exploited when designing a digital stimulus/response instrument. The signals of the interface fall into two major categories. First, all but a few of the lines are dedicated to carrying information to or from the DUT. These include the data and address buses on a computer backplane, for example, and will be called pattern lines here. Second, there are a few signals, the control and handshake lines, which facilitate the information transfers on the pattern lines. Control signals are created by the tester to regulate the transfer process; strobes and clocks are typical examples. In many interfaces, the DUT responds to control signals with a handshake signal to acknowledge a data transfer or to modify the rate of transfer.

Let's define some terms. A cycle is the sequence of events necessary to transfer one bit to or from the DUT on each of the interface's pattern lines. A particular interface specification may define more than one type of cycle-read and write, for instance. The specification of a cycle's pattern data along with that cycle's type forms a vector. An ordered list of vectors is a called a sequence. A complete test consists of the execution of one or more sequences.

As an example, consider a data transfer cycle on the VME (or VXI) bus. Suppose that the tester is acting in the bus master role, writing data to the DUT (Fig. 1a). At the beginning of the cycle, the tester places valid information on the address (A01-A31), address modifier (AMO-AM5), long word(LWORD*) and interrupt acknowledge (IACK*) lines. After allowing for propagation delay and settling time, the address strobe AS*) is asserted. Also, near the beginning of the cycle, WRITE- is asserted and the data to be written is put on the data bus (D00-D31). This is followed, again after a suitable delay, by the assertion of one or both of the data strobes (DSO*, DS1*). It is now up to the DUT to acknowledge the data transfer by asserting DTACK*, after which the tester will negate the address and data strobes, then wait for the DUT to negate DTACK*. When DTACK* goes false, the cycle is complete and another cycle can begin.

A read cycle (Fig. 1b) is similar, except that the tester negates WRITE* and tristates (doesn't drive) the data bus. Instead, when the data strobes are asserted, the DUT puts its response data on the data bus and asserts DTACK*. The tester then accepts the response and negates the data strobes, causing the DUT to tristate the data bus and negate DTACK*, completing the read cycle.

In this example, the address, address modifier, and data buses are identified as pattern lines. The address and data strobes are control signals and OTACK* is a handshake line. LWORD*, IACK*, and WRITE* could be treated as pattern lines but are really control-like in nature since they serve to define the type of cycle.

Some observations about the two categories of signals are in order here, beginning with pattern lines. First, pattern lines each assume a single value in each cycle; they make at most one transition per cycle. Second, pattern lines are most often collected into sets that have common functions and timing. These sets are called buses and usually contain multiples of eight pattern lines. There might be a 16-bit data bus or a 24-bit address bus, for example. A third observation is that some, but usually not all, pattern lines may be bidirectional. That is, they may carry information first one way and then the other during the course of the test. Data buses, for example, are typically bidirectional but address buses are generally not.

The few control and handshake lines in an interface differ from the pattern lines in a number of ways. First, they are single lines, not contained within buses. (Sometimes an interface will have what is called a control bus, which is really a collection of individual control and handshake signals, not the same as a pattern bus). Another difference is that these lines usually make more than one transition in each cycle. In the VMEbus example above, the data and address strobes, as well as OTACK,, are first asserted, then negated, thereby making two transitions in each cycle. There can be many repetitions of a clock signal in a cycle. A third difference is that control and handshake lines are unidirectional, not bidirectional. Finally, for a given cycle type, the control and handshake lines have the same behavior regardless of the information on the pattern lines.

Handshaking can be either synchronous or asynchronous. If there is no explicit clock signal in the interface, it is an asynchronous handshake. The VME and VXI buses employ this type. On the other hand, if there is a clock signal in the interface, then handshake and control transitions must usually be synchronized to the clock transitions, creating the synchronous variety. An example of this is when a device requests a wait state in a personal computer. When there is a clock signal in the interface, it can be generated either by the tester or by the DUT. In the latter case, the tester must be able to synchronize itself with the DUT-supplied clock, and this forms a type of handshake as well.

Model D20 Requirements

To be useful, a digital stimulus/response instrument must be capable of emulating the DUT's interfaces. Its application to manufacturing testing imposes other requirements, including high test quality and throughput, ease and flexibility of integration and use, and low downtime. Achieving high test quality places several demands on the instrument's timing capabilities. The tester must first of all be capable of exercising the DUT at full speed. Also, timing relationships at the DUT must closely resemble those defined by the interface specification. This means that the tester must have good resolution and accuracy for edge placement and cycle duration. Since different types of cycles may have different durations or different timing relationships between the various signals, the tester must be capable of changing timing on the fly. Finally, since there may have to be a substantial length of cable between the VXIbus mainframe and the DUT, there must be some means of compensating for the resultant cable propagation delays.

Good signal fidelity is another requirement for high test quality. A tester must deliver clean stimulus waveforms to the DUT and not be difficult for the DUT to drive cleanly. Maximizing test throughput requires not only that devices be tested at full speed, but that time spent transferring information between the test controller and the tester be minimized. The amount of data that must be transferred must be small, and the transfer rate must be high. Fixturing is an important aspect of production testing, so a variety of methods of connection to the DUT must be accommodated. In some cases it is possible to put the DUT close to the instrument, but in others there may be one or two meters of cable separating them. There may also be a mass interconnect device involved, such as the HP 9420A or E3722A interface connector assemblies. When doing mixed-signal testing, the digital instrument must be synchronized with analog instrumentation. Flexible trigger input/output capability is therefore needed.

Functional test systems use a variety of instrument controller platforms: personal computers, UNIX* workstations, and HP BASIC workstations, to name a few. To be compatible with all controllers, a digital instrument should have an ASCII command language like the other instruments in the system. SCPI (Standard Commands for Programmable Instruments, a superset of IEEE 488.2) command format is preferred. There should also be efficient non-ASCII options for transferring large volumes of pattern data.

Finally, reducing downtime requires a reliable instrument with built-in self-test, to identify failed modules quickly. Replacing a module must not require time-consuming recalibration to meet specifications.

Model D20 Architecture

With an eye to the above requirements, the IIP 75000 Model D20 design team investigated various digital stimulus/response instrument architectures. We looked at a number of existing products as well as several new proposals. What follows is a discussion of the architecture that emerged from our investigation and the decisions that shaped it.

The fact that interface signals fall into two categories (pattern and control/handshake) suggested a similar division of roles in the Model D20. We therefore created pattern I/O modules (HP E1451A and E1452A) for patterns and a timing module (HP E1450A) for control signals and handshaking.

The timing module generates eight control signals and performs both synchronous and asynchronous handshaking with the DUT It also accepts and generates triggers for synchronization with other instrumentation, and it provides timing information to the pattern I/O modules in the form of twelve pattern clocks on the VXIbus local bus.

Each pattern I/O module has thirty-two channels, arranged as four eight-bit ports. Ports are independent of one another and can be programmed for stimulus output or response input. The two types of pattern I/O modules are identical except that the HP E1451A passes pattern clocks on to the next mainframe slot and the HP E1452A terminates them.

A Model D20 system is configured as shown in Fig. 2. The HP E1450A timing module is placed farthest to the left, followed by a number of IIP E1451A pattern I/O modules. One HP E1452A terminating pattern I/O module completes the instrument.

A single timing module can service up to ten pattern I/O modules, a full mainframe. Furthermore, up to three timing modules can be linked in a master/slave arrangement, allowing up to thirty pattern I/O modules to be included in the instrument. The timing module is optional when an external clock source is available. As a result, instruments with from 32 to 960 pattern lines and from 0 to 24 control lines can be assembled.

The pattern I/O and timing modules can interface directly to the DUT, but in case the DUT must be some distance from the mainframe, pods are provided. A pod contains active circuitry at the end of a two-meter cable. It buffers and reconstructs stimulus waveforms, eliminating any distortions a length of cable might cause, and gives a lower output impedance than a cable would. It also buffers responses from the DUT, providing high-impedance inputs which are, easier to drive cleanly than long cables. The HP E1454A pattern I/O pod buffers sixteen bits of pattern data; two pods are used with each pattern I/O module. The HP E1453A timing pod buffers the control and handshake signals associated with the timing module. The HP E1456A and E1455A pods are electrically identical to the HP E1454A and E1453A, respectively, but are mechanically different to allow them to be mounted in the HP 9420A and E3722A interface connector assemblies.

Given this basic architecture for the Model D20, attention was turned to the question of message-based versus register-based programming interfaces. Message-based interfaces simplify instrument programming and provide for controller independence. Since they employ onboard processors, they allow built-in self-test for quick identification of failures. Sophisticated message-based interfaces can, however, slow data transfer rates, limiting throughput. They require significant amounts of board space, and in the case of the Model D20, where there is not one module guaranteed to be a part of the instrument, each module would be required to have one. This would raise the cost significantly.

Register-based interfaces, on the other hand, provide direct control of the hardware and maximum data transfer rates. They are less expensive and take less board space. Programming register-based modules as complex as the Model D20's can be a daunting task, however. Fortunately, recent versions of the HP E1405 command module, with their downloadable firmware capability, provide a single place from which to control multiple register-based modules with an SCPI command language. This approach was taken with the Model D20, realizing the benefits of a message-based interface while still allowing fast, unrestricted register-based operation. Maximum pattern rate is a key specification for a digital instrument, and many standard and proprietary interfaces were examined to determine how fast the Model D20 should run. The VME and VXI buses have a maximum pattern rate of 10 MHz. Personal computers, while having clock rates of 25 MHz or more, have pattern rates of 12.5 MHz or less. Most other interfaces have speeds of the same order. It became apparent, then, that an instrument capable of 20-MHz pattern rates would be viable, provided it could produce control signals at up to 40 MHz. Picking 20 MHz as a maximum pattern rate meant that much of the Model D20's circuitry could be implemented with off-the-shelf CMOS technology. The low power of CMOS places low demands on the mainframe power supply and cooling system and minimizes failure rates. Using commonly available technology minimized both the time to market and the cost.

Since the vast majority of digital devices have either TTL or CMOS interface levels, the Model D20 needs to be compatible with both. To this end, all outputs swing to CMOS levels (ground to +5 volts), allowing the instrument to drive either TTL or CMOS DUT inputs. Conversely, all inputs have 1.5-volt typical thresholds, allowing them to be driven by either TTL or CMOS DUT outputs.

Pattern I/O Modules

Realizing that most of the pattern signals in a DUT interface can be collected into buses that have multiples of eight lines led to the concept of the pattern I/O port. A port is a self-contained, independent, eight-bit I/O structure with a single clock to control its timing. Each pattern I/O module contains four ports. Compared with so-called "per-pin" architectures, this "per-byte" approach reduces cost considerably without seriously limiting flexibility in real applications.

As shown in Fig. 3, each port consists of an address counter, a pattern and control memory, input and output stages, clock selection and delay circuitry, and a comparator. At the beginning of a sequence, the address counter is preset. It then increments for each cycle (vector) of that sequence. The memory has 65,536 (64K) twelve-bit words. Eight bits of each word are used for pattern data while the remaining four provide cycle-by-cycle control for the port,. The output and input stages provide the interface to the DUT (if there is no pod) or to the pod cable. The clock for each port can be one of the pattern clock signals from the timing module or an external clock signal. Since there is only one pattern value associated with each vector, a single clock edge per cycle provides all the timing information a port needs. Pattern clocks are subjected to a variable delay for the purposes of deskew and cable-length compensation, to be described below. A port can be programmed to perform one of three different tasks, with its memory assuming a different role for each. The first mode of operation is stimulus, in which the eight pattern bits of each memory word are sent through the output stage to the DUT. In this mode, one of the control bits provides cycle-by-cycle tristate control for the whole port-, when tristated, outputs assume a high-impedance state-neither high nor low. An additional input to the output stage allows external tristate control.

The second mode is record, in which eight bits of response pattern data are sampled by the input stage and written into the memory in each cycle. Finally, there is a compare mode, which brings the comparator section into play. In this mode, eight bits of expected response data from the memory are compared with the eight bits of actual response from the DUT. Another control bit enables this comparison on a cycle-by-cycle basis, and there is a static mask register that allows any bits to be declared "don't care". When a comparison fails, the port stops, thus preserving the memory address of the first failure and both the expected and the actual responses. One of the remaining two control bits is used to indicate the end of a sequence, causing the port to stop. The last is a branch bit used to implement a diagnostic looping feature by forcing the address counter to load a nonsequential address from a branch destination register (not shown in Fig. 3).

There is a high degree of flexibility in this port concept. Multiple ports with duplicate programming and the same pattern clock can form pin groups corresponding to the DUT's buses. IEEE 488.2, the basis for SCPI, restricts integer data to thirty-two bits or less, thereby limiting firmware support for pin groups to no more than four ports. Larger buses can be emulated by duplicating the programming for more than one pin group. Ports can be programmatically reassigned to different pin groups as necessary to test different devices.

Bidirectional buses can be tested by connecting a stimulus pin group in parallel with a response pin group. An advantage of this approach is that the two pin groups are otherwise independent, allowing complete flexibility in timing and making cable-delay compensation possible.

Another advantage is that the resources to implement bidirectional buses need only be purchased for those pattern lines that are bidirectional, and not necessarily for all.

Paralleling pin groups creates other possibilities, as well. Responses can be simultaneously recorded and compared, for example. Also, multiple stimulus or response pin groups can be combined, to double, triple, or even quadruple the Model D20's pattern rate and memory depth.

Compare mode and deep memory increase test throughput by reducing the amount of information that must flow between the instrument and the controller for each device tested. Compare mode does this by eliminating the need to move what could be millions of bits of response data into the controller for go/no-go analysis after each sequence. It is only necessary to interrogate two registers in each response port. Of those ports indicating a comparison error, the one with the lowest memory address identifies the first failure. Deep memory allows a long sequence or multiple shorter ones to reside in the Model D20. This reduces the incidence of reloads during testing.

Timing Module

The HP E1450A timing module accepts a number of inputs from the DTTT and/or other instrumentation and produces control outputs to the DUT and pattern clocks to the pattern I/O modules. It also generates triggers for other instruments. Its overall block diagram is shown in Fig. 4.

The timing module's inputs include triggers from various sources, two READY lines for synchronous handshaking, and ten lines (Q0-Q9) that are used mainly for asynchronous handshaking and trigger qualification. All of these inputs must be synchronized with the internal 160-MHz oscillator, and all the timing modules in the instrument must "see" the inputs at the same time. For this reason, the timing module is divided into master and slave sections, which are linked by an external cable. A timing module becomes a slave by having its slave section connected to the master section of another timing module.

Master Section

As Mg. 4 shows, the master section accepts inputs, processes them, and synchronizes them with the internal oscillator. The two READY lines, one from a front-panel connector and one from the pod, are ANDed together, then sent to the slaves after being synchronized. Lines Q0-G9 become variables in four user-defined Boolean expressions. These lines address a fast memory that has been filled with the truth tables of the expressions (labeled "Boolean Expression Evaluators" in Fig. 4), and the results appear on four condition lines. Three of the conditions (CONDO, CONDI, and COND2) are for general handshaking and synchronization, and are sent to the slaves, while the fourth (COND3) becomes a trigger qualifier. Available trigger sources include the eight TTL and two ECL VXIbus trigger buses on the backplane, an input on the timing pod, and both TTL-Ievel and ECI-level front-panel connectors. Positive or negative slopes can be selected for the pod and front-panel trigger inputs but slopes for the VXIbus trigger buses are fixed by the VXIbus standard. Trigger qualification is done by sampling the state of COND3 when the selected edge from the selected source occurs, If COND3 is true, then the trigger event is recognized, but it is not passed on to the slaves until after a programmable delay. This trigger delay is provided by a sixteen-bit counter, giving a range of zero to (2 C' - 1) x 6.25 ns (almost 409.6 [micro-s]). READY, CONDO, CONDI, COND2, the qualified and delayed trigger, and the oscillator signal appear at three front-panel connectors, from which they drive the slave sections via master/slave cables.

Slave Section

While the master section deals with inputs to the timing module, the slave section is concerned with the module's outputs, namely control signals, pattern clocks, and triggers. Recall that control signals are generally higher-speed than patterns, with possibly many transitions per cycle. They are essentially arbitrary digital waveforms. Pattern clocks (which provide timing information to the pattern I/O modules via the VXIbus local bus) and trigger pulses can be thought of and created ill the same way. Therefore, the timing module has three similar timing generators: one to create marker (trigger output) pulses and six stimulus pattern clocks, one for six response pattern clocks, and one for the eight control signals. To accomplish system deskew and pod/cable delay compensation (discussed later), the three timing generators need to operate in different time frames and therefore must be separate. These timing generators, along with a prescaler, a sequencer, several control state machines, and some cable-length compensation and deskew circuits, make up the timing module's slave section.

Fig. 5 shows the slave section in more detail. The stimulus, response, and control timing generators are all similar, consisting of a ten-bit address counter, 1024 words of memory, an output register, and a little random logic. At the beginning of each cycle, the address counter loads a new value, then begins incrementing through successive memory addresses. The memory data is clocked through the output register, creating waveforms. Cycles are defined by putting appropriate data into a range of memory locations, each corresponding to what is termed a subcycle. Many cycles can be defined at the same time, as long as the sum of all of the subcycle locations does not exceed the size of the memory. Oscillator frequency determines the timing resolution of the instrument, and should therefore be as high as possible. However, memory access time and logic delays limit the maximum oscillator frequency. Sticking to the policy of using relatively inexpensive, readily available parts, a 160-MHz oscillator is used, for a best-case resolution of 6.25 ns. This number is an even divisor of 50 ns (the pattern I/O ports' minimum cycle time) and provides adequate resolution in most cases.

The control timing generator's memory is eight bits wide, each bit corresponding to a control signal output. Similarly, the response timing generator's memory is six bits wide, one per response pattern clock signal. The stimulus timing generator has twelve-bit words, however. Six bits are for stimulus pattern clocks and the rest are for the ECI, marker pulse, for testing the three conditions from the master section, and for both conditional and unconditional end-of-cycle definition.

Two synchronous bits control each timing generator. The four resulting operations are next subcycle, next cycle, hold, and inhibit. The next subcycle operation causes the address counter to increment and the new memory data to be clocked out on the next oscillator cycle. The next cycle operation is similar, except that instead of incrementing, the address counter loads the first address of another cycle. The hold operation freezes the address counter but allows the output register to update its contents. Finally, the inhibit operation causes the oscillator to be completely ignored; nothing changes state. The prescaler is a programmable sixteen-bit, divide-by-N counter which causes the timing generators to hold for N - 1 out of every N oscillator cycles. This lengthens each subcycle and changes the Model D20's timing resolution to N x 6.25 ns. The maximum subcycle duration is 216 x 6.25 ns (409.6 rts).

At the end of each cycle, a next cycle operation occurs. The timing generator address counters are loaded with an address determined by the sequencer. This sequencer makes the Model D20's on-the-fly timing changes possible by either causing the same cycle to be repeated or switching to a different cycle. The sequencer functions like a pattern I/O port configured for stimulus operation, except that its memory contains eight-bit tags instead of pattern data, and its four control bits have different functions. The sequencer is clocked once, furnishing one tag per cycle. Starting addresses in the timing generator memories are formed by multiplying the tags by four (left-shifting them two places). Three of the four remaining bits permit cycle-by-cycle control of trigger arming, marker (trigger output) pulse generation, and breakpoints. The last bit designates the end of the sequence.

State Machines

As can be seen in Fig. 5, the control logic section provides control of the timing generators through the actions of several state machines. The outputs of the run/stop, trigger, condition, and EOC/SEGCLK state machines are combined with the prescaler's output (PCLK) into the two timing generator control bits. The EOC/SEOCLK state machine monitors the near-end-of-cycle (NEOC) bit from the stimulus timing generator memory to determine when the end of the cycle is at hand. It causes another cycle to begin by initiating a next cycle operation in the last oscillator period of the current cycle. It also issues a clock pulse to the sequencer to make the next tag and control bits available.

An end-if-ready (EIR) bit in the stimulus timing generator memory works like NEOC, except that it is ANDed with the READY line from the master section. If the DUT is indicating that it is ready for the next cycle to begin when EIR is encountered, the cycle is terminated in a manner similar to when NEOC occurs.

An example will show how this end-if-ready feature forms the basis for synchronous handshaking. Suppose that the DUT is a device that requires a continuous clock input (to be provided by a Model D20 control output) and that it can request wait states, which must lengthen a cycle by whole clock periods, up to some maximum number. This is typical of a personal computer card. The Model D20 cycles would then be programmed to be the maximum length allowed, but an EIR would be placed at the point where a cycle normally ends and at whole DUT clock periods thereafter. If the DUT is not requesting a wait state, it drives READY true, and the cycle terminates at the first EIR. If, on the other hand, the DUT needs a wait state, it makes READY false, causing the cycle to go past the EIR. The cycle will then terminate at a subsequent EIR, once READY goes true, or at the end of the cycle as defined by NEOC. Placing EIRs at DUT clock period intervals ensures that the tester will always generate DUT clocks with the proper period.

For each of the condition lines from the master section there are a corresponding state machine and control bit from the stimulus timing generator memory. When a control bit is true, the associated state machine tests its condition at the end of that subcycle. If the condition is false, the timing generators and prescaler are inhibited, and all activity stops. Once all the conditions being tested become true, operation resumes.

Referring back to the VMEbus example above Fig. 1), recall that the instrument must first wait for the assertion, then negation, of DTACK* by the DUT For this example, two conditions could be programmed to correspond to the assertion and negation of DTACK*, respectively. The Model D20 would then be programmed to test these conditions at appropriate points in its cycles. When the sequencer arms the trigger in a particular cycle, the trigger state machine inhibits the timing generators and prescaler immediately before the beginning of that cycle. Operation continues once a trigger is received from the master section. Trigger events that arrive while the trigger is not armed are ignored.

The Model D20 can be synchronized with an external clock signal by feeding the clock into a trigger input and then arming the trigger immediately before the expected clock edges. The variable trigger delay (in the master section, Fig. 4) provides the means to change the phase of the instrument relative to the external clock. This is a simple way to align stimulus patterns and control signals with other events in the DUT. However, trigger inputs are synchronized with the internal 160-MHz oscillator, resulting in 6.25 ns of random error, or jitter.

The run/stop state machine can be idle, paused, or running. If it is idle (its initial state) or paused, the timing generators and prescaler are inhibited. The running state is entered, allowing operation to begin, when a run command is received. A pause flag, which can be set or cleared at any time, is tested at the end of each cycle, with the paused state resulting if it is true. A run command with the pause flag set causes a single cycle to be executed, while a run command with the flag cleared either starts or continues the sequence. At the end of a sequence, firmware places the instrument back into the idle state.

The breakpoint and end-of-sequence control bits from the sequencer are ORed together and then fed to the run/stop state machine. The resulting sequencer pause line has the same effect as the pause flag. Thus, the instrument pauses at each breakpoint and at the end of the sequence. These two bits are separate so that breakpoints can be distinguished (by reading a status register) from the ends of sequences.

The fourth control bit from the sequencer causes the stimulus timing generator to produce two types of marker pulses. One type is always two subcycles wide and can be directed to one or both of the VXIbus ECL trigger buses. The second type of marker pulse lasts the whole cycle and can be sent to any or all of the VXIbus TTL trigger buses. This second pulse also appears in both active-high and active-low forms on the front panel.

System Deskew and Cable-Length Compensation

Suppose that two outputs from a digital instrument are to have transitions that happen at exactly the same time. This is impossible to achieve in reality, and the difference in time between the transitions is called skew. A similar notion applies to inputs that are supposed to sample DUT responses at the same time, but don't. Skew is the main component of tester timing error and should therefore be minimized at the DUT.

There are many sources of skew in an instrument like the Model D20. A big contributor is the statistical variation in delay between instances of otherwise identical timing or data paths. Two pattern I/O ports can have substantially different delays from their pattern clock inputs to their stimulus outputs. Pods will also differ from unit to unit. Even two modules with equal delay will have skew between their outputs because of backplane propagation time. The farther a pattern I/O module is from the timing module, the later it will receive pattern clocks. Each slot introduces a delay of about 800 ps.

Now suppose that there are pods (and their cables) between a Model D20's pattern I/O ports and a DUT (see Fig. 6). Suppose also that a stimulus transition is meant to occur at the same instant (t = 0) as a response transition at the DUT. For this to occur, the instrument must generate the stimulus before t = 0. Likewise, the response arrives at the response port after t = 0. To create the proper timing relationships at the DUT, response pattern clocks must lag stimulus pattern clocks by approximately twice the delay of a pod and its cable.

Minimizing skew and compensating for pod/cable delay both require that internal timing relationships be adjusted according to the actual delays of various parts of the system. When a Model D20 module or pod is manufactured, its delays are measured and stored in electrically erasable read-only memory (EEROM) in that module or pod. Every time the instrument is turned on, its EEROMs are read by the firmware, which then uses the information to compute how much delay to add using variable delays in the pattern I/O and timing modules. This compensates for the major contributors to skew, as well as the pod/cable delays, without any special measurements, fixturing, or programming on the part of the user. Even after a failed module or pod is replaced, the instrument automatically meets its skew specifications. In many cases there will be a significant length of cable between the instrument (with or without pods) and the DUT. For these situations, there is a command that allows users to specify the delay to the DUT and back. The Model D20 then corrects for this round-trip time as well as its own, in the manner described above. Since many cables have specified propagation velocity, timing accuracy can be maintained at the DUT, even in the absence of pods. This feature also makes it feasible to build custom interface circuitry and compensate for its delay. For example, translators to and from ECL levels or differential drivers and receivers for the SCSI bus could be employed.

The maximum possible delay from a pattern clock at the output of the timing module to a stimulus output (including backplane, pattern I/O port, and pod delays) is a known constant. Since actual delays are always lower, the Model D20 can be deskewed by adding an appropriate delay in each port's clock path. The circuit that does this is shown in Fig. 7. When the pattern clock arrives, it sets the flip-flop, which opens the switch and allows voltage to start building on the integrator capacitor. When this voltage crosses a threshold set by the digital-to-analog converter (DAC), the comparator trips. This generates the delayed clock signal and resets the flip-flop, closing the switch and rapidly resetting the integrator in preparation for the next pattern clock. Thresholds that are more negative take longer to reach and therefore result in longer delays. The total range of delay variation is 25 ns and the worst-case resolution is 130 ps.

To compensate for pod and cable delays, response pattern clocks must be delayed with respect to stimulus pattern clocks by approximately 50 ns. The cable length compensation circuitry in the timing module mg. 5) accomplishes this by delaying the two control bits to the response timing generator with a twelve-stage tapped shift register. This results in up to 75 ns of delay in 6.25-ns steps. The clock delay circuit in each response port interpolates these steps and deskews the port as described in the paragraph above.

The control timing generator is much faster than a worst-case stimulus port located at the far end of the backplane. Delay must therefore be introduced to deskew the control signals. This is done with the same tapped shift register that is used for the response timing generator. The two control bits and the accompanying oscillator signal are then fed through tapped delay lines to subdivide the 6.25-ns shift register steps into quarters. Thus, control timing generator delay can be adjusted with 1.56-ns resolution.

The most-significant causes of skew are measured or characterized at the factory and compensated in the deskew process. The many factors that cannot be compensated combine to form the Model D20's skew specification. Two main sources of this residual skew are the differences in delay among the eight bits of a port and between rising and falling edges. Other contributors include power supply and temperature variations, aging, inconsistency between backplanes, and available deskew resolution. The net effect is that stimulus transitions (excluding going into or out of tristate), control signal transitions, and actual response sampling times, will all be within [+ or -]3 ns of their programmed values. This gives the Model D20 a pin-to-pin skew of 6 ns.

Since all actions are initiated by crystal-controlled circuitry, an additional error of only 0.01% is introduced for events that are separated in time. This is usually insignificant, being on the order of picoseconds in most cases.

Conclusion

The HP 75000 Model D20 was created to fill the need for digital stimulus/response capability in a wide range of manufacturing functional test applications. Characteristics of digital interfaces and the VXIbus platform were exploited in the design, resulting in a high-performance instrument that is both cost-effective and easy to integrate and use.

Acknowledgments

No project of this size is brought to completion without honest efforts from too many people to name here. The author would, however, like to recognize the accomplishments of the rest of the R&D hardware and firmware team. Lee Gregory's architectural insight and solid circuit design put the Model D20 on firm footing from the beginning. Phil Mizuno implemented the pattern I/O modules. nm Lock designed cost-effective yet EMI-proof packaging for both modules and pods. Rick Adams wrote all the firmware with the exception of the timing correction algorithms, which fell upon Jim Epstein's shoulders. Bob Hetzel and Dave Swigert designed and built the production test and calibration systems, respectively, while Bob Vienot's technical skills continued to amaze us all. Finally, Larry Jones provided the leadership and the glue for the team, making the tough calls when necessary.

COPYRIGHT 1992 Hewlett Packard Company
COPYRIGHT 2004 Gale Group