Testing a Microprocessor Without the Manufacturer Patterns

1. Testing a Microprocessor Without the Manufacturer Patterns Michael Salmon CTO Force Technologies Ltd Marlborough, Wiltshire, UK +44(0)1264 -731200 msalmon@forcetechnologies.co.uk www.forcetechnologies.co.uk

2. Summary • If you are a user of off-the-shelf microprocessors in the Mil/Aero/Space/Industrial/Automotive market, suppliers often discontinue the military and industrial temperature range devices well before the end products they were designed into are discontinued. • When these parts are discontinued, it can be desirable to have commercial products up-screened or repackaged to assure a continued source of supply. • However microprocessors are difficult to test and developing test software without the aid of the original manufacturer’s design files can be very costly. • One way to help lower these development costs, but still develop a comprehensive test program, is to use commercially available emulators to assist with the test program development.

3. Summary • The basic approach is to use the test system to set up the basic ability to read and write the microprocessor. (uP) • The customer’s actual system level application code is then loaded into the emulator and also loaded into the test program. • The test program then learns the device responses from the emulator and stores them in the test program. • More than ½ of the test development cost for a uP comes from writing the individual uP instructions, predicting the response to these instructions and then debugging what works and what doesn’t. Using the customer’s own application code eliminates the individual instruction generation. Using the emulator to generate the responses to those instructions also save time.

4. Summary • Additionally, since the end application code is being used, the test program coverage is guaranteed to use every instruction that is used in the end application. This is much better test coverage than is usually obtained by a test engineer just randomly selecting instructions to use in the test program. • This technique still requires competent test engineers and capable test equipment, but with those two ingredients, the test development cost can be cut by roughly ½ and the functional test coverage can exactly match the customer’s application. • Applicable to: • Microprocessors/DSP/microcontroller • Graphic engines • Communications & Networking FPGA’s • Complex Digital devices

5. Traditional Vector Generation Method • Device Design Environment • Modeling Integrated with Design • Simulation to generate test patterns • BIST • SCAN • Functional • Simulation patterns converted to tester patterns • Final Test generated

6. Device Simulations

7. No Device ModelWhere to Obtain Test Vectors? • Designers get them from simulation output • Our ASIC customers usually supply simulation output • Purchase them for the device manufacturer • good luck! • Contract 3rd party to develop • Consultant or test lab such as FTL • Develop them yourselves

8. Example Vector File

9. How to Develop Vectors • Must fully understand the device • Testers work on time cycles • Setup all inputs and expected outputs for one cycle • Try that cycle, fix if necessary and do another • Time consuming • Tedious • Poor coverage • Difficult to keep track of signal pins

10. Way to Solve the Problem • Build a Microprocessor development system • Must have a known good device • Hardware simulator is the known good die • Tester loadboard and tester resources are the hardware • On Tester build a software model of the device interface • Device bus cycle timing implemented in tester • Developed tester s/w monitors device operation and pin status • Complied device assembly language loaded to the device • The device is operating functionally just as it would in an application • Tester records the device operation • Saved as a test vector file

11. Device Bus CycleTester Programmed to Device Timing(AM80386)

12. Special Tester Requirements • Tester algorithmically writes vectors on the fly • Software routine in the tester reviews each vector • Next vector is generated according to the device protocol • Validity of results must be analyzed by s/w • Tester Register stores state of pass/fail • Typically non-user tester registers are required • Tester hardware manuals are consulted • Rewrite vectors in memory • Pass fail pin register allows on-the-fly changes • Test vector is corrected • Executable vector code results • Incremental process • S/W loops executable vectors to correct and add additional vectors • At completion corrected/generated vectors are saved

13. Vector-by-Vector Generation • Input to the program is assembled code • First word of code is converted to binary and applied to input pins • Control pins are monitored to determine the type of bus cycle (read/write) • Continue clocking, recording the outputs until the end of that bus cycle • Read the next word of assembled code and repeat • Stop when no more input code • Save memory to file

14. Test Generation Diagnostic move.l #5555, #AAAA lsl.l #1, D0 bcc #02 Learn routine if s = 2 then if rw = read then data = FFFF Known Good DUT Vectors R/W ADDR DATA CLOCK 0010HLHL 0000LLLL 0101HLHL 1010XXLH

