🚀 go-pugleaf

In article <18848@ksr.com> chuck@ksr.com (Chuck Shavit) writes:
>
>Dear netters,
>
>Writing ATPG and other testing-related tools in object oriented languages
>(C++ comes to mind) seems like a good idea.  Did anyone in NetLand actually
>do it?

A good idea?  Why, it's a great idea! :-)

For the Apollo DN10000 I wrote an interactive symbolic hardware
debugger two years ago that allowed access to every scan path in the
system under test via a local area network.  Users could group
non-contiguous scan bits into logical registers for interactive
symbolic access and control.  This system was designed using
object-oriented (OO) techniques and implemented using C++.  (The
software implementing the command line interface is called the Tool
Command Language (Tcl) from Dr. John Ousterhout at Berkeley, see
comp.lang.tcl.  This portion was not written in C++.)

A system of this sort was attempted two or three times before I tried
it, and success was very limited each time.  I personally believe that
my attempt ended up being highly successful due to my use of OO and
C++.  I seriously doubt that I could have completed the implementation
had I used C.  Some might argue that anything one can do in C++, one
can do in C, and they'd be partially correct.  People who say such
things do not realize how valuable compiler support for OO techniques
really is.

The use of OO and C++ for this project paid off when we realized that
we needed a translator that could convert ATPG test patterns into a
format suitable for our offline scan test executive program.  I was
able to simply replace the network communications objects in the
debugger program mentioned above with objects allowing output to
files.  I then augmented the command line interface with several
commands specific to the translator requirements, and that was it.
Talk about software reuse!

The key is that when using OO techniques you end up modeling the
objects that exist in your problem domain.  The alternative
algorithmic techniques, as Grady Booch says, merely "highlight the
ordering of events."* Once you have suitably modeled the objects in
your problem domain, those objects can readily be reused to solve
multiple problems in that domain.  This is exactly what happened when
I converted the debugger into a test translator.  The objects in my
scan testing problem domain, such as Devices, Boards, ScanPaths,
ScanVectors, etc., are the same for both problems, so I reused almost
all of my debugger code for the translator solution.  The behaviors
exhibited by these objects are essentially independent of any one
specific problem.

Finally, the problem domains of hardware design and test are very easy
to model with OO techniques, since they are inherently
object-oriented.  I'm sure many others have pointed this fact out
before.

-steve

*Object-Oriented Design With Applications.
 Grady Booch.
 The Benjamin/Cummings Publishing Company, Inc.
 1991
 ISBN 0-8053-0091-0

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