


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.


GP NODE BOARD TESTS
-------------------

   The GP Node Board Tests consist of the following test suites:

      Register / Counter / Timer / Error Detection Tests/
      GP Node Memory Tests/
      NIC Tests/
      Coherency / Arbitration / User Processor Tests/

Register /  Counter / Timer / Error Detection Tests/

   These tests check various GP node function associated with setting
   bits in the node control register and the integrity of read and
   write registers in the DP ASIC and NIC:

      Control / Mask Register Test
      DRAM Parity Error Detection Test
      ECC Correction Test
      Multiple-bit Error Detection Test
      DP OS Timer Test
      RPM Counter Test

Control / Mask Register Test

   This test verifies that the DP ASIC control/mask register, the
   NIC control/mask register, and the NIC FIFO offset register can
   hold data correctly.   This test writes each register with various
   patterns, reads the register under test after doing a write, and
   checks that the data read back is correct. 

DRAM Parity Error Detection Test

   This test checks that the status bits indicating a parity error
   has occurred on a byte of a word read from DRAM are operating correctly.

   There are eight parity errors that can be forced by the diagnostics
   (four with each DP ASIC), one for each byte of a high or low word
   read from memory.  This test forces one error at a time by setting
   one of the bits in the DP control register to force an error on
   a specific byte.  To force a parity error, one of the N11BxPERR
   bits in the DP control register is set.  Setting one of these bits
   does not actually cause bad parity on data read from memory but
   forces a parity error to the N11.  The DP ASIC detects that it
   is forcing bad parity and sets the data bus parity error interrupt
   bit in the corresponding DP status register.  Using the force bad
   parity bits does not require a memory read to set the DP status
   register interrupt bit.

ECC Correction Test

   This test checks that when one-bit errors are forced on memory
   writes when ECC correction is turned on, the corrupted data is
   corrected.

   This test takes advantage of several known data patterns for which
   the lower data byte matches the corresponding ECC byte for that
   word of data. It also uses a hardware features that routes the
   lower byte of data written to memory to the ECC memory location
   associated with that DRAM location. 

   The test first sets the bits in the DP control registers that enable
   ECC correction (for both high and low words of data). It also clears
   the ECCSEL bit in the node control register to route the lower
   data byte of a word written to memory to ECC memory. The test then
   forces a one-bit error in one of the special data patterns and
   writes it to memory. Since the lower byte is also written into
   ECC memory, it is interpreted as the ECC byte for that word. However,
   with the one-bit error, the logic determines that a correction
   must be made to the data written to memory because the computed
   ECC does not match that stored in ECC memory. The test reads the
   location and checks that the data was corrected and that the single-error
   correction bit in the DP status register is set. 

   There are ten patterns used in this test for which the lower byte
   of data matches the correct ECC value for that pattern. Note that
   one-bit errors cannot be forced on the lower byte of the data since
   this byte is written to ECC memory, and that would give an incorrect
   ECC value for comparison. The test does force one-bit errors on
   each of the upper 24 bits of each of the ten patterns, though.

Multiple-bit Error Detection Test

   This test verifies that when errors are forced with multiple bit
   errors in them, the multiple-bit error detected bit in the DP status
   register (errors are forced in both DP ASICs, so the error bit
   is checked in both DP_STS_LO and DP_STS_HI).  The DP ASICs should
   be able to detect any two-bit error within a 32-bit value and any
   three- or four-bit error where all the errant bits are contained
   in the same four-bit nibble.  The test also checks that this error
   bit is cleared when the clear hardware error bit in DPCTRL is set.

DP OS Timer Test

   This test checks that the 32-bit timer in each DP can be read and
   written.  These counters are incrementing counters and should be
   able to read and written at any time.  The test writes patterns
   into the timers such that as the timer increments, a rollover to
   the next bit should occur.  The timer is then read and that value
   is checked to make sure it is higher than the original value written
   (for example, if 0x3fff is written, the value read should rollover
   to be greater than 0x4000).

RPM Counter Test

   This test checks that the local counters in the RPM chip can be
   read and written.  This set of counters includes the system processor,
   user processor, and LTU counters.  It does not include the counters
   related to MRCs or the global clock.  These three counters increment
   whenever the related unit/processor is master of the local bus.
   For the system and user processors, memory operations are done
   to cause their counter to increment; for the LTUs, LTU transfers
   are done.  In each case, the counters are read to get an initial
   value.  After the current bus master has performed some operations,
   the counter is read again and the two values compared to ensure
   the second value is higher than the first.  The counters of the
   other potential bus masters are also read and checked to make sure
   they didn't increment.  (A special case of this is when the user
   processor or LTU is bus master; since the system processor is always
   in control when the test is started, its counter may increment
   some between the time it is first read and the second time it is
   read.  The test checks that it didn't increment much in relation
   to how much the counter of the real bus master did.) 

   The test also checks the that each counter can be reset and that
   when one counter is reset, the others in the test are not affected.
   Finally, the test checks that if a counter is disabled and its
   bus master performs some operations that should cause it to increment,
   the counter does not change value.

GP Node Memory Tests/ 

   The GP Node DRAM Memory Tests verify the DRAM address and data
   lines and the ability of each DRAM location to hold data (data
   integrity tests). The test menu is shown followed by the test
   descriptions:

      Data Line Test
      Address Tag Test
      Three-Par Test
      Address Line Switching Test
      Cell Integrity Test
      ECC DRAM Test
      Memory Bus Transaction Test

Data Line Test

   This test tests the data lines going to DRAM by writing various
   data patterns to the same memory location and making sure when
   the location is read, the data is correct.  This test first writes
   the location with the standard patterns of 5's, A's, 0's, and F's.
   After this, sliding 1's and 0's patterns are used.

Address Tag Test

   This test checks the address lines going to DRAM by writing the
   address of each DRAM location into the location and then reading
   each location and verifying that the data read matches the address
   of the location.  This test checks all memory addresses above the
   lower megabyte of memory and below the upper 128K of memory.

Three-Par Test

   The 3-par test checks the address lines going to DRAM by dividing
   the memory to be tested into three partitions and then checking
   that operations in one partition do not affect another partition.
   In this test, every third word is in the same partition.  This
   test checks all memory addresses above the lower megabyte of memory
   and below the upper 128K of memory.

