A quick word on shell scripts. Both Sproing and its utility application, Dict2ddb, are stand-alone programs, but shell scripts that call them are an easy way to automate tasks, and provide documentation on what you may be trying to accomplish. Shell scripts I used to generate the example files are all listed in the appendix. For this tutorial I’ll stick to the command line (I’m assuming csh is the shell).


Bridge Fault Diagnosis

First the .ddb’s, the dictionary database files, need to be created. We’ll start with the behaviors we’re attempting to diagnose. Assuming they are in dictionary format (see Special Appendix) we create a behavior database.

% dict2ddb bridge.dictionary bridge.ddb –Obrdg.log –b –v -p

Next we create the composite signatures from the stuck-at dictionary:

% dict2ddb stuckat.dictionary stuckat.ddb –Osa.log –s –v -p

Besides the files being of different format, dict2ddb needs to know what type of file it is converting, thus the –b/-s (bridge/stuck-at) flag. The –v flag verifies the stored information, and the –p flag reports progress to standard output. –Ofilename writes status information to a log file.

Once the stuck-at dictionary is in database format, the composite bridging fault dictionary needs to be created. We use Sproing to do this, but not in its diagnostic capabilities:

% sproing -sstuckat.ddb –fbridge.faultlist \

-iIDDQ.dictionary -Ocbd.log –Ccbd.ddb

The –sfilename flag reads in the stuck-at database. –ffilename reads in the list of possible faults. In this case, bridge.faultlist could be a file generated by Carafe and is that list of potential realistic bridging sites. The –i flag is optional, but the IDDQ dictionary is used to identify more restricted (non-detecting) vectors. This will create a better composite dictionary. The –Ofilename is again the log file, and the

–Cfilename here creates a file called cbd.ddb, which is the composite bridging dictionary.

With this composite dictionary database and the behavior dictionary database we can now do the diagnosis:

% sproing -bbridge.ddb –ccbd.ddb –Ddiagnoses –Oresults

Where –bfilename is the input behavior database, and –cfilename is the input candidate database. The diagnoses file will have the list of candidate faults, i.e. the diagnosis, and the results file will have information about what went on, and how well the diagnosis went (see Output file: Diagnosis File & Output File: Results File sections for more information).


Node (composite stuck-at fault) diagnosis

Diagnosis based on faulty nodes, or composite stuck-at fault diagnosis, requires the same basic steps as bridge fault diagnosis, but because of the different inputs, different option flags are needed. First the dictionary of behaviors to be diagnosed needs to be converted into database format:

% dict2ddb tester.dictionary tester.ddb –Otest.log –s –v -p

Next we create the stuck-at database from the simulated stuck-at dictionary:

% dict2ddb stuckat.dictionary stuckat.ddb –Osa.log –s –v –p

Where again, -s means create a stuck-at database, -v verifies work done, and -p prints progress to the screen.

Sproing is used to create a composite stuck-at dictionary database:

% sproing -sstuckat.ddb -Ocbd.log –Ncsad.ddb

csad.ddb is now the candidate list of faults.

Sproing is then used to do the diagnosis:

% sproing -btester.ddb –ncsad.ddb –Ddiagnoses –Oresults


Stuck-at fault diagnosis

For stuck-at diagnosis, the behavior dictionary is created the same way as in nodal diagnosis:

% dict2ddb tester.dictionary tester.ddb –Otest.log –s –v -p

And the stuck-at database is created similarly:

% dict2ddb stuckat.dictionary stuckat.ddb –Osa.log –s –v –p

But, a composite dictionary is not created.

To diagnose:

% sproing -btester.ddb –sstuckat.ddb –Ddiagnoses –Oresults \


The –stuckat at the end is important and is what determines this is stuck-at diagnosis vs. node diagnosis.