Hello,
Im a student doing some under-graduate work for my final year project.
It involves moving Bscan functionality onto the board so we kind of
augment the DUT with some hardware for test purposes (remote testing
is a big incentive to move towards this). Hence we generate JTAG on
the board itself and talk to the test manager(PC S/W) using some
faster protocol like LAN for instance.

Curently the test patterns for testing a board (both with bscan and
non-bscan components) are stored on the PC memory. To that end, all
sorts of diagnostic features for determing and localizing the fault
down to the device pin are implemented in the Test Manager.

Now have moved a couple of functions from the Test Manager to an on-
board module. This module is a mixed H/W - S/W module. But the
solution is rather rudimentary and theres no fault tracing implemented
on the module yet. Plus we still route the test patterns from the Test
manager. We want that to be stored somehow on the board itself.

Now thats what im supposed to think about. So the first thing that
comes to my mind is how would one go about storing the various
patterns corresponding the various test choices the end user can make.
The H/W module can generate the JTAG signals for the UUT (unit under
test). And it takes with the S/W module which 'steers' the H/W module
and is the brain of the board as far as DFT is concerned.

Now since this is my first ever real life work, im a bit confused
about how to approach this problem. I have started reading some papers
on the subject of fault dictionary compaction and means of testing
clusters (group of Non-bscan components) using bscan components
present on the board. Most of them are by P. Hansen from teradyne. I
think the first problem we'd face is storage of test data. Hence the
choice above.

By the way,what is really meant by 'fault dictionaries' since we would
be only storing the expect values not a sort of a LUT which points to
faults and prints human readable messages. Could anyone please
elaborate?

I would kindly request people on the group to analyze my approach to
this and guide me a little as where I should be looking towards. Since
this work encompasses DFT techniques and a lot of thinking with
regards to the embedded solution as well, i suppose people on this
forum could certainly have things to say to help me move in the right
direction

Any suggestions would be highly appreciated
Regards and thanks for reading through this rather long post,
AB

On 5 Aug, 07:55, DFT_noob <aijazba...@gmail.com> wrote:
> Hello,
> Im a student doing some under-graduate work for my final year project.
> It involves moving Bscan functionality onto the board so we kind of
> augment the DUT with some hardware for test purposes (remote testing
> is a big incentive to move towards this). Hence we generate JTAG on
> the board itself and talk to the test manager(PC S/W) using some
> faster protocol like LAN for instance.
>
> Curently the test patterns for testing a board (both with bscan and
> non-bscan components) are stored on the PC memory. To that end, all
> sorts of diagnostic features for determing and localizing the fault
> down to the device pin are implemented in the Test Manager.
>
> Now have moved a couple of functions from the Test Manager to an on-
> board module. This module is a mixed H/W - S/W module. But the
> solution is rather rudimentary and theres no fault tracing implemented
> on the module yet. Plus we still route the test patterns from the Test
> manager. We want that to be stored somehow on the board itself.
>
> Now thats what im supposed to think about. So the first thing that
> comes to my mind is how would one go about storing the various
> patterns corresponding the various test choices the end user can make.
> The H/W module can generate the JTAG signals for the UUT (unit under
> test). And it takes with the S/W module which 'steers' the H/W module
> and is the brain of the board as far as DFT is concerned.
>
> Now since this is my first ever real life work, im a bit confused
> about how to approach this problem. I have started reading some papers
> on the subject of fault dictionary compaction and means of testing
> clusters (group of Non-bscan components) using bscan components
> present on the board. Most of them are by P. Hansen from teradyne. I
> think the first problem we'd face is storage of test data. Hence the
> choice above.
>
> By the way,what is really meant by 'fault dictionaries' since we would
> be only storing the expect values not a sort of a LUT which points to
> faults and prints human readable messages. Could anyone please
> elaborate?
>
> I would kindly request people on the group to analyze my approach to
> this and guide me a little as where I should be looking towards. Since
> this work encompasses DFT techniques and a lot of thinking with
> regards to the embedded solution as well, i suppose people on this
> forum could certainly have things to say to help me move in the right
> direction
>
> Any suggestions would be highly appreciated
> Regards and thanks for reading through this rather long post,
> AB

You seem to enjoy reading papers, but are you aware of a companies
like firecron and assett intertech. They have a product which does
exactly what you are trying to.
The real world doesn't tend to use words like "fault dictionary
compaction" because if a salesman can't easily explain something then
an engineer will not trust it (or buy it). We tend to be a cynical
bunch, particularly w.r.t. software.

The standard method is something like.

1) Use software such as scanworks from assett intertech to create the
test vectors. Any board can be highly interconnect tested using less
than twenty sets of vectors using some clever maths (this might be
what fault dictionary compaction means). You end up with an SVF file
which is industry standard and documented on the assett site.
2) Your JTAG hardware (such as firecron will sell you) injects the
vectors in the SVF into your UUT and records the results (probably as
an SVF again)
3) If the results are incorrect the SVF is passed back to the ASSETT
software which will work out the fault, if you buy the right options
it will even open a graphic of your pcb and show you your dry joint or
whatever.