Address Line Switching Test

   This test checks the address lines by making as many of them as
   possible change state on each write to memory.  This test picks
   the one megabyte address as the lower starting address and the
   highest memory address as the upper address.  The test increments
   the low address and decrements the high address on each write.
   A total of 100 accesses are done from the low and high addresses. 

   After finishing the writes, the locations are read, again in alternating
   order mixing high and low reads, and checked for correctness. 
   The data written is all 0's to the lower addresses and all F's
   to the upper addresses.

Cell Integrity Test 

   This test checks the ability of each DRAM cell to hold data correctly.
   The test does this by writing various data patterns to each memory
   location and then reading the data back and verifying that it is
   correct.  The test uses data patterns of 5's, A's, 0's, F's.  This
   test checks all of memory above the first megabyte and below the
   upper 128K of memory. 

ECC DRAM Test

   This test checks that the eight-bit wide memory used to store ECC
   information can hold data correctly. This memory cannot be directly
   read and written, so this test uses a couple useful debugging features
   of the GP node board. The first is the ECCSEL bit in the node control
   register, which when clear routes the lower byte of data written
   to memory to the ECC memory associated with that location (as well
   as to normal memory). This feature is used to write the ECC memory.
   To read ECC memory, memory is read normally but the value in ECC
   memory stored at a given location shows up in a byte of a register
   in the DP ASIC. There are four of these bytes, so the one checked
   depends on the address read.

   So, to write ECC memory, the test clears the ECCSEL bit and then
   writes memory normally, resulting in ECC memory being written also.
   Then, when reading ECC memory, four memory locations are read and
   then the four corresponding bytes in the DP ASIC register are checked
   for correctness (note that the reading must be done this way to
   avoid having any of the bytes overwritten before they are checked).
   Each ECC location is checked with four different patterns.

Memory Bus Transaction Test

   This test does various size accesses to memory to verify that they
   take place correctly.  The test does 8-bit, 64-bit, and 128-bit
   accesses.  Data of each length is written to memory, read back,
   and the correctness of the data is verified.  For byte accesses,
   ldio and stio instructions are used; for 64-bit accesses, fst.d
   and fld.d instructions are used; and for 128-bit accesses, fst.q
   and fld.q instructions are used.  Note that although reads of the
   correct length are done, data is checked in 32-bit chunks since
   that's the length of the return register used by the software.
   Caching is turned off during this test.

NIC Tests/

   This section describes the data transfer tests for the GP node
   board.  These tests all use the loopback path from the NIC's output
   FIFO to its input FIFO.  The first set of tests do not use the
   DP ASIC's line transfer unit (LTU) capability, but later ones do.
   Note that in all tests that use the loopback paths, the NIC outputs
   must be tristated by clearing bit 52 in the NIC control register.
   The loopback path is enabled by setting bit 46 in NICCTL.  The
   following identifies the NIC Test Menu followed by a description
   of the test:

      NIC Loopback Transfer Test
      NIC FIFO "Almost" Flag Test
      NIC Control and Status Register Functionality Test
      NIC CRC Test
      NIC FIFO Error Test
      NIC Parity Error Test
      NIC Streaming Test
      LTU Test

NIC Loopback Transfer Test

   This test checks that data can be transferred over the NIC's loopback
   path correctly.  The loopback path routes data from the NIC's output
   FIFO to its input FIFO.

   This test writes a header word and an end-of-data (EOD) word, and
   checks that various FIFO status bits are set at the correct time.
   After writing the twelve words transferred during the test, the
   test checks that the transmit FIFO not full, transmit FIFO not
   empty, transmit FIFO not almost full, and transmit FIFO empty bits
   are all set.  It also checks that the receive FIFO not empty bit,
   can_read_one_word, can_read_two_words, and EOD_in_NIC bits are
   set before reading any data.

   After reading out all the data, the NIC status register is read
   again to make sure the receive FIFO not empty bit, can_read_one_word,
   can_read_two_words, and EOD_in_NIC bits are now clear.

NIC FIFO "Almost" Flag Test

   This test checks that the receive FIFO almost full and transmit
   FIFO almost empty conditions of the NIC operate correctly.  This
   test first writes data to the NIC until the receive FIFO is full
   and the transmit FIFO is not empty and then not almost empty. 
   Data is then read until the transmit FIFO becomes almost empty
   and then empty.  The word count that it took for each of these
   four conditions to become true is saved.

   The test then writes the offset registers and does another transfer
   as above, again saving word counts for transmit FIFO not empty,
   transmit FIFO not almost empty, transmit FIFO almost empty and
   transmit FIFO empty.  These counts are then compared with those
   that occurred when the offset registers were not used.  All counts
   should be different if the offset registers had the correct effect.

NIC Control and Status Register Functionality Test

   This test checks the functionality of various control and status
   features of the NIC, including end-of-data, read_one_word, and
   read_two_words status bits, and the NIC's enable/disable deliver
   last word capability, enable/disable stripping capability, and
   inhibit CRC capability.

   The first test case checks the can_read_one_word and can_read_two_words
   flags by writing one or two words and checking that these bits
   are set and cleared at the appropriate times.  Note that these
   flags refer to data available in post-FIFO stages of the receive
   pipeline, not data in the FIFO itself.

   The next test case checks the disable stripping function to verify
   that the first word transferred is not stripped off by the NIC.
   This test checks that the first word sent can eventually be read
   from the NIC, whereas when the disable stripping bit is clear,
   the first word is normally considered a header word and is not
   able to be read out from the NIC.

   The next test case checks the inhibit CRC function of the NIC.
   When set, no CRC word is appended to a packet sent to the NIC.
   Normally, the CRC word is also taken off by the NIC, but with the
   inhibit CRC bit set, the test checks that the last data word sent
   is instead stripped off.

   This test case checks the deliver last function of the NIC.  When
   set, this bit disables the stripping of the last word that is sent
   to the NIC, which in most cases is the CRC word.  This test case
   also sets the inhibit CRC bit so that no CRC word is generated.
   Therefore, the result of this test case should be that the last
   data word written is available to read instead of being stripped
   off as it would be if the deliver last bit was set.

