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

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


NODE TESTS
----------

   The Node Tests consist of the following test suites:

        1. Register Tests/
      	2. Memory Tests/
      	3. NIC Tests/
      	4. Multiple Processor Tests/
	5. Floating Point Unit Tests/


Register Tests/ 

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

Register / Control and Mask Register Test

   This test verifies that the DP ASIC and MP3 VDP control/mask
   registers, the NIC control/mask register, the MP3 Node Control
   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.

Register / 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 system processor.  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.

Register / 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 feature 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.

Register / Multiple-bit Error Detection Test

   This test verifies that when data containing multiple bit errors is
   written to memory, the multiple-bit error detected bit in the DP
   status register is set (errors are forced in both DP ASICs, so the
   error bit is checked in both DP_STS_LO and DP_STS_HI).  These errors
   are forced the same way single-bit errors are, by enabling the lower
   byte of a word of data to ECC memory, where that byte is the correct
   ECC value for the word of data, and corrupting multiple bits in the
   upper 24 bits of the word (note that the corrupted bits must be in
   the same 4-bit nibble). 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.

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

Register / MP3 UART Test

   This test checks the UART functionality on the MP3 nodes. The UART
   is an Intel 82510 serial controller. The test puts the controller
   into internal loopback mode which causes the contents of the
   transmit FIFO of the chip to be received immediately by the receive
   FIFO. The data received is compared with the data sent.

Register / Byte Enable Test

   This test checks the byte enables (BE0-7) by using the i860's pixel 
   store instruction.  It sets up data in the lower half of an array 
   and then sets up the PS and PM fields in the processor status register 
   to indicate the pixel size and which pixels are to be written.  The 
   test runs in a loop so all combinations of pixel sizes and masks are 
   tried.  Each pixel store (pst.d) instruction operates on data from the 
   low half of the array and puts the resulting data in the high half of 
   the array. It then checks that the bytes that should have been written 
   were and that the others were left alone.  Any pixels that weren't 
   affected in the correct way are reported as data miscompares.  All
   pixel store instructions used in this test operate on double words.


Memory Tests/

   The tests in this menu verify the DRAM address and data lines and
   the ability of each DRAM location to hold data (data integrity
   tests).

Memory / Data Line Test

   This test checks 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.

Memory / 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.

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.

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 below the high memory address minus 128K bytes (where
   the firmware code is stored).  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.

Memory / DRAM 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.

Memory / ECC DRAM Cell Integrity 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 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 / 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.

Memory / Byte Access Test

   This test writes all of memory from 0xc0100000 to the top of memory
   (except for the area used to store the firmware code) by bytes and
   then reads each byte and checks that it contains the correct data.
   The data written to the bytes is an incrementing pattern starting at
   0x0 and going to 0xff before starting over at 0x0 again. Therefore,
   byte address 0xc0100000 is written with 0x0, 0xc0100001 with 0x1,
   0xc01000ff is written with 0xff, 0xc0100100 is written with 0x0,
   etc. The test also initializes all of memory to be tested with all
   f's (using word writes) before starting the byte writes.

Memory / Byte Access with ECC Check Test

   This test is the same as the byte access test except that the DP
   status register corresponding to each byte written or read is
   checked after the write or read and the single-bit error correct,
   double-bit error detect, and parity error bits are checked to ensure
   none of these errors have occurred. If one has, the test fails. Note
   that during reads, the data is checked for correctness before the DP
   status register bits are checked.

Memory / Address Alternate Test

   This test tries to change as many address and data lines as possible
   on each successive write by writing opposite data patterns to high
   and low memory addresses and interleaving the high and low memory
   writes. The lowest address used is 0xc0100000, and the test checks
   addresses up to the top of memory (except for the memory used to
   store the node firmware).  Data is written as double words, and the
   low memory address is incremented by 8 on each write while the high
   address is decremented by 8 on each write.  The first iteration of
   the test writes low memory addresses with all zeros and high
   addresses with all f's. The second iteration writes low addresses
   with f's and high addresses with zeros. The data is then read by
   words to be checked.

Memory / Memory Unique Test

   This test writes each 32-bit word in memory with a different value
   (a counting pattern starting at zero and incrementing by one for
   each word).  After writing each location, all locations are read and
   the data read is verified for correctness.


NIC Tests/

   This section describes the data transfer tests for the 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.

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 / Programmable Almost Full and Empty 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 / CSR 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 Mode 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.

