🚀 go-pugleaf

In article <lfatgtINNj5@news.bbn.com> ekearns@bbn.com (Edward Joseph Kearns) writes:
>I've performed this tasks a couple of times running hardware tests 
>out of Eprom using a 680x0 processor.  The only limitation on past 
>products was the amount of testability and observability designed 
>into the product.  To improve test coverage for our next generation 
>product we are designing boundary scan IEEE 1149.1 into all of the
>ASIC's on our boards.  That's a total of 6,334 ASIC pins on one 
>board alone!  I've already decided that it would be wise to break
>the board up into separate scan chains based on functional blocks.
>We'll probably use TI's scan chain contollers and linkers and a
>Motorola 68HC16 BIT processor.

One issue with 1149.1 is that every chip has its own scan controller.
This is fine for chip test, but for board test it would better if
there were only one controller for all the chips on the board.  See

	Dervisoglu, B.I., "Scan Path Architecture For Pseudorandom
	Testing", IEEE Design & Test of Computers, 6(4): pp. 32-48,
	1989.

	Dervisoglu, B.I., "Features of a Scan and Clock Resource Chip
	For Providing Access to Board-Level Test Functions", Journal
	of Electronic Testing: Theory and Applications, 2: pp.
	107-115, 1991.

These papers describe the scan architecture of the Apollo Series 10000
workstation, in which each board has its own Scan and Clock Resource
(SCR) chip that serves as a board-wide scan controller.  A better
approach, IMHO.

>The problem is that we have no 1149.1 resident experience and it 
>looks like I'm going to be it!  I've read everything I can get my 
>hands on.  Right now I'm reading about TI's ASSET PC based tools 
>that help you write and implement diagnostic boundary scan tests.  
>Additionally TI's Scan Engine software converts the tests written 
>for their ASSET product for use on any 16bit microprocessor as an 
>embedded (POST/BIT) application.  The problem I have is justifying
>spending ~$50K for these tools because most everyone around here who 
>has heard anything about 1149.1 thinks that "writing software for a 
>serial test bus should be a piece of cake"!  

Such a typical attitude.  If it's so simple, why haven't those clowns
gone and written it themselves already?  Tell them to get a clue.

>Ya, Right!  Why would TI, HP, Teradyne... have entire development 
>efforts underway if it was easy?  I have no experience in this so 
>I can't defend my belief that this is going to be one huge pain in 
>the butt!  I'd rather be helping the hardware engineers debug their 
>hardware than my boundary scan software.  
>
>Does anyone out there have any experience writing or spec'ing embedded 
>or otherwise boundary scan tests or the use of any 1149.1 diagnostic 
>tools or devices.  Was it "a piece of cake"?  What were the toughest 
>technical hurdles.  Are there really a zillion ways to make an "off 
>by one bit" error in the control software?  How many did you make?
>I have a half million questions....

In a previous life I wrote a lot of scan software.  I found that the
use of object-oriented software development techniques greatly reduces
the chances for errors while allowing relatively powerful tools to be
developed quickly and reused for different applications.

I used C++ to create software objects that precisely modeled the
hardware entities of the problem domain.  These objects behaved as
their hardware counterparts did.  For example, a Board object can
contain scannable Device objects.  Sending a "read" message to a
Device causes it to return the scan vector data from its scan ring in
the form of a ScanVector object.  A "read" to a Board object causes it
to "read" each of its Device objects and return a vector of ScanVector
objects.  Hopefully you get the idea.

A paper describing all of this will appear in a future issue of IEEE
Design & Test of Computers magazine (probably the first issue of
1993).

In the meanwhile, you might try these papers:

	B. I. Dervisoglu and Mark Keil, "ATLAS/ELA: Scan-Based
	Software Tools For Reducing System Debug Time in a
	State-of-the-Art Workstation," Proceedings of the 26th
	ACM/IEEE Design Automation Conference, 1989, pp. 718-721.

	K.T. Kornegay and R.W. Brodersen, "A Test Controller Board for
	TSS", Proceedings of the First Great Lakes Symposium on VLSI,
	1991, pp.  38-42.

	Reilly, John and others.  "Processor Controller for the IBM
	3081", IBM Journal of Research and Development, 26: 22-29,
	1982.

	A.J. van de Goor and J. A. M. van Tetering, "A low-cost tester
	for boundary scan", Microprocessors and Microsystems, Vol. 15,
	No. 2, March 1991, pp. 82-89.


The Reilly paper is excellent, as it describes ways to deal with
scannable entities symbolically, that is, by name.  Both papers by
Dervisoglu that I mention discuss scan software to some extent, and
you will find them helpful.

Good luck.  Feel free to contact me by email if you have specific
questions.

-steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

In article <BxD9CM.C1@scd.hp.com> vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:
>
>One issue with 1149.1 is that every chip has its own scan controller.
>This is fine for chip test, but for board test it would better if
>there were only one controller for all the chips on the board.  See
>
>	Dervisoglu, B.I., "Scan Path Architecture For Pseudorandom
>	Testing", IEEE Design & Test of Computers, 6(4): pp. 32-48,
>	1989.
>
>	Dervisoglu, B.I., "Features of a Scan and Clock Resource Chip
>	For Providing Access to Board-Level Test Functions", Journal
>	of Electronic Testing: Theory and Applications, 2: pp.
>	107-115, 1991.