NIC CRC Test

   This test checks various functions of the NIC related to calculating
   and checking CRC's and forcing CRC errors. 

   This test case sets the deliver last bit in NICCTL and then does
   a normal data transfer of several words for which a CRC is calculated.
   The test then takes all the data words and calculates the correct
   CRC.  The CRC generated by the NIC should be sent to the receive
   FIFO as the last word in the packet, following the last data word,
   since the deliver last bit is set.  The calculated CRC is then
   compared to the CRC computed by the NIC to ensure they match.

   This test case is similar to the previous one except that the CRC
   on first word and disable stripping bits are also set in NICCTL.
   In this case, the CRC computation should include the same words
   as the last case, since the header wasn't stripped off then either.
   After the data is transferred, the CRC generation is done with
   all data read from the receive FIFO, including the word defined
   as the header word.  This CRC should match the one calculated by
   the test.

   This test case forces a CRC error on the lower 32 bits of data
   applied to the CRC generators in the NIC to make sure it is detected
   by the NIC.  Note that all interrupts are masked off during this
   test.  This test sets the force network CRC0 error bit in NICCTL
   and then writes several data words to the transmit FIFO.  Note
   that this error bit must stay set during the entire transfer (until
   the receive FIFO is empty).  The data is then read from the receive
   FIFO.  After this, NICSTAT is read and the network crc0 error bit
   is checked to ensure it is set, while the network crc1 error bit
   is checked to verify it is clear.  The crc0 error bit in NICSTAT
   must be cleared at the end of the test case by setting the clear
   hardware error bit in NICCTL.

   This test case is similar to the previous test case except that
   it forces an error on the upper 32 bits of data transferred.  NICSTAT
   is read and the network crc1 error bit is checked to ensure it
   is set, while the network crc0 error bit is checked to ensure it
   is clear.  The crc1 error bit in NICSTAT must be cleared at the
   end of the test case.

   This test case checks that when a CRC error is forced but the inhibit
   CRC checking bit in NICCTL is set, the corresponding CRC error
   bit in NICSTAT is not set.  This test sets the inhibit CRC checking
   and force network crc0 error bits in NICCTL.  It then writes several
   words to the transmit FIFO and reads it out from the receive FIFO.
   After reading the data, NICSTAT is read and the network crc0 error
   bit is checked to verify it is clear.

   This test case is similar to the previous one except that the error
   is forced on the upper 32 bits of data.  After the transfer, the
   network crc1 error bit is checked to ensure it is clear.

NIC FIFO Error Test

   This test checks that overrun and underrun FIFO conditions, the
   receive FIFO and transmit FIFO full conditions, and the transmit
   FIFO almost full condition that are posted in the NIC status register
   can be detected.  The test also checks that the overrun and underrun
   flags are cleared when the clear hardware error bit is set in the
   NIC control register.   Note that during this test, both offset
   registers are set to zero and the almost full select bit is set
   so the offset registers indicate almost full and empty status.
   The effect of these two things is that the receive FIFO almost
   full and transmit FIFO almost empty conditions never occur.

   The first test case checks the receive FIFO underrun condition.
   This test attempts to read data from an empty FIFO and then reads
   NIC status and checks that the receive underrun bit is set.  The
   clear hardware error bit is set and the underrun bit is checked
   again to ensure it is cleared.

   The next test case checks the transmit FIFO full condition by disabling
   the transmit of data in the FIFO, writing enough data to fill the
   transmit FIFO, and checking that the transmit FIFO not full flag
   is clear.  Then, the test does one more write to cause the transmit
   FIFO overrun condition to be true.  The clear hardware error bit
   is then set and the overrun bit is checked again to ensure it is
   now clear.

   The receive FIFO full and receive FIFO overrun conditions are checked
   by causing the offset registers to be used for the almost full
   and empty conditions and then setting them to zeros.  This makes
   sure that the receive FIFO almost full condition never occurs,
   since this prohibits the receive FIFO from ever becoming full.
   The test writes to the NIC until the receive FIFO is full and
   then forces the overrun condition by writing one more word to the
   NIC.  Lastly, the clear hardware error bit is set to clear the
   overrun condition. 

NIC Parity Error Test

   This test checks that when parity errors are forced on data sent
   to the NIC, the errors are indicated by the corresponding bits
   being set in the NIC status register.  The two errors that can
   be forced are on the two separate bytes of a 16-bit word that the
   NIC usually deals with.  (Data normally arrives at the NIC in 64-bit
   words, but is first split into 32-bit chunks for CRC generation
   and then into 16-bit chunks to be sent to the MRC (or loopback
   path)).

   The first test case checks that a parity error forced on the lower
   byte of data is detected while the second test case deals with
   the upper byte.  The test also checks that both errors can be cleared
   by setting the clear hardware error bit in the NIC control register.

NIC Streaming Test

   This test checks that the NIC can transfer data in streaming mode.
   The test consists of two test cases, one for slow streaming mode
   and one for high-speed streaming mode. The test puts the NIC in
   the correct mode for the test case and also sets the loopback bit
   so the data goes from the NIC's output FIFO to its input FIFO.
   The data is then written to the transmit register in the NIC and
   read from the receive register. The data is checked for correctness.
   Three test cases of varying lengths are run for each of the two
   transfer modes, although no attempt is made to fill up the transmit
   FIFO before reading since the test is run in loopback mode.

LTU Test

   This test checks the basic functionality of the GP node's line
   transfer unit (LTU). This unit allows the user to transfer a block
   of data by specifying a starting address and a line count (a line
   is made up of 32 bytes) in a special area of memory.

   The test initializes a block of memory from which data is transferred
   and the block of memory to which it is to be written. It then starts
   an LTU transmit operation by writing the starting transmit address
   and the number of lines to be transferred to an upper-word address
   in LTU space, followed by the LTU receive operation, which is started
   by specifying the starting receive address and another line count
   to a lower-word address in LTU space. The test then monitors the
   transmit LTU and receive LTU done bits in the DP status register
   to verify that the LTU operations complete as they should. When
   the LTU operations are done, the test compares the data in the
   receive space with the original data in transmit space. The test
   consists of three test cases that transfer different amounts of
   data.

