-*- Mode:Text -*-
Bob Powell
11/21/86

1. Master schedule and plan for K and IOP HW and SW:
	TBD - revise Bruce's sheet.

================

2. Development Plan for K:

  2.1: Schedule
	TBD

  2.2: Material and Equipment
	Boards, parts, test racks, test equipment

    2.2.1: Boards:
	Make three sets of board blanks, populate two.

    2.2.2: Parts:
	Parts and spares for two board sets to be kept in Cambridge HW lab.

    2.2.3: Test stations: (Nubus version)
	First rev (nubus) boards: two stations consisting of:
		Nubus test rack with K processor and LMI Debug board.
		Associated LAMBDA and Debug board as debug master.
		Probably no disk drive or other I/O device until VME version.
	LAMBDAs are halves of one 2x2, located in machine room.
	Test racks located in classroom.
	Software link to Daisy system TBD.
	Describe test rack setup and configuration.

    2.2.4: Test stations: (VME version)
	TBD.

    2.2.5: Software required for debug.
	Lambda-diag.
		Nubus-level code is preserved.
		Command interface is preserved.
		Register-level read/write routines rewritten for K state.
		State analysis code rewritten for K.
	We can get started with an unmodified lambda-diag, and
	hack it as required.  (Design: Joe or Pace; Impl: any of SW)

  2.3: Functional verification and test procedures.
	(Engineering Diagnostic Plan)

    2.3.1: Initial hardware bootstrap sequence:

      2.3.1.1: Initial static verification of subsections of machine.
	ALU, Registers, Call HW, cache, DRAM, memory interface,
	bus interface, GC, Data type, Map, trap sequence etc.

      2.3.1.2: Dynamic verification of independent subsections of machine.
	Same as above

      2.3.1.3: Initial verification of larger parts of machine.
	Sections listed above working together.
	May be preceded by static verification.

      2.3.1.4: First code in boot proms:
	Test that instruction bits get where the should etc.
	Zeroes, then real instructions.

      2.3.1.5: Run code that exercises DRAM:

      2.3.1.6: First code in RAM:
	Faster turnaround than ROM.

      2.3.1.7: Test and enable Icache.

    2.3.2: Evolution of useful diagnostics:

    2.3.3: Evolution of useful software primitives:

2.4: Personnel (for HW development)
	Kent:
		Engineer in charge; design all low-level diags,
		most of the additional diags.
	Rich McGarry:
		Board tech, diagnostic programming.
	Joe, Naha, Youcef:
		(Primarily System S/W)
		Help Kent with test SW, HW functionality and SW primitives.
	BobP:

================

3. Manufacturing Diagnostic Plan
	TBD.
	Initial debug is part of Development Plan.