SpeedRacer Diagnostics Plan
---------------------------

I.  Overview

1.	Bring-up diags

    Bringup diagnostics are for the ISD hardware and O/S groups to 
    verify the proper operation of new system hardware.  In many cases,
    these diags are inappropriate for both manufacturing, and end
    users.


2.	Power-on diags

    Power-on diagnostics are those executed by the boot prom when
    the system is powered-on.  These diagnostics are a sanity check
    of the system functionality necessary to boot Irix.


3.	Field diags

    Field diags are directed at field engineers and end users who 
    wish to isolate system problems on systems that are unable
    to boot Irix.  Current field diags take too long, and include
    many useless legacy tests.

    We need to determine a small set of field diagnostics that
    exercise most components in the system in a relatively short
    period of time (e.g. 30 minutes).  These diagnostics should
    be focused on elements of the system that are difficult to 
    test under Irix (e.g. memory and cache), or are needed to boot
    the system, so that more extensive diagnostics can be run.


4.	Manufacturing diags

    We will let manufacturing deal with mfg diagnostics.  We will
    make available to them a library of field/bringup diagnostics
    that are used by the O/S group, and a means of building IDE.
    Mfg will have a separate directory on the source tree for 
    developing their diagnostics.

    Of course, we will work with mfg and CSD to determine which
    diagnostics will be part of power-on, and the field version
    of IDE.


5.	Miscellaneous

    The ISD O/S group intends to undertake the redesign of IDE with
    two goals:

	To provide a more modular implementation of IDE, so diags
	can be added without impacting the size and development of
	the base IDE.

	To provide a simpler user interface to the base IDE.


II.  Tests

1.	Bring-up diags

    The execution environment for bring-up diags isn't entirely
    determined, but it will consist of both 

	-  Executing IDE diagnostics from a special prom image, and
	-  Loading IDE from an external device (Ethernet or SCSI)

    Power-on diags are a subset of the shipped power-on diags.
    (See (2. Power-on diags) below.) They are run from the prom.

    Emulation will be the first tool to debug and bring-up diagnostics:
    we do not intend to first simulate the code.

    The main emulation system will be built in stages, and the
    diagnostic development will reflect that.


    A.  Main Emulation System Diags

    Phase 1:  R4K, Cache, Memory, Heart, Bridge, Prom, Serial

	CPU/FPU
	Caches
	    No new diags necessary: link existing diags to ide (R4K) [herve]


	Memory
	    Port of current memory tests [anouchka]

	ECC
	    Port of current ECC tests and design of new heart-specific tests 
					[anouchka]

	Heart
	    Level 1 Heart diags [kkn, anouchka]

	Bridge
	    Level 1 Bridge diags [kkn, anouchka]

	System (Heart/Bridge)
	    Level 1 System diags [kkn, anouchka]

    Phase 2:  Same as Phase 1 with SCSI and/or Ethernet

	SCSI
	    New scsi diag [robertn]

	Ethernet
	    New ethernet diag [ddh]

	PCI
	    New tests focused on PCI features [kkn, anouchka]

	System (Heart/Bridge)
	    Level 2 System diags [kkn, anouchka]

    Phase 3:  Same as Phase 2 with Xbow

	System (Heart/Bridge/Xbow)
	    Level 3 System diags [TBD, anouchka]

    Phase 4:  Same as Phase 3 with T5

	CPU/FPU
	    New T5 diags [necessary? port from Shiva?]

	Caches
	    New diags for T5 systems [TBD, dwong]


    B.  IOC3 Emulation System Diags

    The IOC emulation is currently planned as a parallel effort, 
    separately from the Main Emulation effort.

	IOC3 [TBD, anouchka]

	Serial [TBD, dwong]

	Ethernet [TBD]

	Keyboard/Mouse [TBD, jeffs]

	Parallel [TBD, pap]


    C.  Real System Diags

    The base diagnostics used for the real power-on are the
    union of all the above diagnostics.  There will be a few late
    additions:

	T5-MP

	Graphics

	Audio

	Other Digital Media


2.	Power-on diags

    A subset of the shipped power-on diags will be used for bring-up.
    Diags needed early are marked with (*).

    Really early diags - before memory initialization

	*pon_heart - walking 1 on heart register to verify that the memory 
                     controller does not have any stuck bit [anouchka]
	*pon_regs -  checking the datapath to onboard device registers 
                     as part of IOC bring-up (needed only later) [anouchka]

	*pon_addr - walking 0/1 test across address lines [dwong]
	*pon_data - walking 0/1 test across data lines [dwong]

    More diags (from pon_morediags())

	pon_graphics - black box to us, except for size/time policing [gfx]
	pon_caches - cache diags [dwong]
	scsi - scsi diags (ctlr, drives, what?) [robertn]
	kbd/mouse ctlr, kbd, mouse - kbd/mouse diags [jeffs]

   NOTE:  in the pon directory, pon_hndlr, pon_io, and pon_subr.s support 
	  the power on diags but are not diagnostics themselves. 


3.	Field diags

	The goal is to add a simple gui to the field diags that would give
	the user an idea of coverage/length before the tests are initiated.
	We will trim the volume of shipped diags to a small extensively 
	tested set.

