.H 1 "FIREFOX RAM CONTROLLER MUSTS AND WANTS"

This is a expansion of the must and wants for the Firefox RAM controller.
The first section explains all the musts that were listed in the memo to
Denny Georg (2/14/84).  The second section list the wants and gives them a
weight.

.H 2 "MUSTS"

.H 3 "Schedule"
Schedule is the number one priority for Firefox.  It is a definite must that
we have working parts that can go through class B by March 15.  We must have
production parts in August.

.H 3 "RAM Speed"
It is a must that the controller work with 120 nsec. RAM's.
We may not be able to get any faster RAM's during early production and
when they are available they will cost more.

.H 3 "Clock Speed"
The controller must use only the 10 MHz MID_BUS clock.  This must can be
reworded to say that it uses only clocks that are provided by a standard
MID_BUS connector.  The RAM board in Firefox will have only one connector and it
will be the standard MID_BUS connector.  If MID_BUS is redefined to have
a 30 MHz (or 20 or 40 MHz) clock in addition to the 10 MHz clock then of
course the clock may be used.

.H 3 "Board Reliability"
There were two must listed that related to system reliability.  These allowed
failed RAM chips to remain in the system.  To do this  requires that 
any speed degradation
caused by doing a correction must not be perceivable to the user.  It was
estimated that about 2 MID_BUS wait states could be added.  It is also a must
that soft errors can still be reliably corrected when there is a failed RAM
chip.  We need this feature if we are to meet the computer group reliability
goals.  We consider the reliability goals as musts.

.H 3 "Number of Banks"
It was stated that the RAM controller had to support up to 4 Mbytes.  The
Firefox RAM board will only be 2 Mbytes and so we may not be able to justify
this as a must.  It would however be short sighted to support less
than 4 Mbytes.  There is a contingency that would require the RAM board to
grow to 4 Mbytes.  It is considered a must to keep this
contingency open for at least the next few months.

.H 3 "Chip Reliability"
The chip reliability had a must stated as .2%.  Firefox could still meet
the reliability goals if this number was as high as .4%.  We would however
be counting on the rest of the system to (from a reliability point of view)
support the VLSI controller.  A primary reason for using VLSI is to improve
the system reliability.  We need the VLSI chips to more than carry there weight
in meeting the reliability goals.

.H 3 "Input/Output Compatibility"
It was stated that the outputs needed to be compatible with TTL buffers and
MOS RAMS.  This statement could be restated more specificly if needed.  The
idea is that it work with the Firefox RAM board(s).  The memory controller
must not require any control or reset signals that are not provided by the
MID_BUS.

.H 3 "Error Reporting"
It is a must that the operating system be able to detect and identify
failed boards and RAM chips.

.H 3 "Power"
The RAM controller must not use more than 5 Watts.
Most of this power must come from the +5 volt supply.  No voltages other
than +5, -12, and +12 can draw more than 10 mA.  Any power used to
regulate other voltages has to be taken from the 5 watt budget.

.H 2 "Wants"

.H 3 "Speed - 10"
The highest want is to minimize the number of wait states to obtain the
maximum performance.  If the timing is close we may want to slow down
the MID_BUS instead of adding wait states. (This would also mean slowing down
the CPU clock.)

.H 3 "Correction Speed - 9"
It is a high want to correct errors with no speed degradation.  There will
be some applications that will notice even a small degradation and it
is desirable to avoid the problems this would cause.

.H 3 "Self-test - 6"
It is a want to have the features in the RAM controller that aid the CPU
in the power up self-test.  The reason for this is to minimize the time
it takes for the system to power up.  It is also a want to have the
capability to disable all the outputs of the memory controller so that
the board tester can drive the RAM array.

.H 3 "Availability - 5"
There was a want listed that stated that the board should function in
a degraded mode with two hard failures.  This is a medium want.  It gives
the customer partial use of the machine (even with a minimal RAM system)
until the machine in serviced.  It is not a high want because most systems
that require high availability will have more than one Mbyte of RAM and so
they could continue to function with on bank mapped out.

.H 3 "Power Supply - 4"
It is desirable to use only 5 volts to reduce the number of parts needed on
the RAM board.  This will help the cost and reliability.  The RAM board is
very space limited and having fewer parts also helps this problem.

.H 3 "Number of Banks - 2"
It is a low want to be able to control up to eight 1 Mbyte banks of RAM.

.H 3 "Reliability - 2"
It is a low want to have a failure rate of better than .1%/year. (As long
as the .2% must is met.)

.H 3 "Drive - 1"
It is a low want to be able to hook up the RAM with no buffers on any lines
that go to the RAM chips.  A few buffers can be added without causing
problems with board space.

.H 3 "RAM Chip Speed - 1"
It is a low want to work with 150 nsec. RAM chips.  The RAM vendors are saying
that by 1Q86 there will be little if any savings over the 120 nsec. RAM's.
There would be some savings in prototype boards if the slower RAM's could
be used.

