PSD TESTS MENU
--------------
 	1.  Utilities/
 	2.  Node Tests/
 	3.  Message Network Tests/
 	4.  MIO Module Tests/
 	5.  SCSI Device Tests/
 	6.  HiPPI Module Tests/

NOTE:  The back slash (/) immediately following a test name indicates
       that the test is a directory and that there are a series of
       tests contained within that directory.  Any test without a
       back slash indicates an individual test.


HIPPI TESTS
-----------

   The HIPPI Module Test menu contains tests which verify the HIPPI
   expansion board and its ability to interface with the GP Node.

   The HIPPI Module Tests menu is shown followed by a description
   of each test:

      	1. Register Tests/
      	2. Direct FIFO Tests/
      	3. Node Addressing/Memory Tests/
      	4. Block FIFO Tests/
      	5. Source/Destination Loopback Tests/
      	6. Parity/Node Interaction Tests/


Register Tests/
   The Register Tests verify the registers on the HIPPI Expansion
   board. 

Register / 960 Self Test
   This test examines the i960's FAIL signal to determine whether
   the i960 passed its internal power-on self test. The test reads
   the signal's state through a bit in the source FIFO status register.

Register / Diagnostic Control Register
   This test avoids changing the D_PDRV bit to prevent FPGA corruption.
   This test will clear most register bits after testing completes,
   but leaves the LED bits in their previous state and leaves the
   FIFO LD bits high. 

Register / Source Control/Status Register
   This test verifies only those register bits that are writable,
   excluding the MSEL 1 bit (to prevent the source INTERCONNECT signal
   from going active on the HIPPI). The register is cleared after
   testing completes. 

Register / Destination Control/Status Register
   The test verifies only those register bits that are writable (the
   file least-significant bits). The test requires two passes because
   the CONIN bit has state dependencies with other register bits.
   The register is cleared after testing completes. 

Register / DMA Address Counter Register
   The DMA Address Counter Register Test verifies only those register
   bits that are writable. The register is cleared after testing completes.

Register / DMA Transfer Counter Register
   The DMA Address Counter Register Test verifies only those register
   bits that are writable. The register is cleared after testing completes.

Register / DMA Control/Status Register
   The DMA Control/Status Register Test verifies only those register
   bits that are writable. This test "walks" a one across all writable
   bits. It does this check twice to provide good transition fault
   coverage. The register is cleared after testing completes.


Direct FIFO Tests/
   The Direct FIFO Tests verify the data path to the FIFO's, internal
   RAM arrays, read/write pointers, fixed flag logic, programmable
   flags and the data path between the Source/Destination FIFO's at
   speed. 

Direct FIFO / Source FIFO
   This test verifies correct operation of the data-path and tag FIFO
   devices for the source channel. It adapts an algorithm that detects
   all stuck-at and transition faults in the internal RAM arrays,
   read / write pointers, and fixed flag logic. The algorithm has
   an N2 performance characteristic, so performance may be an issue
   if hardware upgrades use larger FIFO devices. The read / write
   arbitration logic or the 9th bit in the data paths used for parity
   are not checked by this test.

   Following is a description of the test algorithm as adapted for
   the HIPPI controller. This algorithm is applied to all FIFO devices
   on the channel simultaneously.
   1. 	Reset the FIFO and verify that the Full and Empty flags are
        in the correct states. Also verify that the multiplexer bit (for
        selecting the high or low 32-bit word) selects the low side.
   2.	Fill the FIFO with zeros and verify that the Full flag is set.
        Drain the FIFO and verify that the Empty flag is set.
   3. 	Write one word and verify that the Empty flag is clear. Read
        one word and verify that the Empty flag is set. Also re-verify
        the multiplexer bit state.
   4. 	Write and read march_32 pattern. This step verifies external
        data paths and buffers.
   5. 	Write an 8-bit ascending pattern four times to fill the FIFO.
        Read all data from the FIFO and verify that it's correct. Monitor
        the Empty and Full flags at all times for erroneous transitions.
   6.	Fill the FIFO with four 256-byte blocks of data, with the data
        identical within the block but differing between blocks. Read back
        to verify that the upper two address bits in the internal RAM array
        work correctly.
   7. 	Write one word and read it back. This increments the internal
        addressing pointers by one word.
   8. 	Repeat steps 6 and 7 1025 times (one more than the FIFO word
        size) to verify the fixed flag logic for all internal pointer
        values.

   When the test reports and error the subtest ID number corresponds
   to the step numbers in the preceding list (for example, subtest
   ID number 4 indicates the failure occurred during the external
   data path check). The iteration number in the message indicates
   the failure occurred after that many read or write operations in
   the current step.