Coherency / Arbitration / User Processor Tests/

   The Coherency / Arbitration / User Processor set of tests checks
   functions that involve more than one bus master in a test.  These
   include the ability to get correct data when either the system
   or user processor has modified data in its cache; the ability of
   the system and user processors to receive interrupts; and verification
   of bus arbitration when the system and user processors and the
   LTUs all try to transfer data to and from memory.  The test menu
   is shown followed by the test descriptions:

      DP / NIC Interrupt Test
      LTU Line Count Test
      System Processor / LTU Coherency Test
      System / User / LTU Arbitration Test

DP / NIC Interrupt Test

   This test checks that the NIC interrupt, system to user processor
   interrupt, user to system processor interrupt, and the two DP OS
   timer interrupts can be forced, that the correct processor can
   receive them, and that clearing the appropriate mask bit stops
   the processor from receiving the interrupt.

   The interrupts are forced in the following ways:
   o	NICINT - forced by setting the enable transmit FIFO empty bit
                 in NIC_CTL_LO (a NIC reset is done at the beginning
                 of the test, so the FIFOs should be empty)
   o	SYSINT - forced by setting the SYSTOUSRINT bit in DP_CTL_LO (this
                 causes the SYSINT bit in DP_STS_LO to be set)
   o	USRINT - forced by setting the USRTOSYSINT bit in DP_CTL_HI (causes
                 the USRINT bit in DP_STS_HI to be set)
   o	OSLOTIMEINT - forced by writing a large value into the OS low
                      timer and waiting for the counter to count up
                      so that it rolls over to 0; this causes the interrupt
   o	OSHITIMEINT - forced by writing a large value into the OS high
                      timer and waiting for it to count up so that
                      it rolls over to 0; this causes the interrupt

   Note that this test does take the user processor out of reset and
   allows it to run for short periods to process interrupts.  When
   it receives an interrupt, it writes a value into a memory location
   that the system processor looks at.  This way, the system processor
   can tell what the user processor has done.

LTU Line Count Test

   This test does several LTU transfers, with the emphasis being on
   ones for which the NIC throttles just about the same time as the
   line count reaches zero. This acts like a stress test on the NIC
   FIFO's, making sure that the correct amount of data is transferred
   if the FIFO flags are changing as the LTU completes.  The test
   always writes the same value into the FIFO offset register and
   uses the values in that register to throttle the NIC, but each
   test case transfers a different amount of data. The data is checked
   for correctness after each transfer.

System Processor / LTU Coherency Test

   This test checks that if data in the system processor's cache is
   modified and an LTU transfer is done from the memory locations
   corresponding to the data in the cache, the data in cache is written
   out to memory before the LTU transfer is performed and is the data
   transferred.

   The test follows these basic steps:
   o	initializes two areas in memory with known data patterns (area1
        with pattern1, area2 with pattern2)
   o	reads area1 to fill the cache with data
   o	modifies the data in the cache with pattern3
   o	performs an LTU transfer from area1 to area2
   o	checks that memory area2 now contains pattern3

   This test also contains test cases that modify a different cache
   line on each iteration, with eight lines total being modified.
   One line is modified and then an LTU transfer is done, and the
   test checks that the modified cache line was evicted to DRAM and
   that the correct data was transferred by the LTU.

System/User / LTU Arbitration Test

   This test checks that the system and user processors and the LTU
   can all perform operations correctly when they are arbitrating
   for the bus.   It does this by first starting having the system
   processor start an LTU transfer, and then starting itself and the
   user processor running the same piece of code, which is a DRAM
   controller test.  The test verifies that the LTU completes and
   that the data transferred is correct, and that the system and user
   processors both ran their test correctly.

   This test also checks cache coherency between the user processor
   and system processor by having the system processor put some data
   in the cache, put some of it in a modified state, and then start
   the user processor running some code which writes to memory locations
   that are cached.  The result should be that the data in the cache
   should be written to memory before the writes done by the user
   processor take place.  Data miscompares are reported as errors.



MESSAGE NETWORK TESTS
---------------------

   The Message Network Tests check the router backplane and the node-to-node
   communications through the router backplane. Following are the
   Message Network Tests along with a description of each test:

      Mesh Routing Chip Loopback Test
      CRC Error Test
      Transmit and Receive Test
      Concurrent Receive Test
      Router Test
      Channel Arbitration Test
      Concurrent Router Test
      Multi-Hop Test
      Neighbor Concurrent Comm Test
      Node Concurrent Comm Test
      Channel Mask Concurrent Comm Test
      Generic Transmit and Receive Test

Mesh Routing Chip Loopback Test

   The Mesh Routing Chip Loopback Test transmits and receives a message
   using a null routing probe. This forces the MRC to loop the message
   back into the node. The message is then received and compared with
   what was written. An error message is generated if there is a difference.
   This test checks as much of the communication hardware as possible
   without requiring that two nodes communicate with each other. 

CRC Error Test

   The CRC Error Test transmits and receives a message with a null
   routing probe and a corrupted CRC. The message is then received
   and a CRC error is expected. If a CRC error is not detected, an
   error message is generated. A message is then transmitted with a
   null routing probe and a normal CRC. If a CRC error is detected,
   an error message is generated. This checks the node CRC error
   detection circuits without requiring that two nodes communicate
   with each other. 

Transmit and Receive Test

   The Transmit and Receive Test individually checks each of the node-to-node
   links. Each node transmits a message to its neighbors in a north,
   south, east, west sequence. The receiving nodes compare the message
   received with an expected pattern. An error is reported if a difference
   is detected.

Concurrent Receive Test

   The Concurrent Receive Test checks the ability of the MRC to concurrently
   receive a message from its neighbors. Each node is tested individually.
   All neighbors are simultaneously commanded to transmit to the node
   under test. The node under test receives and checks all of the
   messages.

Router Test

   The Router Test checks the ability of the MRC to route messages.
   Each MRC is tested individually. The test is performed as follows.
   The node north of the node under test transmits to the node south.
   South transmits north. East transmits south, west, then north.
   West transmits north, east, and south. The receiving nodes verify
   the messages. Each transmit and receive occurs individually.

Channel Arbitration Test

   The Channel Arbitration Test checks the ability of the MRC to arbitrate
   simultaneous messages through a channel. Each MRC is tested individually.
   All input neighbors of the node under test and the node under test
   simultaneously transmit to the output neighbor. 

