NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lsi/testing/270

Text File | 1992-11-08 | 5.5 KB | 121 lines

Newsgroups: comp.lsi.testing
Path: 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: [e-mail] (Stephen Vinoski)
Subject: Re: Boundary Scan JTAG 1149.1 Experience?
Message-ID: <[e-mail]>
Keywords: help
Sender: [e-mail] (News Account)
Organization: Hewlett-Packard Corporation, Chelmsford, MA
References: <[e-mail]>
Date: Sat, 7 Nov 1992 22:05:09 GMT
Lines: 108

In article <[e-mail]> [e-mail] (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  [phone]   [e-mail]
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.