15. Typical Microprocessor Functional Coverage(Pentium) • Attack at a block level • All internal registers & Flags • CPU Instructions • Floating Point Unit • Memory Management • CACHE & Pipelining • Device Memory • Device Interfaces • Data/Address Busses • Peripheral Functions • Serial Interfaces • Analog Functions • Test Strategies needed for each functional block

16. CPU Instructions • Data Movement • Arithmetic Operations • Logical Operations • Shifts and Rotates • Bit Manipulation • Program Control • System Control

17. Need an Assembler Complier(Example MIPS Processor)

18. Testing Methods • Reset • Each pattern must start on a consistent basis • Reset often includes some basic device testing • JTAG / Boundary SCAN • Quick method to check DC output performance of each pin • Check VOL/VOH • Built In Self Test (BIST) • If accessible often the BIST test will result is good basic structural test coverage

19. Structural Test vs Functional Test • Structural test is performed by the manufacturer (>90% of test) • Simulation required • At Device Design implementation • SCAN • BIST • Proprietary Device Information • BIST execution is sometimes made available • SCAN is almost never documented • Automatic Vector Generation • Computer generated patterns • Have minimal relation to device usage • Structural Patterns rarely have timing or parametric consideration • Hard Fault identification • Functional Patterns (less than 10% of the test) • Device functionality and operation • At speed testing • Parametric testing

20. Added Test Methods • Memory testing • Algorithmic Pattern Generation • Checkerboard / Invers checkerboard • March Patterns • High Speed BUS testing • Loop Back methods high speed serial buses • Signature Analysis • Execute multiple instructions and only check the final result • Example: (Multiple, Add, Divide random numbers) • Check for the correct final answer • Pass = Correct Result • Analog Functionality • ADC/DAC operation • Phase Lock Loop • Other Analog Functions

21. Planned Test Flow • Reset • Initialization • Register test • CPU Functional • FPU Functional • Flow Functional • AC/DC Parametrics

22. What this test it is Not • Not a device manufacturer replacement test • Manufacturer provides the full nodal coverage • Structural test is needed with complex devices • Fault grading is not possible without the device model • The test generated will have high functional coverage • May be better than the vendor’s functional coverage • Effective for parametric Screening • Extended Temperature Testing (Up-screening) • Special application screening • Intent is to functionally test all major blocks of the die • Tested similar to the way the part is used • Test finds the timing, parametric or functional problems

23. Recommended Test Methodology • Test the device the specified performance characteristics • Functional at-speed • Application speed at a minimum may not need spec speed • Test frequency is a major tester cost driver • Comprehensive functional testing • Test all device functionality • Fault grading is not possible Only the manufacturer has device modeling capability • Test key AC parameters • Key parameters are usually referenced to device clocks Propagation delay Setup and hold times Extra parameters are often listed for designer reference • Use go-no-go testing to cover most AC parameters Tested over the entire functional pattern • Selected AC characterization measurements can be made • DC measurements to the full specified limits • Attempt to test 25C parameters at extended temperatures • Limit adjustments may be required after testing • Select the appropriate tester • No one tester can effectively test all technologies

24. Applicable Devices & Tester Requirements(Verigy 93000) • Learn Technique - Applicable Devices • Microprocessors/DSP/microcontroller • Graphic engines • Communications & Networking FPGA’s • Complex Digital devices • Tester Requirements • 800 pins 600Mhz digital • 8 power supplies and PMU per pin • +/-100ps accuracy • 100+ Meg pattern depth • Algorithmic pattern generator • Mixed signal capabilities • 18bit Arb. wave form gen • 16bit digitizer • Digital capture memory

25. Test Engineering Integra/FTLSummary • Test/sales/support Facilities in UK/Kansas/California • 41k sq ft (KS), 3k sq ft (CA) • 27 Year History as a Testing Lab • 24 Hours/Day x 7 Days/Week Operations • 170 Employees, 26 Test Engineers & 38 Testers • Broad tester and test technology capabilities • Memory, Digital, Linear, Mixed Signal, RF, FPGA • Engineering expertise in every technology • Greater than 10,000 test programs developed locally • >200 Active Customers Mil/Space & Semi-manufacturer • Operations are ISO-9001, AS9100 UK/US, ITAR, DSCC and Trusted/US • On-Time Delivery Performance of 96% • Customer Satisfaction Rating of 98%