Concurrent Router Test

   The Concurrent Router Test checks the ability of the MRC to simul-
   taneously route messages to different nodes. Each MRC is tested
   individually. The neighbor to the north of the node under test transmits
   to the neighbor south of the node under test. The node to the east
   transmits west and the node to the west transmits east. The node under
   test performs an MRC internal loopback. All transmits occur simul-
   taneously. The receiving node verifies the messages.

Multi-Hop Test

   The Multi-Hop Test individually checks the capability of each node
   to transmit a message to all other nodes in the system one at a
   time. Each node transmits to all other nodes (one at a time) in
   the system. The receiving nodes verify the messages. 

Neighbor Concurrent Comm Test

   The Neighbor Concurrent Comm Test simultaneously checks all of
   the MRC capabilities for communicating between each node and its
   neighbors. Each node transmits to its neighbors, receives, and
   checks messages. 

Node Concurrent Comm Test

   The Node Concurrent Comm Test simultaneously checks all of the
   MRC capabilities for communicating between each and every node
   in the system. Each node transmits to all other nodes including
   itself, receives, and checks messages.   

Channel Mask Concurrent Comm Test

   The Channel Mask Concurrent Comm Test assists in engineering and
   manufacturing debug of the routing backplane. The user is prompted
   for transmits on each of the MRC channels. MRC channels are north,
   south, east, west, and the internal loopback. Each node transmits,
   receives, and checks messages on channels which are not masked.

Generic Transmit and Receive Test

   The Generic Transmit and Receive Test assists in engineering and
   manufacturing debug of the node boards and the routing backplane.
   The user is prompted to enter source and destination node numbers
   for messages. All messages are transmitted simultaneously. The
   destination nodes receive and check the messages. 



MIO MODULE TESTS
----------------

   The MIO Module Test menu contains tests which verify the MIO Module.

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

      RAM Data Line Test
      RAM Address Test
      RAM Moving Inverse Test
      SCSI Controller Test

RAM Data Line Test

   The RAM Data Line Test verifies the data lines to location zero
   in the MIO Module RAM. Patterns 0x0000, 0xffff, 0xf0f0, 0xcccc,
   0x3333, 0x5555, 0xaaaa, and 0x0000 are written, read, and verified.

RAM Address Test

   The RAM Address Test verifies the address lines to the MIO Module
   RAM. Incrementing data corresponding to address lines 0 through
   17 is written to Bank 1. Addresses used are 0, 1, 2, 4, 8, 0x10,
   0x20, 0x40, 0x80, 0x100, 0x200, 0x400, 0x800, 0x1000, 0x2000, 0x4000,
   0x8000, 0x10000, 0x20000, and 0x3ffff. Data written to the locations
   is, respectively, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
   14, 15, 16, 17, 18, and 19. Incrementing data corresponding to
   address lines 0 through 17 is written to Bank 2. Addresses used
   are 0x40000, 0x40001, 0x40002, 0x40004, 0x40008, 0x40010, 0x40020,
   0x40040, 0x40080, 0x40100, 0x40200, 0x40400, 0x40800, 0x41000,
   0x42000, 0x44000, 0x48000, 0x50000, 0x60000, and 0x7fffff. Data
   written to the locations is, respectively, 20, 21, 22, 23, 24,
   25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, and 39.
   All these addresses are now read and the received data compared
   to the expected patterns. If an Ethernet is installed on this MIO,
   data is not written or read from the top 64K bytes of the MIO RAM.

RAM Moving Inverse Test

   The RAM Moving Inverse Test verifies the 512K bytes of MIO Module
   RAM.The entire RAM is initialized with pattern 0x0000. Bank 1(addresses
   0x80000000-0x8003ffff) is tested first. The first location of RAM
   is read to verify the previously written pattern. The first location
   is written with new pattern 0xffff. The first location is read
   to verify the previously written pattern. This read, verify, write,
   read, and verify is repeated for every word in the first bank of
   RAM. The above sequence is repeated with patterns 0xf0f0, 0xcccc,
   0x3333, 0x5555, 0xaaaa, and 0x0000.

   The above sequence is repeated for bank 2(addresses 0x80040000
   - 0x8007ffff). Bank 2 is only tested for addresses 0x80040000 -
   0x8006ffff on the boot node or any node with active ethernet. The
   ethernet is alive at this point and superfluous data can occur
   in the upper 64K bytes of MIO RAM.

SCSI Controller Test

   The SCSI Controller Test verifies the functionality of the SCSI
   Controller and Xilinx DMA. The reset, configuration registers,
   illegal command interrupt, DMA, FIFO count, and FIFO overflow functions
   are tested.



SCSI DEVICES AND RAID TESTS
---------------------------

   The SCSI Device Test menu contains tests which verify the SCSI
   bus communication with devices and the ability of the devices to
   accept and execute SCSI commands. 

   Following is the Device Tests menu followed by a description of
   each test:

      SCSI Bus Reset Test
      Device ID Test
      Array Controller Tests/
      Array Controller Disk Tests/
      Disk Tests/
      Tape Tests/
      Operator Functions/

SCSI Bus Reset Test

   The SCSI Bus Reset Test issues a reset to the SCSI bus. The reset
   causes all connected devices to execute a start-up sequence. The
   SCSI Controller is checked to insure a SCSI Bus Reset interrupt
   was generated. Another reset is issued and the interrupt is allowed
   to go to the SCSI Driver interrupt handler generating a renegotiate
   synchronous mode to all connected devices.

Device ID Test

   The Device ID test compares the configuration of the device to
   test with the configuration requested.

Array Controller Tests/

   The Array Controller Tests menu contains tests which verify the
   Array Controller and its ability to execute SCSI commands. 

   The Array Controller Tests menu is shown followed by a description
   of each test: 

      Array Controller Ready Test
      Array Controller Self Test
      Array Controller Bad Command Rejection Test
      Array Controller Buffer Write/Read Test

Array Controller Ready Test

   The Array Controller Ready test verifies that the device is ready
   to receive commands by issuing Test Unit Ready commands to the
   device and expecting a ready status.

Array Controller Self Test

   The Array Controller Self test directs the device to execute its
   self test and return the status.

Array Controller Bad Command Rejection Test

   The Array Controller Bad Command Rejection test verifies that the
   device returns proper status for a bogus SCSI command.