NIC / LTU Transfer Test

   This test checks the basic functionality of the node board'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 five test cases that transfer 32, 2, 128, 256,
   and 512 lines of data, respectively (two is the minimum and 512 is
   the maximum number of lines that can be transferred).

NIC / 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.

NIC / Long LTU Line Count Test

   This test does LTU transfers when the system processor has modified
   data in both the transmit and receive buffers and verifies that the
   correct data shows up in memory after the LTU transfer.

   The test follows this sequence of steps on each test case:

           * flush the cache;
           * initialize three cache lines before the transmit and receive 
  		   buffer starting addresses to 0xc1c1c1c1 and 0x76767676, 
		   respectively;
           * cause one line of data from the transmit buffer to be put 
       		   into the cache;
           * write new data into the transmit buffer to modify the one line 
		   already in cache;
           * cause the corresponding line of data in the receive buffer to 
 		   be cached;
           * write data to the receive buffer to cause the cached line to 
		   become modified;
           * start transmit and receive LTUs for some amount of data (the 
		   line count varies with the test case) and wait for them 
		   to complete;
           * compare the data transferred to the receive buffer with that in 
		   the transmit buffer to make sure they match; also check the 
		   equivalent of three cache lines preceding and following the 
		   transmit and receive buffers to make sure all are correct;
           * any miscompares indicate possible coherency problems

   The test does LTU transfers with line counts from 0x3 to 0x200, and
   does six transfers for each line count, with a different cache line
   containing modified data on each transfer. The modified cache line
   varies from m - 3 to m + 2, where m is the number of lines to be
   transferred by the next LTU transfer.  Note that when the line count
   is greater than m, the line modified is not transferred on that test
   case. This provides a check that modified data near the data to be
   transferred does not somehow get transferred.

   The test also checks 24 words (the equivalent of three cache lines)
   before and after the transmit and receive buffers to ensure they did
   not change from the pattern they were initialized to.

   The transmit buffer used in this test starts at 0xf0100000, and the
   receive buffer starts at 0xf0200000. The data patterns below are
   used to initialize the areas specified:

           0xc1c1c1c1 - preceding transmit buffer
           0x32323232 - following transmit buffer
           0x76767676 - preceding receive buffer
           0x55551111 - following receive buffer
    
NIC / LTU All Mod Line Count Test

   This test is similar to the LTU Line Count test except that all
   lines in the transmit and receive buffers are modified before
   starting the LTU transfers instead of just one line. Also, the line
   counts in this test range from 0x2 to 0x200, and only one set of LTU
   transfers is done for each line count instead of six.

   The test also checks 24 words before and after the transmit and
   receive buffers to ensure they did not change from the pattern they
   were initialized to.

   The transmit buffer used in this test starts at 0xf0100000, and the
   receive buffer starts at 0xf0200000. The data patterns below are
   used to initialize the areas specified:

           0xc1c1c1c1 - preceding transmit buffer
           0x32323232 - following transmit buffer
           0x76767676 - preceding receive buffer
           0x55551111 - following receive buffer
    
NIC / LTU Invalidate Line Count Test
    
   This test is also very similar to the LTU line count and LTU all mod
   line count tests except that it modifies all lines in the transmit
   and receive buffers except one before starting the LTU transfers.
   This test has test cases for line counts from 0x3 to 0x200, and for
   each line count, six subcases are performed, with a different line
   being left unmodified in each subcase.  In the subcases, the line
   left unmodified varies from m - 3 to m + 2, where m is the line
   count for that test case. Only lines of data transferred during the
   LTU are checked for correctness, along with 24 words preceding and
   succeeding the transmit and receive buffers.

   The test also checks 24 words before and after the transmit and
   receive buffers to ensure they did not change from the pattern they
   were initialized to.

   The transmit buffer used in this test starts at 0xf0100000, and the
   receive buffer starts at 0xf0200000. The data patterns below are
   used to initialize the areas specified:

           0xc1c1c1c1 - preceding transmit buffer
           0x32323232 - following transmit buffer
           0x76767676 - preceding receive buffer
           0x55551111 - following receive buffer
 

Multiple Processor Tests/

   The Multiple 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.

Multiple Processor / 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(s), 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.

Multiple Processor / DP and NIC Interrupt Test

   This test checks that the NIC interrupt, system to user processor
   interrupt, user to system processor interrupt, the two DP OS timer
   interrupts, and the MP3 VDP OS timer interrupt 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
   o	VDP OS Timer- forced by writing a large value into the VDP OS 
                      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.