Colin

Hello,
Well..we do have the scanworks spftware suite at our disposal and we
are just experimenting with this new method so to speak. The guys who
worked on this before me have been successfully able to have some kind
of an embedded solution to this and they have been able to write
software that runs on a micro-processor which is able to talk to a H/W
module wich can generate the JTAG signals.

My first goal is to think about how one could have an embedded fault
tracing mechanism so that it wont have to go back to the PC software
to diagnose the error.

I hope this would help you to understand what I am exactly looking for
at the moment.

Regards,
AB

On Aug 5, 9:59=A0am, "colin_toog...@yahoo.com" <colin_toog...@yahoo.com>
wrote:
> On 5 Aug, 07:55, DFT_noob <aijazba...@gmail.com> wrote:
>
>
>
>
>
> > Hello,
> > Im a student doing some under-graduate work for my final year project.
> > It involves moving Bscan functionality onto the board so we kind of
> > augment the DUT with some hardware for test purposes (remote testing
> > is a big incentive to move towards this). Hence we generate JTAG on
> > the board itself and talk to the test manager(PC S/W) using some
> > faster protocol like LAN for instance.
>
> > Curently the test patterns for testing a board (both with bscan and
> > non-bscan components) are stored on the PC memory. To that end, all
> > sorts of diagnostic features for determing and localizing the fault
> > down to the device pin are implemented in the Test Manager.
>
> > Now have moved a couple of functions from the Test Manager to an on-
> > board module. This module is a mixed H/W - S/W module. But the
> > solution is rather rudimentary and theres no fault tracing implemented
> > on the module yet. Plus we still route the test patterns from the Test
> > manager. We want that to be stored somehow on the board itself.
>
> > Now thats what im supposed to think about. So the first thing that
> > comes to my mind is how would one go about storing the various
> > patterns corresponding the various test choices the end user can make.
> > The H/W module can generate the JTAG signals for the UUT (unit under
> > test). And it takes with the S/W module which 'steers' the H/W module
> > and is the brain of the board as far as DFT is concerned.
>
> > Now since this is my first ever real life work, im a bit confused
> > about how to approach this problem. I have started reading some papers
> > on the subject of fault dictionary compaction and means of testing
> > clusters (group of Non-bscan components) using bscan components
> > present on the board. Most of them are by P. Hansen from teradyne. I
> > think the first problem we'd face is storage of test data. Hence the
> > choice above.
>
> > By the way,what is really meant by 'fault dictionaries' since we would
> > be only storing the expect values not a sort of a LUT which points to
> > faults and prints human readable messages. Could anyone please
> > elaborate?
>
> > I would kindly request people on the group to analyze my approach to
> > this and guide me a little as where I should be looking towards. Since
> > this work encompasses DFT techniques and a lot of thinking with
> > regards to the embedded solution as well, i suppose people on this
> > forum could certainly have things to say to help me move in the right
> > direction
>
> > Any suggestions would be highly appreciated
> > Regards and thanks for reading through this rather long post,
> > AB
>
> You seem to enjoy reading papers, but are you aware of a companies
> like firecron and assett intertech. They have a product which does
> exactly what you are trying to.
> The real world doesn't tend to use words like "fault dictionary
> compaction" because if a salesman can't easily explain something then
> an engineer will not trust it (or buy it). We tend to be a cynical
> bunch, particularly w.r.t. software.
>
> The standard method is something like.
>
> 1) Use software such as scanworks from assett intertech to create the
> test vectors. Any board can be highly interconnect tested using less
> than twenty sets of vectors using some clever maths (this might be
> what fault dictionary compaction means). You end up with an SVF file
> which is industry standard and documented on the assett site.
> 2) Your JTAG hardware (such as firecron will sell you) injects the
> vectors in the SVF into your UUT and records the results (probably as
> an SVF again)
> 3) If the results are incorrect the SVF is passed back to the ASSETT
> software which will work out the fault, if you buy the right options
> it will even open a graphic of your pcb and show you your dry joint or
> whatever.
>
> Colin

DFT_noob wrote:
> 
> Well..we do have the scanworks spftware suite at our disposal and
> we are just experimenting with this new method so to speak. The
> guys who worked on this before me have been successfully able to
> have some kind of an embedded solution to this and they have been
> able to write software that runs on a micro-processor which is
> able to talk to a H/W module wich can generate the JTAG signals.
> 
> My first goal is to think about how one could have an embedded
> fault tracing mechanism so that it wont have to go back to the PC
> software to diagnose the error.
> 
> I hope this would help you to understand what I am exactly
> looking for at the moment.

Please do not top-post.  Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material.  See the following links:

  <http://www.catb.org/~esr/faqs/smart-questions.html>;
  <http://www.caliburn.nl/topposting.html>;
  <http://www.netmeister.org/news/learn2quote.html>;
  <http://cfaj.freeshell.org/google/>;  (taming google)
  <http://members.fortunecity.com/nnqweb/>;  (newusers)

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>;
            Try the download section.