Array Controller Buffer Write/Read Test

   The Array Controller Buffer Write/Read test writes/reads/verifies
   various test patterns to the Array Controllers buffer memory. A
   Read Buffer command is executed to find out the size of the devices
   buffer. A pattern of 0xAA and then 0x55 is written to the buffer,
   read from the buffer, and verified.

Array Controller Disks Tests/

   The Array Controller Disks Tests verify the ability of the Array
   Controller and the devices attached to the Array Controller to
   execute SCSI commands and store and retrieve data. 

   The Array Controller Disks Tests are shown followed by a description
   of each test: 

      Array Controller Disks Ready Test
      Array Controller Disks Self Test
      Array Controller Disks Bad Command Rejection Test
      Array Controller Disks Buffer Write/Read Test
      Array Controller Disks Diagnostic Unit Test
      Array Controller Disks Diagnostic Write/Read Test
      Array Controller Disks Read Test
      Array Controller Disks Write/Read Test (Ignored)

Array Controller Disks Ready Test

   The Array Controller Disks Ready test verifies that the device
   is ready to receive commands by issuing Test Unit Ready commands
   to the device and expecting a ready status.

Array Controller Disks Self Test

   The Array Controller Disks Self test directs each device attached
   to the Array Controller to execute its self test and return the
   status.

Array Controller Disks Bad Command Rejection Test

   The Array Controller Disks Bad Command Rejection test verifies
   that each device attached to the Array Controller returns proper
   status for a bogus SCSI command.

Array Controller Disks Buffer Write/Read Test

   The Array Controller Disks Buffer Write/Read test writes/reads/verifies
   various test patterns to the buffer memory of each drive attached
   to the Array Controller. A Read Buffer command is executed to find
   out the size of the devices buffer. A pattern of 0xAA and then
   0x55 is written to the buffer, read from the buffer, and verified.

Array Controller Disks Diagnostic Unit Test

   The Array Controller Disks Diagnostic Unit test directs the Array
   Controller to execute a vendor unique self test on itself and its
   attached devices.

Array Controller Disks Diagnostic Write/Read Test

   The Array Controller Disks Diagnostic Write/Read test writes/reads/verifies
   test patterns to the restricted area of the Array Controller attached
   devices. This restricted area is where the Array Controller retains
   its loadable software and information about the drives. The area
   is large enough on each drive to go over cylinder boundaries. The
   commands used are Array Controller vendor unique. A pattern of
   0xAA is written to the Array Controller attached drives, read from
   them, and verified.

Array Controller Disks Read Test

   The Array Controller Disks Read test reads a specified number of
   blocks from the Array Controller attached devices. The amount read
   is enough to cross several cylinder boundaries in the user area.

   NOTE: The following test writes to the Array Controller disks starting
   at address 0 and is destructive. It will destroy data on the Array
   Controller disks.

Array Controller Disks Write/Read Test (Ignored)

   The Array Controller Disks Write/Read Test writes/reads/verifies
   data to the Array Controller disks. The data is an incrementing
   pattern (i.e. 0x00 - 0xff, then 0x00 - 0xff) that fills a 512 byte
   block. The first four bytes of each 512 byte block are also an
   incrementing pattern rippling through the 128 blocks of a 64K byte
   buffer (i.e. 0x00000000 - 0x0000007f). A megabyte of data is written
   (i.e. sixteen 64K byte buffers) to the Array Controller disks starting
   at address 0. The megabyte of data is read and the first four bytes
   of each 512 byte block is verified. This continues for a pre-determined
   number of one megabyte transfers to insure crossing several cylinder
   boundaries on all disks.

Disk Tests/

   The Disk Tests verify the ability of disks to execute SCSI commands
   and store and retrieve data. 

   The Disk Tests are shown followed by a description of each test: 

      Disk Ready Test
      Disk Self Test
      Disk Bad Command Rejection Test
      Disk Buffer Write/Read Test
      Disk Read Test
      Disk Write/Read Test (Ignored)

Disk Ready Test

   The Disks Ready test verifies that the device is ready to receive
   commands by issuing Test Unit Ready commands to the device and
   expecting a ready status.

Disk Self Test

   The Disk Self test directs the disk to execute its self test and
   return the status.

Disk Bad Command Rejection Test

   The Disk Bad Command Rejection test verifies that the disk returns
   proper status for a bogus SCSI command.

Disk Buffer Write/Read Test

   The Disks Buffer Write/Read test writes/reads/verifies various
   test patterns to the buffer memory of the drive. A Read Buffer
   command is executed to find out the size of the devices buffer.
   A pattern of 0xAA and then 0x55 is written to the buffer, read
   from the buffer, and verified.

Disk Read Test

   The Disks Read test reads a specified number of blocks from the
   device. The amount read is enough to cross several cylinder boundaries
   in the user area.

   NOTE: The following test writes to the disk starting at address 0 
   and is destructive. It will destroy data on the disks.

Disks Write/Read Test (Ignored)

   The Disk Write/Read Test writes/reads/verifies data to the disk.
   The data is an incrementing pattern (i.e. 0x00 - 0xff, then 0x00
   - 0xff) to fill a 512 byte block. The first four bytes of each
   512 byte block are also an incrementing pattern rippling through
   the 128 blocks of a 64K byte buffer (i.e. 0x00000000 - 0x0000007f).
   This buffer of data is written to the disk starting at address
   0. The data is read and the first four bytes of each 512 byte block
   is verified. This continues for a pre-determined number of transfers
   to insure crossing several cylinder boundaries on the disk.

Tape Tests/

   The Tape Tests verify the ability of tape devices to execute SCSI
   commands and store and retrieve data. 

   The Tape Tests are shown followed by a description of each test:

      Tape Ready Test
      Tape Self Test
      Tape Bad Command Rejection Test
      Tape Buffer Write/Read Test
      Tape Rewind Test (Igonred)
      Tape Erase Test (Igonred)
      Tape Streaming Write/Read Test (Ignored)
      Tape Start/Stop Write/Read Test (Ignored)
      Tape Space Data/Filemarks/EOD Test (Ignored)

Tape Ready Test

   The Tape Ready test verifies that the device is ready to receive
   commands by issuing Test Unit Ready commands to the device and
   expecting a ready status.