Multiple Processor / Processor Read and Write Coherency Test

   This test checks that if one processor has modified data in its
   cache and the other processor does a read or write, the modified
   data is evicted to memory.  This test checks all four combinations:
   the system processor having modified data in its cache and the user
   processor(s) attempting a read and a write, and the user
   processor(s) having modified data and the system processor
   attempting a read and a write.  The test also tries each combination
   with data types of byte, short, word, and double.

Multiple Processor / System Processor and 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.

Multiple Processor / System, User, and 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 having the system processor start an
   LTU transfer, and then having the system and user processors run the
   same piece of code, which is a DRAM controller test.  This means the
   LTU and all processors are arbitrating for the bus at the same
   time.  The test verifies that the LTU completes and that the data
   transferred is correct, and that the system and user processors all
   ran the dram controller 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(s) 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.

Multiple Processor / User Processor and LTU Coherency Test

   This test checks that if data in the user processors' 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	system processor initializes two areas in memory with known data 
        patterns (area1 with pattern1, area2 with pattern2)
   o	user processor reads area1 to fill the cache with data
   o	user processor modifies the data in the cache with pattern3
   o	system processor starts an LTU transfer from area1 to area2
   o	system processor checks that memory area2 now contains pattern3


Multiple Processor / User Processor LTU Test

   This test checks that an LTU transfer started by the user
   processor(s) transfers data correctly, and that the user
   processor(s) can detect when the LTU transfer is complete.  The test
   consists of three test cases, which transfer 32, 2, and 128 lines of
   data, respectively.  Besides checking that the LTU transfers
   complete correctly, the data transferred on each test case are
   checked for correctness.

Multiple Processor / System Processor and LTU Receive Test

   This test checks that if data in the system processor's cache is
   modified and an LTU transfer is done from different memory locations
   than the data in cache, the data from the cache is NOT the data
   transferred during the LTU.

   The test follows these basic steps:
   o	initializes two areas in memory with known data patterns (area1
        with pattern1, area2 with pattern2)
   o	reads area2 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 pattern1

Multiple Processor / User Processor and LTU Receive Test

   This test checks that if data in the user processors' cache is
   modified and an LTU transfer is done from different memory locations
   than the data in cache, the data from the cache is NOT the data 
   transferred during the LTU. 

   The test follows these basic steps:
   o	initializes two areas in memory with known data patterns (area1
        with pattern1, area2 with pattern2)
   o	reads area2 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 pattern1

Multiple Processor / User Processors Coherency Test

   This test checks coherency between the 2 MP3 user processors. When
   one user processor has modified data in its cache and the other user
   processor writes that location, the data in the first user
   processor's cache is verified to be invalidated.


Floating Point Unit Tests/

   These tests check the functionality of the floating point unit (FPU)
   in the i860.  The tests are made up of general floating point tests
   and ones that check the functioning of various rounding modes of the
   FPU.

Floating Point Unit / General Math Test

   These tests provide a basic sanity check of the i860 floating point
   unit.  The tests consist of the following sub-tests:

   	* Summation Test
   	* Anti-Summation Test
   	* Negative Summation Test
   	* Anti-Negative Summation Test
   	* Double Test
   	* Divide and Subtract Test
   	* Factorial Test
   
Summation Test

   This test performs a cumulative sum of two double-precision floating
   point numbers.

   Two double-precision floating point numbers, a and b, are first
   initialized to 0.0. Then, in a loop of 5, 1000.0 is added to b and b
   is added to a.  At the end of the loop a is checked for 15,000.0.

   This test exercises the fadd.dd instruction (floating-point add
   double precision source to double-precision destination).

Anti-Summation Test

   This test performs a cumulative subtraction on two double-precision
   floating point numbers.

   Two double-precision floating point numbers, a and b, are used. A is
   first initialized to 15000.0 and b is initialized to 0.0. Then, in a
   loop of 5, 1000.0 is added to b and b is subtracted from a. At the
   end of the loop a is checked for 0.0.

   This test exercises the fsub.dd instruction (floating-point subtract
   double precision source to double-precision destination).

Negative Summation Test

   This test performs a cumulative summation of two negative
   double-precision floating point numbers.

   Two double-precision floating point numbers, a and b, are first
   initialized to 0.0. Then, in a loop of 5, 1000.0 is subtracted from
   b then b is added to a. At the end of the loop a is checked for
   -15000.0.

   This test exercises the fadd.dd and fsub.dd instructions.