Direct FIFO / Source FIFO Flags
   This test verifies the source FIFO's programmable almost-empty
   and programmable almost-full flags. The test uses patters from
   the minpat_16 set, masked to 10 bits, for a set of offset values.
   This test is identical for source an destination FIFO's.

Direct FIFO / Destination FIFO
   This test verifies correct operation of the data-path and tag FIFO
   devices for the destination channel. It adapts an algorithm that
   detects all stuck-at and transition faults in the internal RAM
   arrays, read / write pointers, and fixed flag logic. The algorithm
   has an N2 performance characteristic, so performance may be an
   issue if hardware upgrades use larger FIFO devices. The read /
   write arbitration logic or the 9th bit in the data paths used for
   parity are not checked by this test.

   Following is a description of the test algorithm as adapted for
   the HIPPI controller. This algorithm is applied to all FIFO devices
   on the channel simultaneously.
   1. 	Reset the FIFO and verify that the Full and Empty flags are
        in the correct states. Also verify that the multiplexer bit (for
        selecting the high or low 32-bit word) selects the low side.
   2. 	Fill the FIFO with zeros and verify that the Full flag is set.
        Drain the FIFO and verify that the Empty flag is set.
   3. 	Write one word and verify that the Empty flag is clear. Read
        one word and verify that the Empty flag is set. Also re-verify
        the multiplexer bit state.
   4. 	Write and read march_32 pattern. This step verifies external
        data paths and buffers.
   5. 	Write an 8-bit ascending pattern four times to fill the FIFO.
        Read all data from the FIFO and verify that it's correct. Monitor
        the Empty and Full flags at all times for erroneous transitions.
   6. 	Fill the FIFO with four 256-byte blocks of data, with the data
        identical within the block but differing between blocks. Read back
        to verify that the upper two address bits in the internal RAM array
        work correctly.
   7. 	Write one word and read it back. This increments the internal
        addressing pointers by one word.
   8. 	Repeat steps 6 and 7 1025 times (one more than the FIFO word
        size) to verify the fixed flag logic for all internal pointer
        values.

   When the test reports and error the subtest ID number corresponds
   to the step numbers in the preceding list (for example, subtest
   ID number 4 indicates the failure occurred during the external
   data path check). The iteration number in the message indicates
   the failure occurred after that many read or write operations in
   the current step.

Direct FIFO / Destination FIFO Flags
   This test verifies the source FIFO's programmable almost-empty
   and programmable almost-full flags. The test uses patters from
   the minpat_16 set, masked to 10 bits, for a set of offset values.
   This test is identical for source an destination FIFO's.

Direct FIFO / Source-Destination FIFO Loopback
   This test uses the controller's internal loopback feature to route
   data from the source FIFO directly into the destination FIFO. This
   tool also verifies the FIFO data paths at speed and also verifies
   some of the associated control logic. This test has the following
   steps:
   1. 	Use the current pattern sequence (by default minpat_32) to
        create enough test data in the controller's RAM to completely fill
        the source FIFO.
   2. 	Initialize the FIFO's.
   3. 	Enable the loopback mechanism and wait for several microseconds.
   4. 	Verify that the source FIFO is almost empty and the destination
        FIFO is almost full (the control logic stops the transfer when
        the destination FIFO is almost full).
   5. 	Read data from the destination FIFO one word at a time. Verify
        each word matches the corresponding work in the RAM-based test
        data buffer. Also verify that the destination FIFO contains the
        correct amount of data.


Node Addressing/Memory FIFO Tests/
   The Node Addressing/Memory FIFO Tests verify the upper address
   bits between the HIPPI Expansion board and the GP Node and that
   the i960 can access portions of the GP Node RAM. 

Node Addressing/Memory FIFO / Controller-Node Upper Address Bits
   This test sets and reads selected node memory locations across
   most of the GP node memory range to verify upper address bits between
   the HIPPI controller and the GP node. This tool is a cooperative
   test between i860 and i960 processors: the i860 writes the locations,
   the processors synchronize, and the i960 verifies the locations.

   The tool places incrementing data (starting with a value of one)
   from nodeBigBuf to nodeBigBuf plus nodeBigBufSize in the following
   locations:
   	o  Every 1 Kbyte for the first 16 Kbytes.
   	o  Every 16 Kbytes for the remainder of the first 1 Mbyte.
   	o  Every 1 Mbyte after the first 1 Mbyte.