Tape Self Test

   The Tape Self test directs the tape device to execute its self
   test and return the status.

Tape Bad Command Rejection Test

   The Tape Bad Command Rejection test verifies that the tape device
   returns proper status for an unsupported SCSI command.

Tape Buffer Write/Read Test

   The Tape Buffer Write/Read test writes/reads/verifies various test
   patterns to the buffer memory of the tape device. A Read Buffer
   command is executed to find out the size of the devices buffer.
   A pattern of 0xAA and then 0x55 is written to the buffer, read
   from the buffer, and verified.

   NOTE: A tape cartridge must be installed for the following test to
   execute.

Tape Rewind Test (Ignored)

   The Tape Rewind test issues a rewind command to the tape device
   and verifies that it is at the beginning of the partition.

   NOTE: A scratch tape cartridge must be installed for the following
   tape tests to execute. The tests are destructive and will destroy
   data on the tape cartridge.

Tape Erase Test (Ignored)

   The Tape Erase test issues a rewind command and then sets end of
   data at the start of the tape. After attempting to read of block
   of data, the response from the tape device is checked.

Tape Streaming Write/Read Test (Ignored)

   The Tape Streaming Write/Read test writes a predetermined number
   of blocks to the tape. The writes are conducted such as to force
   the tape to "stream". The tape is rewound and a predetermined number
   of blocks are read from the tape. Only the first 4 bytes of each
   block are checked for unique block numbers.

Tape Start/Stop Write/Read Test (Ignored)

   The Tape Start/Stop Write/Read test writes a predetermined number
   of blocks to the tape. The writes are conducted such as to force
   the tape to start and stop. The tape is rewound and a predetermined
   number of blocks are read from the tape. Only the first 4 bytes
   of each block are checked for unique block numbers.

Tape Space Data/Flummeries/EOD Test (Ignored)

   The Tape Space Data/Filemarks/EOD test writes a predetermined pattern
   of data and filemarks to the tape. Space forward/reverse for data
   blocks, filemarks, and EOD are conducted and the position on the
   tape is checked.

Operator Functions/

   The Operator Functions utilities are required to perform maintenance
   and initialize Array Controllers and devices. 

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

   The Operator Functions are shown followed by a description of each
   function:

      SCSI Bus Reset
      Read Capacity
      Test Unit Ready
      Request Sense
      Send Diagnostic
      Set Pass Thru Cmd
      Inquiry
      Mode Sense
      Mode Select
      Format
      Download RAID Microcode
      Tape Log Sense
      Dump Memory
      MFG Set Up RAID
      Change RAID Levels
      Reconstruct a RAID Device

SCSI Bus Reset

   The SCSI Bus Reset Function issues a reset to the SCSI bus causing
   all connected devices to execute a start-up sequence. No Request
   Sense is done after the reset so any following command could fail.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Read Capacity

   The Read Capacity Function issues a Read Capacity SCSI command
   to the device selected and displays the capacity of the device
   selected. For example:

      dev highest block number block size    total bytes
      0  0x00938500  9667840   0x000200 512  0x270a0200 

   CAUTION: This selection is not normally used by anyone except the
   test engineer and manufacturing. It can be destructive and results
   are unpredictable. When the menu is displayed, it will indicate
   which device it will attempt to execute the commands on. Selecting
   these commands on the wrong device can be destructive.

Test Unit Ready

   The Test Unit Ready Function issues a Test Unit Ready SCSI command
   to the device selected.

   CAUTION: These selections are not normally used by anyone except the
   test engineer and manufacturing. They can be destructive and results
   are unpredictable. When the menu is displayed, it will indicate
   which device it will attempt to execute the commands on. Selecting
   these commands on the wrong device can be destructive.

Request Sense

   The Request Sense Function issues a Request Sense SCSI command
   to the device selected and displays the information returned. An
   example follows:

   sense info:
   dev  class seg key    info      asl     CSI       ASC  ASCQ FRU  bit  field
    0     70   0   6     0000     0000     0000      29    0    0    0     0

   This is referred to as 6,29,0 or a sense key of 6, additional sense
   key of 29, and additional sense code qualifier of 0. This is what
   one would get after doing a SCSI Bus Reset, Test Unit Ready, and
   then the Request Sense. This indicates a Power On, Reset, or Bus
   Device Reset Occurred. The next Test Unit Ready, Request Sense
   combination would normally show a 0,0,0 or normal.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Send Diagnostic

   The Send Diagnostic Function issues a Send Diagnostic command to
   the device selected. This command requests the device selected
   to execute its self-test.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Set Pass Thru Cmd

   The Set Pass Thru Cmd Function issues a vendor unique SCSI command
   to the Array Controller. This command informs the Array Controller
   that the next SCSI command will be passed to an attached device.
   For example, select this command and answer the prompts: select
   disk 1, scsi id of 0, and 3 for target to initiator (data). Next,
   select the Read Capacity command and the capacity of RAID Disk
   1 would be displayed.

   CAUTION: These selections are not normally used by anyone except 
   the test engineer and manufacturing. They can be destructive and 
   results are unpredictable. When the menu is displayed, it will 
   indicate which device it will attempt to execute the commands on. 
   Selecting these commands on the wrong device can be destructive.

