🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lsi.testing
Article #58

Re: Boundary Scan JTAG 1149.1 Experience?

#58
From: Stephen Vinoski
Date: Sat, 07 Nov 1992 22:05
108 lines
5724 bytes
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.
Technical Details
Message-ID: <BxD9CM.C1@scd.hp.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!unogate!mvb.saic.com!ncr-sd!sdd.hp.com!scd.hp.com!hpscdm!hpscdc!vinoski
References: <lfatgtINNj5@news.bbn.com>

Show Full Headers
Complete Article Headers
Newsgroups: comp.lsi.testing
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!usc!news.service.uci.edu!unogate!mvb.saic.com!ncr-sd!sdd.hp.com!scd.hp.com!hpscdm!hpscdc!vinoski
From: vinoski@ch.apollo.hp.com (Stephen Vinoski)
Subject: Re: Boundary Scan JTAG 1149.1 Experience?
Message-ID: <BxD9CM.C1@scd.hp.com>
Keywords: help
Sender: news@scd.hp.com (News Account)
Organization: Hewlett-Packard Corporation, Chelmsford, MA
References: <lfatgtINNj5@news.bbn.com>
Date: Sat, 7 Nov 1992 22:05:09 GMT
Lines: 108