Anti-Negative Summation Test

   This test performs a cumulative sum of a double-precision negative
   number and a double-precision positive number.

   Two double-precision floating point numbers, a and b, are used. A is
   first initialized to -15000.0 and b is initialized to 0.0. Then, in
   a loop of 5, 1000.0 is added to b then b is added to a. At the end
   of the loop a is compared with 15,000.0.

   This test exercises the fadd.dd instruction (floating-point add
   double-precision source to double-precision destination).

Double Test

   This test performs a cumulative sum of two double-precision floating
   point numbers.

   Two double-precision floating point numbers, a and b, are used. A is
   first initialized to 0.0 and b is initialized to 100.0. Then, in a
   loop of 10, b is added to a and b is assigned the new value of a. At
   the end of the loop a is checked for 51200.0.

   This test exercises the fadd.dd instruction (floating-point add
   double-precision source to double-precision destination).

Divide and Subtract Test

   This test performs a cumulative divide of two double-precision
   floating point numbers.

   Two double-precision floating point numbers, a and b, are first
   initialized to 51200.0. Then, in a loop of 10, a is multiplied by
   0.5 (divided by 2) then a is subtracted from b. At the end of the
   loop a is compared with b.

   This test exercises the fmul.dd instruction (floating-point multiply
   double-precision source to double-precision destination).

Factorial Test

   This test performs a cumulative multiply and sum of two
   double-precision floating point numbers.

   A is first initialized to 1.0 and b is initialized to 2.0. Then, in
   a loop of 9, a is multiplied by b then 1.0 is added to b. At the end
   of the loop a is checked for 3628800.0 (9!).

   This test exercises the fmul.dd instruction (floating-point multiply
   double-precision source to double-precision destination).


Floating Point Unit / Rounding Mode Test

   These tests provide a check of the i860 floating point unit adder
   pipeline.  The tests consist of the following sub-tests:

   	* Adder Pipe Restore (+n)
   	* Adder Pipe Restore (-0 .ds)
   	* Adder Pipe Restore (-0 .sd)
   	* Adder Pipe Restore (-0 .dd)
   	* Adder Pipe Restore (-0 .ss)
   
Adder Pipe Restore (+n)

   This test checks that the floating-point unit adder pipeline can
   properly restore the adder pipeline in all 4 rounding modes using
   all positive single-precision floating-point numbers (+n).

   First the adder pipe is filled and saved. Next the pipeline is
   checked to verify the save worked correctly. Finally, the pipe is
   restored in each of the 4 rounding modes and checked.

   This test exercises the floating-point unit adder pipeline in all 4
   rounding modes.

Adder Pipe Restore (-0 .ds)

   This test verifies the adder pipeline maintains the integrity of -0
   while -0 is being shifted through the pipe and being converted from
   double precision to single precision.

   First the adder pipeline is filled with double-precision -0
   (pfamov.ds). Then the adder pipeline is emptied into the destination
   registers. Finally, the destination registers are compared with
   single-precision -0.

   This test is repeated for each of the 4 rounding modes.

Adder Pipe Restore (-0 .sd)

   This test verifies the adder pipeline maintains the integrity of -0
   while -0 is being shifted through the pipe and being converted from
   single precision to double precision.

   First the adder pipeline is filled with single-precision -0
   (pfamov.sd). Then the adder pipeline is emptied into the destination
   registers. Finally, the destination registers are compared with
   double-precision -0.

   This test is repeated for each of the 4 rounding modes.

Adder Pipe Restore (-0 .dd)

   This test verifies the adder pipeline maintains the integrity of
   double-precision -0 while -0 is being shifted through the pipe.

   First the adder pipeline is filled with double-precision -0
   (pfamov.dd). Then the adder pipeline is emptied into the destination
   registers. Finally, the destination registers are compared with
   double-precision -0.

   This test is repeated for each of the 4 rounding modes.

Adder Pipe Restore (-0 .ss)

   This test verifies the adder pipeline maintains the integrity of
   single-precision -0 while -0 is being shifted through the pipe.

   First the adder pipeline is filled with single-precision -0
   (pfamov.ss). Then the adder pipeline is emptied into the destination
   registers. Finally, the destination registers are compared with
   single-precision -0.

   This test is repeated for each of the 4 rounding modes.