Node Addressing/Memory FIFO / Controller-Node March RAM
   This test runs the MarchBCustom tool across a portion of the GP
   node's RAM. The test calculates the address range from global framework
   variables, testing from nodeMemtestBuf up to nodeMemtestBuf plus
   nodeMemtestBufSize.


Block FIFO Tests/
   The Block FIFO Tests verify the block read/write logic and DMA
   traffic when a remote source sends packets. 

Block FIFO / Node RAM-Controller Source FIFO
   This test performs a basic test of the block read logic and consists
   of the following steps:
   1. 	Fill 8 Kbytes at nodeBigBuf with the current pattern set.
   2. 	Block transfer the data from node memory into the source FIFO
        until all data is transferred or something goes wrong. Report an
        error it this step transferred less data than expected.
   3. 	Programmatically read data from the source FIFO and copy it
        to a local memory buffer. Verify that the FIFO contained the expected
        amount of data.
   4. 	Compare the data that's now in local memory with the expected
       values and report any differences.

Block FIFO / Controller Destination FIFO-Node RAM
   This test performs a basic test of the block write logic and consists
   of the following steps:
   1. 	Create an 8 Kbyte buffer in local memory using the current
        pattern set. Programmatically fill the destination FIFO from this
        buffer.
   2. 	Block transfer the data into node memory from the destination
        FIFO until all data is transferred or something goes wrong. Report
        an error it this step transferred less data than expected.
   3. 	Programmatically attempt to read data from the destination
        FIFO, discarding any data. Report an error is any data remained. 
   4. 	Compare the data that's now in local memory with the expected
        values and report any differences.

Block FIFO / Node RAM-Controller FIFO's-Node RAM
   This test uses blkFifoLoopbackCustom to transfer 256 Kbytes of
   data between two buffers in GP node memory. The source buffer is
   at nodeBigBuf and the destination buffer is 256 Kbytes beyond the
   source buffer. This tool uses blkFifoLoopback's data verification
   feature.

Block FIFO / Destination FIFO-Norm Packet-Even Number

   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source sends a packet containing an even number
   of 32-bit words. This test verifies that block writes correctly
   terminate under these circumstances. No HIPPI traffic occurs in
   this test.

Block FIFO / Destination FIFO-Norm Packet-Odd Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source sends a packet containing an odd number
   of 32-bit words. This test verifies that block writes correctly
   terminate under these circumstances. No HIPPI traffic occurs in
   this test. 

Block FIFO / Destination FIFO-Norm Packet-Abrupt End-Even Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source drops the REQUEST and PACKET signals
   simultaneously after sending and even number of 32-bit words. This
   test verifies that block writes correctly terminate under these
   circumstances. No HIPPI traffic occurs in this test.

Block FIFO / Destination FIFO-Norm Packet-Abrupt End-Odd Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source drops the REQUEST and PACKET signals
   simultaneously after sending and odd number of 32-bit words. This
   test verifies that block writes correctly terminate under these
   circumstances. No HIPPI traffic occurs in this test.

Block FIFO / Destination FIFO-Multiple Packet-Normal End-Even Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source sends several packets in one connection,
   with each packet containing an even number of 32-bit words.   This
   test verifies that block writes correctly terminate under these
   circumstances. No HIPPI traffic occurs in this test.

Block FIFO / Destination FIFO-Multi Packet-Norm End-Odd Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source sends several packets in one connection,
   with each packet containing an odd number of 32-bit words.   This
   test verifies that block writes correctly terminate under these
   circumstances. No HIPPI traffic occurs in this test.

Block FIFO / Destination FIFO-Norm Packet-Sequence Error-Even Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source causes a sequence error after sending
   an even number of 32-bit words. The test verifies that block writes
   correctly terminate under these circumstances. The test also verifies
   that the appropriate error interrupt occurs. HIPPI traffic does
   not occur in this test and the hardware implementation precludes
   actually creating this situation with a HIPPI loopback connection.

