Built-In Self-Test Trendsin MotorolaMicroprocessorsBIST started life as a mistake; it is now a key strategy.This article offers an insiders' account of a decade ofbuilt-in self-test development at Motorola.

R. Gary Daniels and William C. Bruce, Motorola, Inc.

There has been a steady and relent-less increase in VLSI complexity

in microprocessor-based products over

the last 10 years. As design complexitygrew, the problems associated withtesting these devices also increaseddramatically.The first Motorola microprocessor

was designed to have no intentionaltest features. With current VLSI com-

plexities, this practice could result in a

production nightmare, including un-

testable functions, lengthy test times,and extremely long functional pattern-

generation schedules that require a

host of engineers. Design for testabil-ity has become an integral part of thedesign process, but this did not happenovernight; rather, it evolved over

several years.

In this article, we review the events

leading up to our present design meth-odology, in which built-in self-test isone of the key strategies.

0740-7475/85/0400-0064$01.00 (D 1985 IEEE

1974: The Motorola MC6800The Motorola microprocessor test

story begins with the first Motorolamicroprocessor, the MC6800, whichwas introduced in 1974. The devicewas built in six-micron NMOS tech-nology with about 4000 transistors.Regarding built-in self-test, or BIST,features, it had none-at least, nonewere intended. It used a bus architec-ture, however, which has certain in-herent testing advantages. A couple ofinstructions were very convenient forunloading all of the registers (SWI)and loading them back up again (RTI).These instructions provided much ofthe control and visibility necessary tosupport testing, although that was nottheir intended purpose. Testing was,frankly, an after-the-fact considera-tion-the part was designed and then itwas someone else's job to figure outhow to test it.

I identify with that "someone"quite well, because I joined the groupwhen the designers were addressingthat very problem. The task seemedfairly straightforward. All we had todo was execute every possible instruc-tion-there were only about 192-with every possible addressing mode.And, of course, we had to use everypossible data combination. Then someof the designers mentioned that since itwas a dynamic part, we'd need toprecondition all the internal registers

Editor's note: This article stems from a

presentation by Gary Daniels at the IEEEInternational Test Conference in October 1984.

IEEE DESIGN & TEST

with every possible data combination.This seemed reasonable. They alsopointed out that there were five dif-ferent interrupts, so we'd need tomodulate all the above with five dif-ferent interrupts, which could occur atany time. This too seemed reasonable.

I made a few calculations andasked, "By the way, how fast does thispart run?" They replied, "About IMHz, so in round numbers, you canexecute about 300,000 instructions persecond." That seemed incredibly fast,so I multiplied by all the combinations,divided by the execution speed, anddetermined how long it would take totest one part: two million years! That isthe essence of the problem of testingmicroprocessors. It isn't that we aren'twilling to do it-it's just that no one iswilling to wait that long.

1975-1976:Move and recession

In 1975, we moved the MOS opera-tion from Phoenix, Arizona, to Aus-tin, Texas. Although the date was setfar in advance, we wound up movingin the middle of a recession, whichalmost put us out of the micropro-cessor business. Not only were there nobuilt-in self-test developments in thatperiod, there were almost no develop-ments at all. To add insult to injury, wediscovered that we had an illegalHACOF, an instruction that our cus-tomers found on the MC6800. It wasan unused opcode-an illegal instruc-tion. When executed inadvertently, theprogram counter would increment in-definitely. The problem, which wascaused by incomplete opcode decod-ing, was a nuisance because Reset wasthe only means of terminating the in-struction.

1977: The MC6802The MC6802 was introduced in

1977. It marked the beginning of theroad back for us in microprocessors.With 11,000 transistors, it was basical-ly an MC6800 microprocessor with anon-chip RAM and oscillator. Duringthe design process, we figured out howto eliminate the HACOF instruction.About that time, the product engineers

came to us with an idea. They said,"You know what we'd really like?Some way to quickly test the RAM. Ifwe could somehow point the programcounter at the first RAM address andthen just increment through the RAM,we could test it a lot faster." Since theHACOF "instruction" did preciselythat-and we really didn't want to in-vest the effort needed to removeit-we replied, "Have we got a dealfor you!" HACOF thus became thefirst intentional built-in self-test fea-ture on a Motorola microprocessor.

I multiplied by allthe combinations, divided by

the execution speed, anddetermined how long it

takes to test one part: twomillion years!

1978: The MC6801In the Army, the first thing you do

when you clean your rifle is check theserial number-you want to make sure

you're cleaning the right rifle. On theMC6801, we often performed the righttest in the wrong mode. It was a fairlysophisticated microcomputer unit,with about 35,000 transistors, manyoperating modes, and many test prob-lems.

During one of our yield-improve-ment meetings, we looked at some

MC6801 tally data (accumulated fail-ures by specific modules) and someoneremarked that the timer looked reallygood; that is, the proportion of timerfailures was much smaller than theproportion of timer area. Someoneelse astutely observed that it was more

likely that the timer test was not goodenough. Shortly thereafter, we beganto get a few timer field-rejects. Partsthat passed our timer test weren'tworking correctly in customers' ap-plications. After some investigation,we discovered that the designers hadoverlooked adding test logic to splitthe 16-bit counter and had been reluc-tant to add a test that required 65,536cycles to execute. After swallowing

hard and adding the test, we failed allof the field-reject parts.

The MC6801 was our first ROM-based part, and this put us in the cus-tom-IC business. It also introduced usto a few test problems that we hadn'tseen before. For example, we noticed asignificant yield loss due to ROM testfailures. For a while, we thought wehad some sort of design problem withthe ROM. Further analysis of theROM rejects, however, showed thatparts with different customer-ROMpatterns had been mixed in together.Most of them were, in fact, goodparts-once they were matched withthe correct ROM test pattern.

1979: Banner yearEven now, the banner year of 1979

seems like our most productive singleyear. We introduced our first EPROMproduct, the MC68701, and our larg-est (and probably last) random logic-based chip, the MC6809. We alsoentered both extremes of the market-place: the high-performance market,with the MC68000, and the low-costmicrocomputer market, with theMC6805P2. Finally, we introducedour first CMOS microprocessor, theMC146805E2. At the time, we didn'tenvision the important role CMOSwould assume in just a few years.

The MC68000 die is about 273 milson a side and^contains-coinciden-tally-about 68,000 transistors. Theonly test feature was logic, whichenabled the microcode ROM to beread directly. This scheme also testedthe sequencer using the microcode out-put as an indirect indication of correctoperation.The MC6805P2 is about 140 mils on

a side, contains approximately 20,000transistors, and is roughly one-fourththe area of the MC68000. TheMC6805P2 is a single-chip micro-computer. In its normal operatingmode, it has no external bus and pro-vides no access to internal buses. Tosupport testing with ATE-driven pat-terns, we designed a production testmode that provides both control andvisibility by multiplexing the internalbuses onto the port pins.

April 1985 65

First major BIST influence:The chicken ranchAt this point, it was time to take my

family on a vacation to Uncle Leroy'sranch in Arkansas. After breakfast thefirst morning, my brother-in-lawasked me if I'd like to help feed thechickens. This brought back somepleasant childhood memories, so Isaid, "Sure, I'll help you feed thechickens. By the way, how many doyou have?" He replied, "80,000."Well, let me tell you, the only way tofeed 80,000 chickens is to let them feedthemselves!

Concept. As I watched the chickens,it occurred to me that a microcomput-er has at least the intelligence of an av-erage chicken. If chickens could feedthemselves, it seemed to me that weought to be able to get our microcom-puters to test themselves. So I cameback from vacation all fired up withthe idea of getting a microcomputer totest itself.

I met with the project team and ex-plained that if we could get a micro-computer to test itself, we could reduceour production costs, the customer'stest costs, and provide a nice market-ing feature as a bonus. Also, becauseevaluation tools are typically not com-plete when the initial sample of a newdevice is ready, self-testing would solve

this problem as well. The project teamguessed (correctly) that they wouldn'tbe able to talk me out of this idea, sothey went off to figure out how to im-plement it. They came back with ascheme that used a special Reset vectorto invoke a self-test program stored ina small portion of ROM. I The ROMcontained instructions that caused theCPU to test the peripheral modules onthe device while it indirectly testeditself.

The concept called for the CPU toact as the intelligence-the brain-andtest the RAM, the timer, and all theother features on the MC6805P2. Toaccomplish this, we would reserve 116bytes ofROM exclusively for the tests,causing the die size to grow by aboutthree mils. Three mils on a 140-milchip . .. we had at least 10 meetingstrying to decide whether that was asmart thing to do. Adding three milsreserved for testing to a chip that wehad worked hard to reduce to thesmallest possible die size was a revolu-tionary proposal in 1979.

Results. As noted earlier, wethought the test feature would reduceour production costs, but the faultcoverage of the test was not highenough to eliminate conventionalATE-driven test patterns. We hoped torequire only a trivial test fixture, rather

than conventional ATE, but this wasunrealistic in a high-volume produc-tion environment. To make mattersworse, we had some nonoverlappingfault coverage between the self-testand the test patterns. That is, the self-test could detect a few faults that thepatterns missed, so we had to continueusing it until we had identified thefaults and added vectors to the test pat-terns. The very simple test fixture re-quired to execute self-test did providetwo major benefits: (1) It was an ex-cellent first-pass evaluation tool thatcould be used until other tools werefully developed, and (2) it was a supermethod for implementing a burn-incircuit.

In attempting to evaluate the mar-keting value, we found it difficult todetermine whether our customers wereusing the self-test to reduce their owncosts. It was the opinion of our prod-uct engineers that only a few wereusing the on-chip self-test. Then an in-teresting thing happened. We have aprogram that calculates the checksumof the customer ROM data and thenmaps the checksum, along with theROM data, onto a mask layer. After a"minor" modification to the pro-gram, the checksum algorithm pro-duced an incorrect result. Before theproblem was discovered, we had pro-grammed 40 different customer partswith ROM data that was correct-ex-cept for the self-test checksum. Nearlyall 40 customers were ready to tear thewalls off the factory to get that errorcorrected.We concluded that customers do in

fact use the on-chip self-test.

Second major influence:Trip to KokomoThe second major test influence

came as a result of a trip to Kokomo,Indiana. Kokomo, among otherthings, is the home of the Delco Elec-tronics Division of General Motors. Ajoint proposal evolved during this trip:We decided to find out whether testgrading could be used to improveproduct quality. The MC6802 was se-lected as a candidate to test thishypothesis, and we agreed to do faultvalidation test grading (stuck-at-one,

IEEE DESIGN &TEST66

stuck-at-zero fault grading). We per-formed the test grading in two phasesin order to provide efficient use of ourtest grader. First, we added patterns tocatch all of the logic gate output nodefaults, than we made a second testgrading to attack the input node faults.

Using the results of the first testgrading, we added about 130 bit timesto thoroughly test the output nodes.To detect 99.8 percent of the inputnodes, we added 300 more bit times.The test grading required about 18months and ran up a huge computerbill. When it was completed, we won-dered how we would convince our-selves that the result was worth the ef-fort. At that time, we knew of no dataor published papers indicating thatquality improved after test grading, sowe put together something I called the"proof of the pudding" experiment.Proof of the pudding. The experi-

ment began by simply datalogging thebit time of the first failure. Experiencehad taught us that integrated circuitsare typically very, very good or very,very bad. If there were no failures afterthe designer's original test pattern,then test grading was ofno value in im-proving quality. The MC6802 seemedto be an excellent subject for this ex-periment because the test pattern wasmature, having been developed overseveral years.

The first 828 bit times, or clockcycles, followed the classic test patterndeveloped by the designers of the part.Another 30 bit times had been addedto solve problems discovered since thepart entered production. Therefore,the part had been produced for sometime with an 858 bit-time test pattern.Test grading indicated that the design-er's original test pattern detected 96.6percent of the possible "stuck" faults,

but we still didn't know how to relatethe fault coverage to the expectedfield-reject rate. We knew we'd need alot of data for the experiment, so wepicked five lots of material. We hadoriginally planned to test 100 wafers,but we were thrown off the test floorafter 93 wafers and 22,500 data points.

Results. Table I summarizes theresults.2 Of the 22,506 dice we probed,

Table 1.Summary of experimental test results on MC6802.

Lot Wafers Potential Gross Logic Failure Rejects By Bit Time(® Total Parametric Units UnitsNo. tested good die rejects® 0-100 101-500 501-858 859-992 993-1290 rejects({) assembled® shipped®

1 36 8712 1442 2143 262 157 22 3 2587 1126 3557 21342 27 6534 1185 1410 178 64 34 9 1695 2348 1306 7843 20 4840 1027 1273 86 62 20 2 1443 1109 1261 7574 5 1210 177 291 29 14 5 1 340 230 463 2785 5 1210 175 301 55 16 7 0 379 193 463 278

Total 93 22,506 4006 5418 610 313 88 15 6444 5006 7050 4231

Notes:

1. Opens, shorts, etc.2. Relaxed functional test (easy functional).3. Designers unaided test pattern ended at bit time 858.4. Pattern improved to 100 percent output faults by adding bit times

859-992.

5. Pattern improved to 99.9 percent input and output faults by addingbit times 993-1290.

6. Includes RAM failures.7. Potential good minus gross defects, easy functional and parametric

rejects.8. Assumes 60 percent cumulative assembly, die high power and final

test yield.

April 1985 67

4006 exhibited gross failures such asopens, shorts, and clock failures.Another 6444 failed functionally-that is, in the functional test pattern.And, sure enough, 84 percent of those-or 5418 dice-failed in the first 100bit times. This confirmed our ex-perience that when ICs were bad, theywere, in fact, very, very bad. Another923 dice failed in the next 758 bit times.Most impressively, 103 dice passed theoriginal test pattern but failed the test-graded addition. If we assume thatsubsequent parametric testing, pack-aging, and final testing resulted in pro-portional failures in both the good anddefective parts, then about 35 partswith functional defects would havebeen included in 4266 outgoing de-vices, had they been tested without thetest-graded addition. As far as I wasconcerned, that was the proof of thepudding. There was no longer anyquestion in my mind that test gradingcould improve product quality.

Third major influence:The design test groupThe third major influence in self-test

at Motorola was the establishment in1980 of a test group within design. Thisdecision was largely motivated by acontinual flow of test-related prob-lems into design. I can remember sort-ing through a two-week-old stack ofmemos and finding at least a half-dozen that described some testingproblem. Consequently, we estab-lished a test group within circuit designand chartered it to bridge the gap be-tween design and production test. To-day that seems like a very logical thingto do. At the time, however, it wasunusual-at least, it seemed so to myboss when I asked for additional staff.

In retrospect, I regard this as one ofmy better decisions as a design man-ager. To my knowledge, this group'srelationship with design, test, andproduct engineering is unique amongmerchant semiconductor companies.

1980-1981: ConsolidationThroughout 1980 and 1981, we

developed some derivative products,enhanced speed, and test-graded somemore patterns. We worked on improv-ing our test pattern methodology andimproved our CAD test tools, but wemade no significant advances in testtechnology-except that the flow ofmemos on test-related problems driedup.

1982-1983:MC68010 and MC6804

In late 1982 and early 1983, we in-troduced two new products. The firstwas the MC68010, an MC68000 withvirtual memory support. It containedabout 82,000 transistors on a 320 x 290-mil die. It was our most complex partand one of the largest and most com-plex ICs in the industry. It included atest mode similar to that of theMC68000, which provided access to

the sequencers and microcode ROM.At the opposite end of the perfor-

mance spectrum, we introduced theMC6804P2 microcomputer. It re-

sembled an MC6805P2 but was im-plemented in a serial architecture. Atiny chip with only 100 mils on a side, ithad about 18,000 transistors. Mostsignificantly, it contained a near-totalBIST capability.From our experience with the

MC6805P2, we knew we were expect-ing too much performance from self-test based solely on ROM. The pro-gram was required to provide thestimulus, determine the response, anddecide the outcome. This procedurewas too byte-inefficient, and the cir-cuit visibility was too poor to achievevery high fault coverage in a smallamount of ROM. In addition, oureconomic experience with self-test in-dicated that it had to be nearly total inscope to pay for itself.

I asked the project team for theMC6804 to come up with a total self-test scheme. In order to reduce theamount of ROM required, the teamproposed a signature analysis tech-nique that would assume the role of anon-chip test response evaluator, withtotal visibility to one of the key buses.

IEEE DESIGN &TEST68

This solution reduced the task of theprogram to essentially that of provid-ing the stimulus and bringing the resultto the bus, where the signature registercould see it. We also added a little moreROM than our estimate called for, justto be sure that the fault coveragewould be high enough.The results of the MC6804P2 self-

test have been very gratifying. No con-ventional test pattern set exists for thispart-only the on-chip self-test and anexecutive test pattern to control it.34As one would expect with a 100-milchip, the die cost is very small; packag-ing and test costs dominate the productcost of the part. To reduce productcosts significantly, we had to attackthe test cost.

1984: Another banner yearIn 1984 we introduced three new ma-

jor VLSI products, which together havea half-million transistors: the MC68020microprocessor, the MC68881 floating-point coprocessor, and the MC68HCI Imicrocomputer. The MC68020 is a2.5-MIP processor. Not only is theMC68020 smarter than any chicken I'veever seen, it's smarter than some test-ers-and that fact has presented us withsome problems.

The MC68020. The MC68020 con-tains 200,000 transistors. Comparedwith the MC6800, at 4000 transistors,that's a complexity increase of a fac-tor of 50 in the last 10 years. TheMC68020 die size is 375 x 350 mils, intwo-micron HCMOS technology (seeFigure 1). Figure 2 compares theMC6804P2 and the MC68020-ourlargest and smallest dice. The designspecification for the MC68020 is 700pages and is kept on a computer.Managing the design specification is asignificant problem, due to both thecomplexity of the device and thenumber of designers needing accessto it. The "data sheet" is a bookpublished by Prentice-Hall.5The MC68020 was in design a long

time. I asked one of the designers whenhe started work on this part, and hesaid, "Well, Gary, when I started, Iwas a bachelor driving a Corvette liv-

Figure 1. Die photograph of an MC68020.

Figure 2. Die photograph of an MC6804P2 and an MC680020.

April 1985 69

Figure 3. Die photograph of an MC68HCI1.

ing in an apartment down on the lake.Now I'm married, with two kids. Idrive a station wagon and I'm buildinga new house in the country." In otherwords, this part was in design for atleast four years.

Test activity has been going on for acouple of years. We use a variety oftechniques to support production test-ing of the MC68020.6,7 The principalstrategy is to partition the chip intomanageable blocks. This process facil-itates the testing of structures ratherthan functions. PLAs, ROM, and thecache are partitioned with multiplex-ers and some supportive microcode.Where PLA outputs are too embeddedfor this approach, on-chip signatureanalysis is used to compress the outputresponse and make it visible. Testmicrocode is used to provide input andoutput data rather than to implement

an on-chip, microcode-based self-test.We developed an automatic test pat-tern generator that is used to generatethe PLA tests. The fault coverage ofthe test is one of the test generatoroutputs.

The MC68HC11. The last product Iwant to mention is the MC68HC11MCU, which is second in complexityonly to the MC68020. Its die size is256 x 287 mils in two-micron HCMOS.Of all the projects I handled in 10 yearsas a design manager, I am most proudof this one. It was conducted verymuch as I believe projects will be con-ducted in the future-that is, it wasbroken up into modules, and eachmodule was treated as a subproject.The CPU, timer, serial I/O, EEPROM,ROM, RAM, and A/D converter wereall treated as separate projects.

We designed the MC68HC11 to bevery testable using test modes andfeatures that alter the normal con-

figuration of the part and provide theability to test modules more simplyand quickly than would be possible inthe user mode. About a dozen registerbits, which are write-protected exceptin test mode, provide most of the testconfiguration control.We think we have found an interest-

ing solution to BIST. Depending uponuser needs, the MC68HCI I has eithera lot of self-test or none. It has none inthat there's little BIST hardware on thepart. It has a lot in that there is an im-portant self-test tool, called the bootloader. The boot loader is a small por-tion of the ROM that directs the MCUto load external input into the 256-byteRAM from the serial I/O. After thememory load is complete, the MCUjumps to RAM and executes the pro-gram. This scheme supports self-testof the chip, the board, or the system.Customers have reacted very positivelyto this self-test approach.

The part has only four modes-twooperating modes and two test modes.They are accessed very simply via twopins and simple input schemes. We le-galized HACOF (an instruction joking-ly referred to as "Halt AND Catch OnFire"), although it's been given a morerespectable name in the MC68HCI I:the TEST instruction. If executed in anymode but test, it triggers an illegal op-code trap.

Figure 3 shows a die photograph ofthe MC68HCI1. The strips that startfrom the bottom are 512 bytes ofEEPROM, then 8192 bytes of ROM,and, in about the middle of the chip,256 bytes ofRAM. The relative sizes ofthese three different types of memoryare evident as implemented in two-micron HCMOS.We believe that the MC68020 and

the MC68HC 11 represent the state ofthe art in VLSI. Both are processed intwo-micron HCMOS and are availablein new package types-the MC68020in a 114-pin grid array, and theMC68HCII in a 52-pin, surface-mount plastic quad package. Both aredestined for high volume.

IEEE DESIGN &TEST70

Wllhat does the future hold forT T BIST in terms of VLSI? To be

sure, the quest for improved qualitywill continue. When I go to meetings,I'm often not sure whether I'm thecustomer or the vendor. As a customermeeting with ATE manufacturers, Iwant the best quality I can get fromtheir testers. A tester that operates at100MHz doesn't do me any good if itis down half the time. If I put on myvendor hat, I assume that the ATEmanufacturer-my customer-willdemand high quality in integrated cir-cuits in order to achieve the same quali-ty in the tester that he'll sell back to me.VLSI test equipment is very expen-

sive, and VLSI complexity continues toskyrocket. Based on the rate noted ear-lier, we'll be able to put 10 million tran-sistors on a piece of silicon 10 yearsfrom now. But how are we going to test10 million transistors through 100-pluspins?

We've got a tremendous challengeahead. In my opinion, we've justtouched the tip of the iceberg in bothVLSI design and testing. The VLSIrevolution is fueled by its own prod-ucts; we sell M68000-family parts tocompanies for tens of dollars, and theysell them back to us-packaged in verycapable engineering workstations-for tens of thousands of dollars. So weare using our latest generation of chipsto design our next generation.

I see only one possible solution forhandling the VLSI problems of thefuture. Design managers must use amore structured approach in designingVLSI chips. If our design approachesdo not become more structured, ourgrandchildren might have to finish thenext round of designs. I've noticedover the years that the problems ofdesign and test are quite similar. Struc-tured design approaches not only offerrelief to designers but also result inmore testable designs.

I recently came across an article byTom Williams8 in which he said,"Time has shown that the problems oflogic testing can only be contained, notsolved." We must continue to containthem if testing is not to become thelimiting factor in future VLSI develop-ment. e]

References1. J. Boney and E. Rupp, "Let Your

Next Microcomputer Check Itself andCut Down Your Testing Overhead,"Electronic Design, Sept. 1, 1979, pp.100-105.

2. R. A. Harrison, R. W. Holzwarth, P.R. Motz, R. G. Daniels, J. S. Thomas,and W. H. Wiemann, "Logic FaultVerification of LSI: How It Benefitsthe User," Proc. WESCON, 1980.

3. J. Kuban and B. Bruce, "TheMC6804P2 Built-In Self-Test," Proc.IEEE Int'l Test Conf., Oct. 1983, pp.295-300.

4. J. Kuban and W. Bruce, "Self-Testingthe Motorola MC6804P2, " IEEE

R. Gary Daniels is vice president of thetechnical staff and director of Motorola'smicrocomputer operations. He was man-ager of Motorola's microprocessor designoperation for the 10 years ending in Sep-tember 1984. Daniels has worked for Mo-torola for 19 years. Semiconductor re-search and development activities in thecompany's central research labs led him tojoin the microprocessor division in 1974.Motorola's MOS microprocessor familywas developed under his leadership. Priorto joining Motorola, he was a designer inthe component test group at Sandia Labs.

Daniels received the 1984 Semiconduc-tor International magazine R&D Award,has authored or co-authored over 25technical papers, and holds 12 US patents.He received his BSEE degree from theUniversity of New Mexico in 1965 andcontinued graduate studies at ArizonaState University. He is a Motorola DanNoble Fellow and a member of the IEEEand ACM.

Design & Test, Vol. 1, No. 2, May,1984, pp. 3341.

5. MC68020 32-Bit MicroprocessorUser's Manual, Prentice-Hall, Engle-wood Cliffs, N.J., 1984.

6. J. Kuban and J. Salick, "TestabilityFeatures of the MC68020," Proc.IEEE Int l Test Conf., Oct. 1984, pp.821-826.

7. J. R. Kuban and J. E. Salick, "TestingApproaches in the MC68020," VLSIDesign, Vol. V, No. ll, Nov. 1984, pp.22-30.

8. T. W. Williams, "VLSI Testing,"Computer, Vol. 17, No. 10, Oct. 1984,pp. 126-136.

William C. Bruce is a principal staffengineer with Motorola at the semicon-ductor products sector, MOS micropro-cessor group in Austin, Texas. He is man-ager of the design test group, part of theMOS MPU circuit design organization,which is concerned with design for test-ability, test pattern generation, self-test,and fault simulation. Bruce, who has beenwith Motorola for eight years, holds threeUS patents, has written several technicalpapers concerned with VLSI testing, andhas served as a session chairman for theIEEE International Test Conference andthe BIST workshop.

Bruce received a BS degree from theUniversity of Wyoming in 1964 and an MSdegree from Ohio State University in 1971.He is a member of the IEEE ComputerSociety.

The authors' address is Motorola, Inc.(OE35), Box 3600, Austin, TX 78764.

April 1985 71