Market demand for faster digital ICs and decreased power consumption exerts enormous pressure on designers to meet these goals. At the same time, shorter windows of opportunity for new devices continue to squeeze time-to-market requirements. A device analysis tool that facilitates performance testing earlier in the process would make a designer’s job much easier.
The Problem
Adapting existing designs to higher performance levels—rather than starting new designs from scratch—saves both time and money. This solution, however, creates significant challenges. Merely speeding up device clocks achieves only mixed success. Devices that work perfectly at 100 MHz may fail at 115 MHz in ways that are difficult to identify. Shrinking geometries, in turn, present several challenges of their own.
Although circuit elements get faster, interconnect delays do not fall comparably. Race conditions and other speed-related conflicts become more prevalent. In fact, on deep-submicron-geometry devices, delay through the interconnects usually exceeds delay through the gates themselves. Placing circuit elements closer together also makes them more susceptible to crosstalk and other forms of noise.
If it were possible to create these complex designs in simulation and to ensure that they worked when the silicon arrived, life would be simpler. Today’s electronic design automation tools simply cannot accurately predict
device behavior due to the uncertainties created by propagation delays, signal noise and crosstalk, and the many calculations that simulating so many interconnects demands. As a result, it is imperative to compare the real performance of silicon prototypes against design requirements and then make necessary design modifications to ensure signal integrity and error-free logic.
Challenges Facing Prototyping Analysis
An analysis technique that pinpoints why and how failures occur in the silicon version of a design offers tremendous benefits to device developers. Such a tool avoids costly errors by assuring that devices meet theoretical specifications before the ramp-up to full production.
New device designs, however, make this task even more difficult. To speed up system performance, microprocessors and other complex devices commonly contain circuitry that multiplies the external clock to achieve a higher internal (core) clock speed. Multipliers of 2 or 4 are fairly common, but some new devices feature odd (for example, 3 or 5) and fractional (for example, 3.5) multiples.
Stable internal core clocks are ensured by including a phase locked loop (PLL) in the clock circuitry within the device. To examine a device’s reaction to modest timing changes, a verification procedure must bypass the multiplier circuitry and drive the core clock directly, without the interference of the PLL.
Providing the waveforms to drive the internal clocks directly requires a test system that matches both core clock speeds and the multipliers. For example, the test system could be required to provide three pulses per test cycle at three times the speed of the device test vector.
Speed-Path Determination
The key to determining whether a circuit design will function adequately at a particular speed requires a test system that features a very flexible and interactive timing capability. For example, if running a 100-MHz part at 115 MHz causes a failure, then finding the source of that failure means identifying the circuit path or paths that cannot tolerate the higher speed. One technique becoming increasingly popular involves either stretching and/or shrinking particular test cycles until the device passes or fails, showing exactly where the design is most susceptible to speed-path problems.
The test system must permit interactive changing of individual test-cycle widths in some orderly and straightforward manner. This procedure changes a part’s operating frequency and adjusts its edge timing with very fine resolution to isolate paths and specific circuit elements that experience problems at the higher speeds.
This technique determines whether a longer (stretched) pulse will permit a previously failing path to pass or whether faster pulses will cause the device to fail. To accomplish this task, you must create a collection of timesets that contains instructions to the test system on test-pulse timing. You can, at any time, assign a particular timeset to a specific vector in a test-pattern sequence. This approach permits finely adjustable test-pattern timing and helps identify the areas of the test that are failing.
To find a speed-path fault, some device manufacturers begin with a test pattern that passes completely, then they speed it up until the device fails. Others work the other way around, starting from a failing condition, then slowing individual vectors until the test passes.
Initially, you tighten the timing of a device that is working at a nominal frequency until it fails. Through the correct use of user-defined formulas, primary input setup failures can be avoided.
Armed with a “passing” and “failing” clock frequency, individual cycles can be modified. For example, starting from a passing condition, the first clock pulse could be shrunk and a functional test executed. If this test passes, the procedure could be repeated for the second pulse and so on until a failure is detected.
Figure 1 shows six iterations of this ripple technique. Also shown is a second technique, termed domino, which successively shrinks pulses until a failure is reproduced. As an example, starting from a passing condition, you can shrink the first clock pulse and execute a functional test. If the test still passes, the next test run returns the first pulse to its normal width and shrinks the second pulse, and so on until the test fails.
This technique of either stretching or shrinking a pulse in a test sequence is known as ripple. The domino technique successively shrinks pulses until the device fails.
The capability to perform cycle stretch and shrink interactively significantly improves your ability to identify timing problems easily and quickly. Ideally, you should implement timing changes directly controlling the test system without recompiling a test program or performing other housekeeping chores that would slow the process.
Using the results of a speed-path analysis, you can implement changes to alter the performance of the device. The changes can involve process modifications, altering device layout such as rerouting two signals to prevent crosstalk between them, or a myriad of other possibilities.
Working With a Real Device
Manually executing cycle-by-cycle timeset modifications rapidly is both tedious and time-consuming. Automating the activity produces the same results much more quickly. Knowing at which vector sequence the failure appears, you can instruct the test system to make the necessary cycle-width modifications over a particular range of vector sequences and rerun the test under each set of conditions.
Consider an actual test case of a device with two clocks: Xclk1 (3x multiplier) and Xclk2 (2x multiplier). The device passes when the Xclk1 clock has a cycle time of 7 ns with 50% duty cycle but fails at test vector 3459 when this clock’s timing is tightened to a cycle time of 5 ns and a pulse width of 1.25 ns on all sequences.
Once the failure has been observed, return the device to its working frequency and create new timesets to determine exactly where and why the failure at sequence 3459 has occurred. This is accomplished by consecutively shrinking the vectors from immediately after the device reset (sequence 920) to the point of fail.
With the Time Navigator IITM interactive interface in the IMS ATS FT™ Test Station, you can either create or select predefined timesets. These timesets are then automatically assigned to determine where the timing problem exists.
As shown in Figure 2, the current Xclk1 timing is the “passing” frequency with a cycle time of 7 ns stored in the timeset called base. You have entered the “failing” frequency and the tool has created a new timeset called shrink.
Both the current waveform and a preview of the waveform that will be generated by the shrink timeset are presented as a visual aid. Remember, you are working with the timing characteristics of one core clock cycle (subcycle time of 5 ns). At the same time, the software program manages the system cycle timing (arrived at by multiplying the subcycle time of 5 ns by the clock multiplier, resulting in 15 ns).
Armed with two timesets, speed-path analysis can be performed by switching the window into the timeset application mode. You select the shrink timeset, enter the range of test vectors (or sequences) over which the shrink timesets should be applied and choose the pulse-modification technique.
Figure 3 shows the domino method, starting from sequence 920 and continuing until a fail has been detected. A step size of 100 has been chosen which causes 100 system cycles (effectively 300 Xclk1 cycles) to be shrunk at each iteration. This allows you to quickly ascertain the block of vectors causing the speed-path problem.
At start of test, the system dominoes from sequence 920 and stops after shrinking sequences 2420 to 2519, with a single error detected at sequence 3459. Pushing the undo button de-assigns the shrink timeset from all sequences, returning the setup to the original passing condition.
In the next stage of analysis, you must determine which sequence in the 2420 to 2519 block is causing the error. Reprogramming the test system to ripple from 2420 to 2519 in a step size of one yields a stop on fail when sequence 2487 is modified. At this stage, three clock pulses are being shrunk at each iteration of the process.
Isolation of the speed-path problem to a particular logic block within the device can be achieved by rippling pulses on an intra-test cycle basis. Figure 4 shows that the sequences mode has been changed to the subcycles mode. A new pop-up has appeared, allowing you to specify the timing parameters for the subcycle rippling. Accepting the same pulse width and cycle time used previously, the system is programmed to ripple from the first to the last pulse at sequence 2487, stopping after modifying the second pulse.
An animate feature provides a visual representation of the testing process, allowing you to observe the waveform modification. In this case, prior investigation determined that the cause of the failure was an internal setup violation in the instruction decode logic of this device.
Conclusion
Many device manufacturers are realizing the benefits of performing speed-path analysis of prototype devices. New software tools provide the capability to quickly and interactively determine the limitation of the circuit elements that prevents the chip from performing at maximum speed. In addition, analysis of the speed-path bottlenecks of working prototypes ensures a design’s success and helps speed time-to-market for cutting-edge designs.
About the Author
David Leslie is a senior application engineer for technical marketing of digital test stations at Integrated Measurement Systems. Previously, he held field positions with IMS, TSSI and IKOS. Leslie has a B.S.E.E. degree from Newcastle in England.
Copyright 1996 Nelson Publishing Inc.
|
|
Integrated Measurement Systems, 9525 SW Gemini Dr., Beaverton, OR 97008, (503) 626-7117.
November 1996