Block FIFO / Destination FIFO-Norm Packet-Sequence Error-Odd Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source causes a sequence error after sending
   an odd number of 32-bit words. The test verifies that block writes
   correctly terminate under these circumstances. The test also verifies
   that the appropriate error interrupt occurs. HIPPI traffic does
   not occur in this test and the hardware implementation precludes
   actually creating this situation with a HIPPI loopback connection.

Block FIFO / Destination FIFO-Normal Packet-Unexpected Disconnected-Even Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source unexpectedly disconnects after sending
   an even number of 32-bit words. The test verifies that block writes
   correctly terminate under these circumstances. The test also verifies
   that the appropriate error interrupt occurs. HIPPI traffic does
   not occur in this test and the hardware implementation precludes
   actually creating this situation with a HIPPI loopback connection.

Block FIFO / Destination FIFO-Normal Packet-Unexpected Disconnect-Odd Number
   This test checks the destination channel FIFO and DMA traffic that
   occur when a remote source unexpectedly disconnects after sending
   an odd number of 32-bit words. The test verifies that block writes
   correctly terminate under these circumstances. The test also verifies
   that the appropriate error interrupt occurs. HIPPI traffic does
   not occur in this test and the hardware implementation precludes
   actually creating this situation with a HIPPI loopback connection.



Source/Destination Loopback Tests/
   The Source/Destination Loopback Tests verify devices, packet transfers,
   connect, connect-reject, loopback, auto-connect, and S2021 signals.
   The loopback cable must be installed for some tests to exercise
   the logic. 

Source/Destination Loopback / Controller S2020 Self Test
   This Device Self-Test takes test data bursts from the FIFO and
   sends them out to the HIPPI bus (which is inactive but in a simulated
   connection state). The first byte of each burst is the expected
   LLRC of the preceding burst, with the first byte of the first burst
   being zero. An error occurs if the source device cannot establish
   the simulated connection or if the self test detects and LLRC error,
   a sequence error or a parity error. No HIPPI traffic occurs in
   this test.

Source/Destination Loopback / Controller S2021 Self Test
   This device self-test generates a walking 0s pattern on most of
   its TTL outputs when its MSEL bits specify the self-test mode.
   The tools stores these test patterns in the destination FIFO and
   verifies them. (Bit 11 in the diagnostic control register disables
   the normal FIFO input filtering mechanism, so all the test data
   will go into the FIFO.)

Source/Destination Loopback / Controller S2021 Ready-Burst-Buffer Counters
   This test verifies the ready, burst and buffer counters of the
   S2021. Data transfer does not occur with this test. 

Source/Destination Loopback / Controller Programmatic Connect
   This test verifies that the HIPPI controller channels can establish
   a connection under program control. Parts of the S2020, S2021 and
   FIFO control logic are verified with this test. This test does
   not verify the controller's autoconnect and autodisconnect logic.
   Data transfer does not occur with this test. This test will return
   a true value if a loopback connector is not present.

Source/Destination Loopback / Controller Programmatic Connect-Reject
   This test verifies that the HIPPI channels can correctly manage
   a rejected connection. Verification is accomplished programmatically,
   since the autoconnect logic unconditionally de-establishes connection
   on all requests. Data transfer does not occur with this test. This
   test will return a true value if a loopback connector is not present.

Source/Destination Loopback / Controller Programmatic Loopback
   This test transfers packets of various sizes between the source
   and destination channels. All connections are established program-
   matically, without using the controller's autoconnect or autodisconnect
   logic. Once the initial test for the loopback cable is passed,
   indicating that the loopback cable is present, each succeeding step in
   the test uses increasingly larger packet sizes. If a transfer completes
   successfully, the test compares data in the source and destination
   buffers to verify that data corruption did not occur. The packet
   sizes are diverse in magnitude and check boundary conditions for
   short bursts, odd-length transfers, and partial GP node cache line
   transfers. This test will return a true value if a loopback connector
   is not present.

Source/Destination Loopback / Controller Programmatic Auto Connect
   This test performs several HIPPI loopback transfers with the controller's
   autoconnect and autodisconnect logic enabled. This test performs
   the following steps, where the step number corresponds to a subtest
   number in the test:
   1. 	Check if the HIPPI loopback cable is present. If it is, initialize
        the source buffer; otherwise return immediately.
   2. 	Transfer 46 Kbytes vial the HIPPI loopback connection.
   3. 	Transfer 46 Kbytes + 28 bytes via the HIPPI loopback connection.
   4. 	Transfer 46 Kbytes + 32 bytes via the HIPPI loopback connection.
   5. 	Transfer 46 Kbytes + 44 bytes via the HIPPI loopback connection.

   If any transfer fails, the test finishes at that point. The different
   transfer sizes verify that the transfer completes correctly in
   the presence of various short burst conditions. This test will
   return a true value if a loopback connector is not present.

