Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!afgg6490
From: afgg6490@uxa.cso.uiuc.edu
Newsgroups: comp.arch
Subject: Re: VME Bus Standard
Message-ID: <112400009@uxa.cso.uiuc.edu>
Date: 4 Dec 89 14:05:00 GMT
References: <11759@phoenix.Princeton.EDU>
Lines: 21
Nf-ID: #R:phoenix.Princeton.EDU:11759:uxa.cso.uiuc.edu:112400009:000:1022
Nf-From: uxa.cso.uiuc.edu!afgg6490    Dec  4 08:05:00 1989


>[9] Built In Self Test ( Built In Test Equipment )
>
>Each board should have BIST (BITE) features. The bus should be
>involved: the system should be able to force a board into BIST mode.
>This also puts the board's interface into BI mode, so that boards
>which temporarily/permanently aren't useful, won't be called upon.
>There is a question as to how a board comes back out of BIST mode,
>depending on why it went in, and what the result was. Also, if the
>board has failed, how much can the system find out about the failure.

Don't oblige potentially expensive features.
Encourage them. Support them.
But do not oblige boards to support a complicated BIST protocol.
I've seen boards spend a lot of logic supporting a BIST interface,
only to have no test hardware at all. The BIST interface could have
been used more productively on more basic things, like ECC.

Put another way: accept "No" responses to external BIST requests.
A simple No.
Not a No that needs to be bundled in some complicated packedt and returned.