There is not one scan controller per chip.  There is one TAP controller
for each chip that has boundary scan implemented.  All chips do not
need to implement boundary scan, and seldom - if ever - do you find a
board where they all do.  Depending upon the implementation, there may
be a scan controller on the board, but usually not.  Scan control is
implemented in a computer that has a scan control chip (usually -
though this can be done in SW), and SW used for testing and diagnosis.

NOW...  I WANT TO TAKE EXTREME ISSUE WITH YOUR INFERENCE THAT THE
APOLLO 10K ARCHITECTURE FOR SCAN IS SOMEHOW BETTER THAN BOUNDARY SCAN.

The P1149.1 standard is the engine that is driving the future of
built-in test.  Departures from this standard slow the process of
progress.  The issue is not whether something is better (and I doubt
that your example qualifies) but whether the standard is "good
enough".  If it is good enough, it should be used, and if it is used
people will find that it has much more capability than is visible on
the surface.  For example, did you know that ATT uses boundary scan as
the basis for communication of internal BIST results from chips to
boundary scan controllers in production test applications?  Did you
know that this use, and extensions of this methodology, are in
development at many major sites in the US and elsewhere?

Did you know that a substantial infrastructure - involving HW and SW is
being created around P1149.1 and its extensions, an infrastructure that
will not support other architectures and scan methodologies?  Do you
think it is smart and cost effective and productive to depart from the
standard under these conditions?

Arnold Frisch
Tektronix Laboratories

In article <12860@sail.LABS.TEK.COM> arnief@sail.LABS.TEK.COM (Arnie Frisch) writes:
>NOW...  I WANT TO TAKE EXTREME ISSUE WITH YOUR INFERENCE THAT THE
>APOLLO 10K ARCHITECTURE FOR SCAN IS SOMEHOW BETTER THAN BOUNDARY SCAN.
>
>The P1149.1 standard is the engine that is driving the future of
>built-in test.  Departures from this standard slow the process of
>progress.  The issue is not whether something is better (and I doubt
>that your example qualifies) but whether the standard is "good
>enough".  If it is good enough, it should be used, and if it is used
>people will find that it has much more capability than is visible on
>the surface.  For example, did you know that ATT uses boundary scan as
>the basis for communication of internal BIST results from chips to
>boundary scan controllers in production test applications?  Did you
>know that this use, and extensions of this methodology, are in
>development at many major sites in the US and elsewhere?
>
>Did you know that a substantial infrastructure - involving HW and SW is
>being created around P1149.1 and its extensions, an infrastructure that
>will not support other architectures and scan methodologies?  Do you
>think it is smart and cost effective and productive to depart from the
>standard under these conditions?

Do you realize that the DN10000 scan architecture was developed before
1149.1?  How can you accuse us of "departing from the standard" when
the standard wasn't even around when we did this work?

The DN10k scan architecture and 1149.1 are different beasts.  Each has
its good features and not-so-good features, and each does some things
better than the other.  Having written hundreds of thousands of lines
of scan software, I personally believe that the DN10k architecture is
easier for software to deal with when it comes to board-level testing.
But that is only my opinion, and it could be wrong.  But you will
allow me to have my own opinions, won't you, Arnie?  Or is there only
one standardized opinion, too?

1149.1 is the best standard we have today, but it is not the be-all
and end-all of scan test architectures.  It is worthwhile for anyone
involved in scan testing to study the DN10000 scan architecture and
others so that their good features can be incorporated into the next
scan test standard.  Do you think it is "smart and cost effective and
productive" to reinvent the wheel?

Chill out, Arnie.

-steve

vinoski@ch.apollo.hp.com (Stephen Vinoski) writes:

>This is fine for chip test, but for board test it would better if
>there were only one controller for all the chips on the board.  See

A good time for me to clarify our present test philosophy...

Actually, that is what we hope to accomplish.  By placing a Micro-
processor and one Test Bus Controller with multiple scan path linkers
on the board, we can apply stimuli vectors, saved in an EPROM, to the 
"boundary" of one functional block of the board, then observe the 
response by collecting the resultant vector on other scan paths in 
other functional blocks.  

This "embedded test" will be used for connectivity testing between 
ASIC's where the number of functional ASIC stimuli vectors would be 
too high to apply in a timely fashion after power-up and before the 
system ready state.

In case folks where wondering, yes there are plenty of non-scan parts
on this board that I also have to write tests for.  That's the part 
I've done before.  And yes we will have approximately 6K scanable ASIC 
pins, plus some scanable registers and fifo's on the board as others 
have questioned. Sounds exciting I know!

My final goal with the embedded test at power-up is only to achive a 
level of funtionality confidence, and not complete ASIC functionality.  
Thus the 1149.1 architecture features that we install will contain the 
"hooks" to perform more thorough testing on the manufacturing floor using
a non-resident test processor in a PC for instance, as a diagnostic tool
in module test or burn-in.  Prior to this step, the ASIC's will have been
tested at the foundary before pc board assembly and at the ATE station 
after pc board assembly.

>In a previous life I wrote a lot of scan software.  I found that the
>use of object-oriented software development techniques greatly reduces
>the chances for errors while allowing relatively powerful tools to be
>developed quickly and reused for different applications.

Others have mentioned the Object Oriented approach as a wise choice.
Thank you for the advice and the references.

Actually!, Thank you all for the many responses.  Between all the phone 
calls with new vendor product leads, and all the new reading material,
a a couple of well deserved vacation days, I've not had enough time to
respond to everyone.  

Let's keep this discussion going.  I still have a ton of questions...

Ed Kearns
BBNASD
Bellevue,Washington