Source/Destination Loopback / Controller Burst-Package Out Logic
   Verifies the correct operation of the two outputs of the S2021;
   BROUT and PKOUT. This test requires that a HIPPI loopback cable
   be attached to the controller. If the loopback is not available,
   the test returns immediately. This test transfers a 8160 byte long
   test packet. This test monitors the BROUT and PKOUT signals during
   the initial short burst. This test will return a true value if
   a loopback connector is not present.


Parity/Node Interaction Tests/ 
   The Parity/Node Interaction Tests verify the performance counter,
   parity, cache coherency, and bus ownership retention. 

Parity/Node Interaction / Controller S2020 Parity Logic
   This test verifies the following parts of the controller's parity
   logic:
   o	The S2020 internal parity checker.
   o	The parity bus between the source FIFO and the S2020.
   o	The local parity generators.
   o	The buffer between the local parity generators and the host parity
        bus.

   The test uses the i960 to write bad parity int9o the source FIFO
   and uses the S2020's self test mechanism to detect the bad parity.
   The tool runs an instance of the self test for each pattern in
   the march_32 pattern set; it forces the parity error in the byte
   lane that has the marching bit for the current pattern. It is an
   error if the self test does not detect a parity problem. Subtest
   ID numbers increment for each instance of the self test. Subtest
   ID zero is for setup prior to the first self test.   

Parity/Node Interaction / Performance Counter
   This tool test the Xilinx-based performance counter. It tests the
   device as a dedicated counter, assuming it's already been initialized
   with the appropriate vectors. The 32-bit counters count at 50 MHz
   whenever certain parts of the logic control the local node bus.
   These four parts are:
   o	The source channel.
   o	The destination channel.
   o	The i960, accessing the node.
   o	The i860, accessing the controller.

   The first stage of the test divides each 32-bit counter into four
   independent 8-byte chunks, using the CTRDIAG bit in the diagnostic
   control register. For each counter, the test increments a diagnostic
   clock source and verifies that the counter chunks contain the expected
   count after each clock. The test then takes the counter under test
   out of its diagnostic mode, so it behaves like a normal 32-bit
   counter. One last clock verifies that the counter value rolls over
   to zero. This stage occurs four times, one for each counter in
   the same order in which they appear in the preceding list. The
   subtest ID number increments for each counter test, starting at
   one for the source channel counter.

   The second stage of the test verifies that each counter can count
   independently of the others. This stage also occurs four times,
   one for each counter, in the same order as before. (The Subtest
   ID number increments for each counter.) Each time the stage executes,
   the tool increments all counters to a value of 10. Then it resets
   the counter under test (leaving the other counters alone) and increments
   all counters ten more times. The target counter should have a count
   of ten and the other counters should have counts of twenty.

Parity/Node Interaction / Node-Controller RAM Parity Logic
   This test verifies that the controller correctly detects parity
   errors on i860 writes to controller resources (in this case, local
   RAM). The i860 and i960 processors cooperate in this test (see
   Table 8-1). First, the i960 determines the target RAM address and
   the address to the i860 at the first synchronization point (sync
   A) - this is subtest 0. Next, the tool uses the following algorithm
   for each pattern in the march_32 pattern set: 
   ================================+===================================
   i860 Action	    		   | i960 Action                     
   ================================+===================================
   Increment the subtest ID number.| Increment the subtest ID number.
			           | Prepare for host parity interrupt
   sync (B)			   | sync (B)
   --------------------------------+-----------------------------------
   Set the diagnostic control reg. |
   to cause invert parity in the   |
   byte land that has the marching |
   bit for the current pattern.    |
				   |
   Write the current pattern to the|
   target location in controller   |
   RAM.				   |
				   |
   Restore the diagnostic control  |
   register to its normal state.   |
				   |
   sync (C)			   | sync (C)
   --------------------------------+-----------------------------------
				   | Check whether the expected parity
				   | interrupt occurred. If not, report
				   | an error and increment an error
				   | counter.
				   |
				   | If the error counter reaches ten,
				   | pass a value indicating the i860
				   | should abort the test after the
				   | next synchronization.
				   |
   sync (D)			   | sync (D)
   --------------------------------+-----------------------------------
   If the i960 wants to abort the  | If the error counter reaches ten,
   test, do so. Otherwise, repeat  | abort the test. Otherwise, repeat
   this algorithm with the next    | this algorithm with the next
   pattern.			   | pattern.
   --------------------------------+-----------------------------------

