.H 1 "FIREFOX RAM TIMING"

This is a summary of the Firefox RAM timing.  The test array has been evaluated
and more spice modeling has been done.  There are a number of issues that
need to be made visible.  This write up will attempt to do that.  Any
disagreements need to be resolved in the next couple of weeks or we risk
slipping the schedule.

.H 2 "Summary of the Main Issues"

There are four main issues that have surfaced as a result of analyzing the
timing:
.AL
.LI
The 32 byte cache line access will take 16 MID_BUS states (4 wait states).
.LI
A split phase loop will be required to allow edges to be placed half way
between the 25 ns clock edges.
.LI
The specs on the 20 MHz library pad drives need to be improved.  This may
require them to be redesigned.
.LI
The memory PC board may have to go to 8 layers.  This is because trace
lengths and how they are connected need to be more tightly controlled.
.LE

.H 2 "Timing Details"

A timing diagram of the cache line read and write cycles is attached.  The
table below lists the critical timing parameters.

.DF
.TB "Timing Parameters"
.TS
center tab (/) box;
l|l|n|n.
#/Parameter/Min/Max
_
1/Clock to address/0/20
_
2/Address board delay/0/30
_
3/Clock to RAS/0/10
_
4/RAS low board delay/0/25
_
5/Clock to first CAS/0/10
_
6/CAS low board delay/3/16
_
7/CAS to data valid at MC/0/32
_
8/Clock to CAS high/4/10
_
9/CAS high board delay/2/12
_
10/Clock to nibble CAS/14/24
_
11/Clock to data/0/10
_
12/Data board delay/0/7
.TE
.DE

The timing parameters were arrived at by analyzing the RAM test array board,
doing spice modeling, and by estimating what the MC could do.

The timing specs for the MC must include any skew caused by the clock
circuits and split phase loop.  All the specs given are relative to a perfect
20 MHz dual phase clock.  Read data must be available at the MID_BUS
interface with enough margin to allow for clock delay.  This should not be
difficult but must not be overlooked.

How the critical timing parameters were derived is discussed below.

.H 3 "Clock to Address"
This spec is to insure that address will be valid by the time that RAS goes
low about 50 ns later.  The address needs to be clocked to the RAM's on the
same edge as it is clocked into the MID_BUS interface.  It is acceptable to
clock the RAS address before the rest of the address is decoded.

.H 3 "Address Board Delay"
This is the largest board delay.  This allows for address buffers to be used
for a future 4 Mbyte memory board.

.H 3 "Clock to RAS"
Less time is given here than for address because it is an MC generated signal
and does not have to be clocked through the MID_BUS interface.

.H 3 "RAS Low Board Delay"
This is a fairly large time because the MC must drive 39 RAM's and only a
few PC layout restrictions will be put on the RAS signal.  Because of this a
large damping resistor will be needed to insure a glitch free signal.  This
will slow the signal down.

.H 3 "Clock to First CAS"
This is the same as RAS.

.H 3 "CAS Low Board Delay"
CAS is the most critical timing parameter.  In order to met the timing
requirements the MC will provide two CAS drivers for each bank of memory.
The PC board will be laid out in a star type matter were all branches are
balanced and all the RAM's are the same distance from the driver.  This
allows a fairly small damping resistor and thus a faster signal.  The specs
were derived by using spice to model worse case conditions for the fast
and slow cases.  The FET model for the 20 MHz library was used for the
modeling.  It is assumed that this same FET will be used on PUMA.

.H 3 "CAS to Data Valid at MC"
This allows 30 ns for the nibble mode access and 2 ns board delay.  The data
lines will be required to be no longer than a total of 6 inches.  The
RAM array test board has some about 12 inches long.  It will take additional
PC area (layers) to shorten the traces.  It is assumed that the input high
voltage for the MC receiver will be 2 volts.

.H 3 "Clock to CAS High"
This is the same as RAS.

.H 3 "CAS High Board Delay"
This was derived in the same way as CAS low board delay.

.H 3 "Clock to Nibble CAS"
In order to meet this timing spec a split phase loop will be needed.
This will most likely be the most difficult spec for the MC to meet.
There is a total of only 10 ns skew allowed for both the split phase
loop and the pad driver.  It is critical that this spec be met.

.H 3 "Clock To Data"
This is treated like RAS because it can be clocked off the MID_BUS before
it has to be clocked to the RAM's.

.H 3 "Data Board Delay"
This was derived using spice modeling.

.H 2 "Alternatives"

It is assumed that the issues listed earlier are not reason enough to
redefine the MC to resolve them.  This section discusses some things that
could be done to resolve the issues.  These alternatives have not been
fully evaluated and there is not time to do this.  If we want to use these
alternatives we need make the decision right away so that we can continue
with the design.

.H 3 "Interleaving"

The memory banks could be interleaved to eliminate two of the four wait states
and the need for the split phase loop.  This would cause two problems:

.AL
.LI
We would not be able to support a Mbyte board.
.LI
Additional buffering would be required.
.LE

The buffering could be provided either on the MC or with TTL.  If it was done
on the MC a larger PGA would be needed.  If it was done with TTL 10 buffers
would be needed and it is not clear that they would fit on the board.

If interleaving is implemented it may be beneficial to change the error
correction algorithm to correct a 64 bit word.

.H 3 "Slow Down the MID_BUS"

If the split phase loop can not be done and the pad drivers can not be
redesigned then the MID_BUS could be slowed to 8 MHz.  This would have
a noticeable effect on the performance of Firefox (about 10%).

.H 3 "Add Wait States"

It would be better to add a couple of wait states to the cycle than to slow
down the MID_BUS.  This would lower the performance by about 8%.

.H 3 "Design a New MID_BUS Interface"

The MID_BUS interface requires that the data be valid at the MC 200 ns before
it needs to be valid on the MID_BUS.  If this could be reduced to 100 ns then
a wait state could be eliminated.

