.PF "''Company Confidential''"

.DF
From: Rob Horning                              Date: 6/12/85
      Craig Robinson

  To: Denny Georg                           Subject: 1 Mbit RAM's

  cc: Mark Ludwig
      Russ Mason
      Russ Sparks
      Jeff Yetter
      Peter Rosenbladt
.DE

This is a proposal to investigate the feasibility of supporting the 1 Mbit
DRAM chips with MC-F.  The Firefox chips' schedule slip coupled with recent rapid
developments of the 1 Mbit RAM chips makes it necessary to revisit this issue.
There have also been some concerns from marketing people that Firefox does
not have enough memory expansion.

It appears to us that the changes should be fairly easy to make.  This needs
to be verified by the MC-F designers.  We would like to know how these
changes will impact (or even reduce) the schedule and man power needs.

The table below shows the cost projections for the 1 Mbit chips and the board
that they would be used in.  It also compares these to the 256K bit parts and
the board they will be used in.  The 1 Mbit price is the
mean of the projections of the 5 Japanese vendors who are developing 1 Mbit
RAM chips.

.DF
.TS
center tab(/) box;
c|c|c|c
l|n|n|n.
  / 1986 / 1987 / 1988
_
1 Mbit chips/40.00/18.00/12.00
8 Mbyte board/$4120/$2036/$1467
256 Kbit chips/$3.00/$2.75/$2.50
2 Mbyte board/$614/$590/$567
.TE
.DE

If 1987 RAM chip cost are used then the cost per byte for the 8 Mbyte board
will be lower than the 2 Mbyte board at introduction.  It is likely that we
will have a need to support the 1 Mbit chips at or shortly after the Firefox
introduction.  (Our competitors will be taking advantage of the 1 Mbit chips.)

.H 1 "Required Changes"

The timing specs for the 1 Mbit chips (the Hitachi preliminary spec)
are very close to the 256K specs.  There are a couple of specs that are
worse but we have a lot of margin in these areas.  Many of the specs
are better.  There are two changes that are required and both have to do
with addressing:
.AL
.LI
There is one more address line.  Two methods of obtaining this address line
are discussed later.
.LI
Refresh has to be done on 9 bits instead of 8.  The refresh time has gone up
to 8 msec and so refresh cycles will happen at the same rate (about 1.5
micro-seconds).  This should be a very easy change to make.
.LE

.H 2 "Extra Address Line"

The most straight forward way of obtaining the extra address line is to add
a pad.  If the PGA changes requires the pad out to be redesigned then the
new address pad should be added.  If the pad out does not have to change
then we will want to avoid causing changes to it.

The other way to obtain the address line is to redefine the nibble address
line (A8) to the new address line.  This line is currently only used for
16 byte accesses.  We still need to support the 16 byte accesses but the
performance is not important on these accesses.  The CA chip and the graphics
designers do not plan on using the 16 byte accesses.  The CPU uses the CLEAR16.
The even 16 byte accesses can be treated the same as they currently are.
The odd accesses can be supported by doing two dummy reads (to the 8 byte wide
memory array) to increment the nibble counter to the desired location.

.H 1 "Board Sizes"

We should not support any half loaded boards.  These make the memory
controller more complex and give very little benefit.  The following
boards should be supported:
.DL
.LI
2 Mbyte - Using 256K bit chips.  This is the low risk board and will be needed
for at least the first year of production to support the low end.
.LI
4 Mbyte - Using 256K bit chips.  This board would be supported only because
it can be supported for free.  It would act as a contingency for the 1
Mbit chips slipping. 
.LI
8 Mbyte - Using 1 Mbit chips.  This would be the first Firefox memory board
using the 1 Mbit chips.  It should be available at or shortly after
introduction.
.LI
16 Mbyte - Using 1 Mbit chips.  This would be later.  It would use either
double sided surface mount or a full size MID_BUS card.
.LE

.H 1 "Conclusion"

We feel that the changes are small enough to MC-F that they should be made now
as opposed to later.  The effort saved by not having to support the half
loaded boards should more than make up for the extra effort required to
support the 1 Mbit chips.