Inquiry

   The Inquiry Function issues an Inquiry SCSI command to the device
   selected and displays the information returned. An example showing
   the inquiry data from an Array Controller follows:

     dev type len qual   rmb   vers fmt  B5  B6 B7     Identification
      0   00   1f   00    0     02   2   00  00 12     NCR  ADP-92/01  0302

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Mode Sense

   The Mode Sense Function issues a Mode Sense SCSI command to the
   device selected and displays the information returned. This command
   is normally used to display RAID mode sense page 0x2a which shows
   the status of its attached drives. For example:

      0     aa  f0  00  00  00  00  00  11
      8     11  11  11  11  11  11  11  11
      16    11  01  01  01  01  01  11  11
     etc.

   This example is the result of selecting page 0x2a. Bytes 2 through
   6 indicate good status for drives 1 through 5 with a SCSI id of
   0 on an Array Controller.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Mode Select

   The Mode Select Function issues a Mode Select SCSI command to the
   device selected. This command is used in conjunction with the Mode
   Sense command. A Mode Sense is issued for a particular page. The
   Mode Select command is selected. The data previously acquired with
   the Mode Sense command can be edited and the new page data written
   back to the device. In the case of an Array Controller, the Mode
   Select data will be written to the Array Controller and its attached
   devices. For example:

      0     aa  f0  00  03  00  00  00  11
      8     11  11  11  11  11  11  11  11
      16    11  01  01  01  01  01  11  11
     etc.

   This example is the result of selecting page 0x2a with the Modes
   Sense command and then selecting Mode Select. Byte 3 indicates
   disk 2 failed. To change this, you would enter 3 0x83 and on the
   prompt enter "q". This data would be written to the Array Controller
   and the other good drives as "user failed". Another Modes Sense
   and then Mode Select would show:

      0     aa  f0  00  53  00  00  00  11
      8     11  11  11  11  11  11  11  11
     16     11  01  01  01  01  01  11  11
     etc.

   This indicates that the user has failed drive 2. Now, if you set
   3 0x80 and on the prompt enter "q", this data would be written
   to the Array Controller and the other good drives. The Array Controller
   would now spin up drive 2 and check it out. If this is successful,
   the Array Controller then writes the other drives that drive 2
   is good. This is just a brief example of how the Mode Select command
   interfaces with the Mode Sense.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Format

   The Format Function issues a Format SCSI command to the device
   selected. If issued to an Array Controller, it could force formatting
   of the attached devices and the destruction of all usable data.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Download RAID Microcode 

   The Download RAID Microcode Function loads Array Controller software
   to the Array Controller. You will be prompted whether to download
   to the Array Controller only or the Array Controller and its attached
   devices.

   CAUTION: These selections are not normally used by anyone except the 
   test engineer and manufacturing. They can be destructive and results
   are unpredictable. When the menu is displayed, it will indicate
   which device it will attempt to execute the commands on. Selecting
   these commands on the wrong device can be destructive.

Tape Log Sense

   The Tape Log Sense Function issues a Tape Log Sense SCSI command
   to a Tape device and displays the information returned.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Dump Memory

   The Dump Memory Function displays local memory. You will be prompted
   for the address and size of memory to display.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

MFG Set Up Array Controller

   The MFG Set Up Array Controller Function initializes an Array Controller
   and its attached devices. This function runs with minimum prompting
   of the user and is normally used by manufacturing on the first
   mating of an Array Controller and its attached devices. Starting
   this function will destroy all usable data on the disks attached
   to an Array Controller.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Change Array Controller Levels

   The Change Array Controller Levels Function initializes an Array
   Controller and its attached devices to a new RAID level. This function
   runs with maximum prompting of the user and is used on a known
   good Array Controller and its attached devices. This function is
   used should the user decide to stop at various points in the initializing
   of an Array Controller and its attached devices.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.

Reconstruct a RAID Disk

   The Reconstruct a RAID Disk function instructs the Array Controller
   to reconstruct one of its attached devices from the others. Normally
   used if the Operation System is not running.

   CAUTION: These selections are not normally used by anyone except
   the test engineer and manufacturing. They can be destructive and
   results are unpredictable. When the menu is displayed, it will
   indicate which device it will attempt to execute the commands on.
   Selecting these commands on the wrong device can be destructive.



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:

      Register Tests/
      Direct FIFO Tests/
      Node Addressing/Memory Tests/
      Block FIFO Tests/
      Source/Destination Loopback Tests/
      Parity/Node Interaction Tests/

Register Tests/

   The Register Tests verify the registers on the HIPPI Expansion
   board. The Register Tests menu is shown followed by a description
   of each test:

      960 Self Test
      Diagnostic Control Register
      Source Control/Status Register
      Destination Control/Status Register
      DMA Address Counter Register
      DMA Transfer Counter Register
      DMA Control/Status 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.

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. 

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. 

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. 

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.

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.

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. The Direct FIFO Test Menu is shown followed by a description
   of each test:

      Source FIFO
      Source FIFO Flags
      Destination FIFO
      Destination FIFO Flags
      Source-Destination FIFO Loopback

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.

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.

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.

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.

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. The Node Addressing/Memory
   FIFO Tests menu is shown followed by a description of each test:

      Controller-Node Upper Address Bits
      Controller-Node March RAM

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.

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. The Block FIFO Tests
   menu is shown followed by a description of each test:

      Node RAM-Controller Source FIFO
      Controller Destination FIFO-Node RAM
      Node RAM-Controller FIFO's-Node RAM
      Destination FIFO-Normal Packet-Even Number
      Destination FIFO-Normal Packet-Odd Number
      Destination FIFO-Normal Packet-Abrupt End-Even Number
      Destination FIFO-Normal Packet-Abrupt End-Odd Number
      Destination FIFO-Multipe Packet-Normal End-Even Number
      Destination FIFO-Multiple Packet-Normal End-Odd Number
      Destination FIFO-Normal Packet-Sequence Error-Even Number
      Destination FIFO-Normal Packet-Sequence Error-Odd Number
      Destination FIFO-Normal Packet-Unexpected Disconnect-Even Number
      Destination FIFO-Normal Packet-Unexpected Disconnect-Odd Number

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.

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.

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.

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.

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. 

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.

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.

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.

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.

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.

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.

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.

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. The Source/Destination Loopback Tests menu is shown
   followed by a description of each test:

      Controller S2020 Self Test
      Controller S2021 Self Test
      Controller S2021 Ready-Burst-Buffer Counters
      Controller Programmatic Connect
      Controller Programmatic Connect-Reject
      Controller Programmatic Loopback
      Controller Programmatic Auto Connect
      Controller Burst-Package Out Logic

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.

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.)

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. 

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.

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.

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.

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.

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. The Parity/Node
   Interaction Tests menu is shown followed by a description of each
   test:

      Controller S2020 Parity Logic
      Performance Counter
      Node-Controller RAM Parity Logic
      Controller Parity Regeneration Logic
      Controller Interrupts to Node
      Node Interrupts to Controller
      Controller-Node Cache Coherency
      Node Bus Ownership Retention
      NXTNER Signal to Node

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.   

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.

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.
   --------------------------------+-----------------------------------

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.

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.

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. 

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)
   =======+==================+======+==================+==================

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.