Parity/Node Interaction / Controller Parity Regeneration Logic
   This test uses the HIPPI loopback transfers to send data with bad
   parity from the source channel to the destination channel and on
   to the GP node memory. On Fab 1 HIPPI controllers, the S2020 and
   S2021devices should detect the bad parity. On Fab 2 HIPPI controllers,
   the DP ASIC's on the GP node should not detect the bad parity if
   the controller's parity regeneration logic works correctly.

   First the i960 determines and verifies that a loopback cable is
   present and initializes the source and destination channels; this
   is subtest 0. This test will immediately exit if the loopback cable
   is not present. Next, the i960 executes the steps of the following
   algorithm for each pattern in the march_32 pattern set.
   1. 	Increment the subtest ID number.
   2. 	Reset the pattern manager to start of the march_32 pattern set.
   3. 	Create a 256-byte buffer consisting entirely of the current
        pattern in controller RAM.
   4. 	Establish a connection.
   5. 	Write all data from the 256-byte buffer into the source FIFO.
        Corrupt parity on any byte of the data, in the byte lane that
        currently has the marching bit.
   6. 	Prepare to receive send and receive parity interrupts.
   7. 	Pulse the BSTAV input to the S2020, causing the device to transmit
        the short burst across the HIPPI. The source parity interrupt should
        occur at this point as the corrupted byte goes out.
   8. 	Read data from the destination FIFO up through the word with
        corrupted parity. When the corrupted byte is at the FIFO, outputs
        to the destination parity interrupt should occur.
   9. 	Verify that the interrupts occurred. If not, report an error.
   10. 	Clear the destination FIFO and the destination error / status
        register to remove remaining data and error status.
   11. 	Break the HIPPI connection.
   12. 	If the number of failures reaches 10, abort the test. Otherwise
        repeat this algorithm with the next pattern in march_32.

   This test executes all the steps in the algorithm twice. The first
   time it checks the low side of the FIFO's and the second time it
   checks the high side of the FIFO's.

   This test will return a true value if a loopback connector is not
   present.

Parity/Node Interaction / Controller Interrupts to Node
   This test verifies the host interrupt register and the propagation
   of interrupts from the controller to the node. The i860 and i960
   processors cooperate in this test.

   The host interrupt register has three read / write bits. Setting
   any combination of these bits high causes an expansion board interrupt
   to the i860. The tool loops three times (subtest IDs one through
   three), once for each bit in the host interrupt register. The processors
   synchronize before and after the i960 sets a bit to cause the interrupt
   and the i860 verifies that the interrupt occurred. Subtest ID zero
   is for setup prior to the first interrupt.

Parity/Node Interaction / Node Interrupts to Controller
   This test verifies two interrupts: the host access interrupt that
   occurs every time the i860 accesses a resource on the HIPPI controller,
   and the i960 NMI. The tool tests both interrupts simultaneously,
   taking advantage of the fact that the register write which causes
   the NMI will also cause the host access interrupt. The i860 and
   i960 processors cooperate in this test.

   After some preliminary setup, the two processors synchronize together.
   The i860 then waits while the i960 unmasks the host access interrupt.
   (This interrupt is normally masked since the i860 makes so many
   controller accesses.) Next, the i860 writes to the controller's
   NMI pseudo-register, presumably causing the interrupts. After another
   synchronization, the i960 verifies that the interrupts actually
   occurred. 


