Cheops System Diagnostics

memtest

This program tests the Cheops P2 module memory. It will test the region described by the command line arguments, reporting to the user any errors found. This program can be run for one to four billion passes, with infinite loop selected by specifying zero passes. It sequentially tests all of the memory regions specified on the command line on every pass.

Usage:

       memtest [ -specific < quad_num>    < size_bytes>    ] # test region of mem.
               [ -bank < bank_num>    [< bank_num>   ]]      # test P2 bank
               [ -type (byte|short|long|quad) ]      # word size to use
               [ -passes < number_of_tests>    ]
               [ -errors < maximum_number_before_exiting>    ]
               [ -debug ]              # turn on debugging messages
 

The < size> of a region is specified in bytes, using hexadecimal notation.

glbtest

This program tests the Cheops P2 memory global bus port. It does this by performing bit pattern and address test in one of two ways:

1. Writing the memory through the local bus, and reading it through the global bus port (read tests).
2. Writing to the memory using the global bus port, then verifying write using the local bus port (write tests).

This program assumes that the local bus port of the memory has been tested and works perfectly (see memtest).

Usage:

       glbtest [< card_number>    [< bank_number>    [< size_in_kilolongs>   ]]]

< card_number>

The module id of the P2 this test is being run on. ( Default: 0 )

< bank_number>

The memory bank to use in the test. ( Default: 2 )

< size>

The size of the test, in kilobytes divided by four. (Default: 2000, or 8 Megabytes )

floodtest

This is THE definitive Cheops Flood Controller test program. Unlike fdb, FloodTest is intended to exhaustively test the functionality of the P2 flood controllers. If a problem is detected, fdb may then be used to actually probe around in the circuit.

Usage:

       floodtest [ -quals (real|zoom|mult|color) | -random ]
                 [ -flood < channel>   [   < channel>   ]   ...   ]
                 [ -errors < maximum_number_before_exiting>   ]
                 [ -ok (0|1|2) ]  # preferred ok channel
                 [ -addr ]        # print address of error
                 [ -verbose ]     # indicate successful transfers
                 [ -debug ]       # turn on flood lib debugging
             (All options names may be shortened to one letter.)

FloodTest operates in two different modes, selected either by the -quals or the -random argument. If in random mode, the parameters of the transfer being tested are selected at random from the set of possible (not necessarily probable !) parameters.

If in quals mode (short for qualification), the tests done are defined in suites (where a typical suite consists of a set of 4 to 10 different parameters.) The pre-defined suites (see the source code for easy directions on how to add more) are :

real

full functionality test suite

large

test large transfers

small

test small transfers

mult

test transfers with multiple sources and dests.

color

test 3 src to 3 dst transfer

zoom

test zoom (replicate and interpolate) functionality

scope

for oscilloscope debugging

cshow

cshow is invaluable in determining the health of both the P2 Nile Bus interface, the backplane Nile Bus, and the O1 Nile Bus interface.

This program takes a file, loads it into the local memory, then transfers it over the nile bus. The image must currently have a size of 1024 (hor) x 512 (ver). Alternatively, the image to be transferred can be a synthesized test pattern (selected either with the -p argument or by default.)

Usage:

     cshow [< filename> ]
           [-p < pattern number> ]   # generate pattern (see below)
	   [-b < nile_bank> ]        # Nile bank of P2 to use
	   [-c < output_module> ]    # output module to use
           [-d < x_size>  < y_size> ]  # size of transfer

The -pattern option determines the data pattern used for the transfer, and can greatly influence which errors are detected. Here are the pattern numbers :

• 0 - Solid pattern (white)
• 1 - Sweeps from black to a color
• 2 - Diagonal sweeps from black to a color
• 3 - Datapath stress test (toggle)

cspace

This program tests the Color Space Converters on a Cheops P2 processor module using JUST the resources available on a P2. The memory and flood controllers MUST be working for this program to stand a chance of succeeding.

Usage:

       cspace [ -chan < channel>  [ < channel>  ] ]     # 0, 1 or 2
              [ -errors < maximum_number_before_exiting>  ]
              [ -passes < number_of_test_passes>  ]
              [ -oscope ]      # loop infinitely, don't error check
              [ -bypass ]      # bypass the cspace conv.
              [ -debug ]       # turn on library debugging

tengtest

dct

This fundamentally unsupported program tests the DCT stream processor.

Usage:

       dct < dev_num>

remap

mojotest

There are several programs that comprise the mojo tests located in ${CHEOPS_BASE}/local/src/diag/mojotest/ - one for each configuration mode currently supported. Unfortunately, they all use Norman, precluding their use in REAL low level debugging.

There is also a top level script that runs all of the tests to determine if a Mojo stream processor is healthy. The stream_proc_slot argument refers to which P2 stream processor daughtercard slot ([0,2]) the Mojo being tested is located in.

Usage:

      mojotest < stream_proc_slot>

motest

This motion estimator test program writes one frame of data in memory, copy it into another frame memory which is shifted from (-8, -8) to (7, 7).

Usage:

    motest [ -x < xdim>    ]
           [ -y < ydim>    ]
           [ -mx < xvec>    ]
           [ -my < yvec>    ]
           [ -mode ]
           [ -V ]

filttest

Program to test the filter card stream processors, looking for blatant errors. It should be able to detect register R/W errors and localize errors to within a chip on the card. The stream_proc_slot argument refers to which P2 stream processor daughtercard slot ([0,2]) the filter card being tested is located in.

Usage:

        filttest < stream_proc_slot>   
 	[-data < data>    ]
	[-coeff < coeff>    ]
	[-loop ][ -v ]

floodinttest

dmatest

fdb

This program tests the operation of a Cheops P2 Module Flood Controller. But's that not all. It slices, dices, and fills memory with any number of useful data patterns for your probing pleasure. It checks to see if a transfer started, or ended. It walks the dog and signs UROP timecards. And all for free !

tdb

scope

busconfig

scsi

Diagnostics for debugging SCSI do exist (in ${CHEOPS_BASE}/local/src/diag/scsi/), but they aren't that great.

To quickly determine if you have a SCSI problem, try the scsi_diag command (no command line arguments.) It is a shell script that uses chload, chread, and diff to test for data and handshaking problems. Make sure that the memory that it uses for the test (usually bank 4-7) is installed and working.