Parity/Node Interaction / Controller-Node Cache Coherency
   This test does a set of basic checks to verify that the i960 accesses
   to snoopable i860 address space (0xe0000000 system processor snoopable)
   are fully coherent. The i960 and i860 processor operate in tandem,
   synchronizing with each other at various points in the test. The
   three basic checks are:
   o	i960 read of a location for which the i860 has a modified line.
   o	i960 write of a location for which the i860 has a modified line.
   o	i960 write of a location for which the i860 has a exclusive line.

   All operations occur at the 0xe0000000-equivalent address of
   nodeMemtestBuf. A one Mbyte page at this address is cacheable, as is
   the one Mbyte page of GP node memory used for i860 code, private data
   and stack. The former page is cached only during this test. The cache
   policy is always copy-back, with GP node hardware turning this into a
   write-once policy.

   Test Algorithm: 
   =======+==================+======+==================+==================
          |                  |Cache | 		       |
          |                  |State |		       |
   Subtest|		     |After |		       |
     ID	  | i860 Action	     |Action| Mem. Contents    | i960 Action
   =======+==================+======+==================+==================
    1	  | write 0x11111111 | X    | =>0x11111111     | 
          | enable cache     | I    | 0x11111111       |
          | read             | S    | <=0x11111111     |
	  | write 0x22222222 | E    | =>0x22222222     |
	  | write 0x33333333 | M    | 0x22222222       |
	  | sync (A)         |      |		       | sync (A)
          +------------------+------+------------------+------------------
	  |                  | S    | =>0x33333333     | read and verify
          |                  |      | (from cpybck) => | data
	  | sync (B)         |      | sync (A)         +
   =======+==================+======+==================+==================
    2     | write 0x11111111 | E    | =>0x11111111     |
	  | write 0x22222222 | M    | 0x11111111       |
	  | sync (C)         |      |                  | sync (C)
          +------------------+------+------------------+------------------
	  |		     | I    | =>0x22222222(from| write byte 0x44
	  |		     |	    | copyback) 0x44<= | 
	  |		     | I    | 0x22222244       | read and verify
	  |		     |	    |                  | data
          | sync (D)         |      |                  | sync (D)
   =======+==================+======+==================+==================
    3     | read and verify  | S    | <=0x22222244     |
	  | data             |	    |		       |
	  | write 0x33333333 | E    | =>0x33333333     |
	  | sync (E)	     |	    |		       | sync (E)
          +------------------+------+------------------+------------------
	  |		     | I    | 0x3333333 0x55<= | write byte 0x55
	  |		     | I    | 0x33333355=>     | read and verify
	  |		     |	    |		       | data
	  | sync (F)	     |	    |		       | sync (F)
   =======+==================+======+==================+==================

Parity/Node Interaction / Node Bus Ownership Retention
   This test verifies that the HIPPI controller maintain ownership
   of the node local bus. The i860 and the i960 cooperate in this
   test. The algorithm is:
   1. 	The i860 clears a boolean flag at (nodeMemtestBuf + 1).
   2. 	The i860 and i960 synchronize with each other.
   3. 	The i860 keeps incrementing a work nodeMemtestBuf as long as
        the flag remains clear.
   4. 	The i960 asserts KEEPBUS and reads one value from nodeMemtestBuf.
   5. 	The i960 delays briefly and read a second value from nodeMemtestBuf.
   6.	The i960 deasserts KEEPBUS and reads a third value from nodeMemtestBuf.
   7. 	The i960 sets the flag, at which point the i860 stops incrementing
        the word at nodeMemtestBuf.
   8. 	The i960 compares the three values it read from nodeMemtestBuf.
        If the first two values aren't equal, or if the second and third
        values are equal, an error occurred.
   9. 	The i860 and i960 synchronize with each other and return.

NXTNER Signal to Node

   This test verifies that the NXTNER logic works correctly. When
   the diagnostic control register's NXTNER bit is asserted, node
   DRAM access time for accesses within the same page should occur
   more quickly than they otherwise would, since the full RAS time
   only occurs on the first access. This test uses the following algorithm
   (item numbers in the list match the subtest ID numbers):
   1. 	Write eight words of minpat_32 at nodeMemtestBuf and in a controller
        RAM buffer.
   2. 	Reset the "controller as master" performance counter and read
        eight words from nodeMemtestBuf into a second controller RAM buffer.
        Record the performance counter value. Compare the two controller
        RAM buffers and report any mismatches.
   3. 	Reset the "controller as master" performance counter, assert
        NXTNER, and again read eight words from nodeMemtestBuf into the
        second controller RAM buffer. De-assert NXTNER and record the
        performance counter value. Again compare the two controller RAM
        buffers and report any mismatches.
   4. 	Compare the two recorded performance counter values. If the
        second value isn't smaller than the first, report an error.
