.H 1 "Firefox 11 Board Theory of Operation"

This is the theory of operation for the Firefox 11 board.  This is also
the 13 board when the math chips are not loaded.  It would be useful to
have an 11 board schematic, the ERS, a copy of the MID_BUS standard and
the 11 board timing diagram.

The 11 board contains everything that could be moved off the CPU board
(the 10 board).  It contains the PDC ROM, the real time clock (RTC), the non-volatile
memory (NVM), the floating point math chips,  CIO to MID_BUS adapter (CA chip),
the latch for the front panel LED's, and the system clock.

.H 1 "Processor Dependent Hardware (PDH)"

The PDH is the ROM, the RTC, the non-volatile memory, and the LED latch.
The PDH is controlled by two PAL's.  The PAL's select the PDH device being
addressed and provide proper timing for the reads and writes for the
device being accessed.

.H 2 " Address Space"

There are two fixed areas that are used by the PDH.  These areas are decoded
by the SIU-F (on the CPU board).  When these areas are selected a transaction
is started by the assertion of a special signal
(NPAV), which has the same meaning as ADD_VALID on MID_BUS.  The first area
is from hex address 1F00 0000 to 1FFF FFFF.  This is the Processor Dependent
Code (PDC) area.  The second area is from hex address F000 0000 to F000 7FFF.
This is the PDH IO address space (RTC, NVM, LED latch).  The pals do not distinguish between these
two address spaces.  The ROM aliases into the IO space and the IO devises
alias into the ROM space.

When the PDC space is accessed, the SIU will always access four consecutive
bytes.  The PDH hardware will treat these as four separate accesses.  Writes
are not allowed to the PDC space.  (This is an SIU restriction.)

Writes are allowed to the PDH IO space.  A read or a write will only cause
one access in this space.  Only every fourth byte can be accessed because
MID_BUS supports only word accesses to IO space.  Bits
30 and 31 of the address will always be zero for accesses to the IO space.

The Following things happen when the SIU accesses the PDH:
.AL
.LI
The SIU requests the bus.
.LI
When it gets the bus it drives the address on the MID_BUS and asserts NPAV.
(Parity is valid but the PDH does not check it.)
.LI
The PDH will assert wait for 11 MID_BUS states.
.LI
The PDH returns data on ADD_DATA0-7 of the MID_BUS.  The PDH does not drive
parity and the SIU does not check it.
.LI
The SIU gives up the MID_BUS.
.LE

This is not a regular MID_BUS transaction because the SIU does not check
parity and takes the bus and
never does assert ADDRESS_VALID before giving it up.  The assertion of address
valid is what starts a transaction on MID_BUS.

.H 3 "PDH Address Decoding"

As was mentioned earler, most of the address decoding for the PDH is done by
the SIU.  The PDH only selects the PDH devise to be accessed.  It does not
distinguish between the PDC and the IO space.  It uses only address bits 13,
14, and 15 from the MID_BUS to determine which PDH device to select.  Latch
U12A latches the address and provides it to the PAL's.  This latch also latches
READ_WAIT_L (Low level means that it is a read).  The table below shows how the
address lines are used to select the PDH devices.

.DS
.TS
center tab (/) box;
c|c|c|c|c
l|c|c|c|c.
Device/ADD13/ADD14/ADD15/ROMSIZE
_
PDC ROM1 (U2)/0/0/0/1
PDC ROM2 (U3)/0/0/1/1
PDC ROM3 (U37)/0/1/0/1
Undefined/0/1/1/1
PDC ROM1 (U2)/0/0/X/0
PDC ROM2 (U3)/0/1/X/0
Stable Store (U1)/1/0/X/X
RTC-Status (U9,12B)/1/1/0/X
LED Latch (U32)/1/1/1/X
.TE
Note: X means don't care 
.DE

ROMSIZE is jumper JP3 and is used to determine the size of the ROM being
used.  If the signal is high the ROM size is 64K bytes.  If it is low the size
is 128K bytes.

The table below shows the address range for each of the devices.  As was
mentioned earlier the PDC ROM's alias to the PDH IO area and visa-versa.

.DS
.TS
center tab (/) box;
c|c|c|c|c
l|c|c|c|c.
Device/Address Space/ROMSIZE
_
PDC ROM1 (U2)/1F00_0000 to 1F00_FFFF/1
PDC ROM2 (U3)/1F01_0000 to 1F01_FFFF/1
PDC ROM3 (U37)/1F02_0000 to 1F02_FFFF/1
Undefined/1F00_0003 to 1F03_FFFF/1
PDC ROM1 (U2)/1F00_0000 to 1F01_FFFF/0
PDC ROM2 (U3)/1F02_0000 to 1F03_FFFF/0
Stable Store (U1)/F004_0000 to F005_FFFF/X
RTC-Status (U9,12B)/F006_0000 to F006_FFFF/X
LED Latch (U32)/F007_0000 to F007_FFFF/X
.TE
Note: X means don't care 
.DE

If the PDC IO devices are accessed in the PDC ROM area the same data will be
returned in all four bytes of the word.  There will be four accesses to the
same location.  If the the PDC ROM is accessed in the PDC IO area only every
fourth byte is accessible.

.H 3 "The PAL Equations"

This section discusses the PAL equations for the two PAL's (U13 and U15).
U15 will be called PAL1 and U14 will be called PAL2.  The PAL's are used
to implement a 15 state state machine.  The PAL equations were reduced by
using logic reduction maps.  If the timing needs to be changed the equations will
have to be used to reconstruct the logic reduction map and reduced again.  The
equations will be easier to understand with a copy of the PAL timing
diagram (B-09850-66511-7).

.H 4 "The State Counter"

The outputs on pins 15-18 of PAL1 are used as a gray code counter (only one
bit changes for each count increment).  The timing diagram shows the gray
code used.  The gray code was used to avoid race conditions on the non-latched
outputs.  The equations for each of the count bits are listed below:

.DS
    Count0 :=  /Count0 * PAV * PON * /ERROR
             + /Count1 * Count2 * PON * /ERROR
             + Count0 * /Count1 * PON * /ERROR
             + Count0 * Count2 * /Count3 * PON * /ERROR
.DE
.DS
    Count1 :=  Count1 * /Count2 * /Count3 * PON * /ERROR
             + Count0 * /Count3 * PON * /ERROR
             + Count0 * Count1 * PON * /ERROR
             + Count0 * /Count2 * PON * /ERROR
.DE
.DS
    Count2 :=  /Count0 * Count1 * /Count3 * PON * /ERROR
             + Count2 * /Count3 * PON * /ERROR
             + /Count0 * Count2 * PON * /ERROR
             + Count1 * Count2 * PON * /ERROR
.DE
.DS
    Count3 :=  Count0 * Count1 * Count2 * PON * /ERROR
             + Count2 * Count3 * PON * /ERROR
             + Count0 * Count3 * PON * /ERROR
.DE

The Slash means the the signal is negative true.  The signals coming out of
the PAL are negative true.

The State machine will stay at the 0000 state until NPAV is valid.  It will
then count for 14 counts and reset to the 0000 state.  The MID_BUS PON signal
or ERROR signal will cause the  state machine to reset to the 0000 state.

.H 4 "MID_BUS Control"

The timing for the MID_BUS is controlled by the PAL's.  The PAL's are not fast
enough to meet the timing edge requirements for MID_BUS and so the last state
of the state machine for the MID_BUS control is provided by an AS74 (U16).
The details of the MID_BUS timing are explained later.  The PDH must assert
2 signals plus the 8 data lines on reads.  WORD_SLAVE is assered low during
the third MID_BUS state after the address state.  This signal does
not have to be restored high by the PDH.  WAIT_SLAVE is asserted low at the
same time as WORD_SLAVE and is pulled high when the PDH has the data valid on reads or
has finished the transaction on writes.  There are two PAL signals
used to control the MID_BUS timing.  The first enables WORD_SLAVE, READ_WAIT,
and the data buffer (PAL1 pin 14).  The second causes READ_WAIT to go high (PAL2 pin 13).
The PAL equations for these signals are given below:

.DS
      ENABLE = Count1 * /Count3
              + Count2
              + Count0 * /Count3
.DE

.DS
      READ_WAIT = Count2 * Count1
                 + Count2 * /Count0
                 + /Count3
.DE

.H 4 "ROM Enables"

The PDH can support three 512K bit EPROM's or two 1 Mbit ROM's.  Jumper JP3
is used to determine if the ROM's or EPROM's are being used.  ROM1 (U2) and
ROM2 (U3) use the non latched outputs of the PAL (U15 pins 12 and 19
respectively).  ROM3 (U37) is enabled by U15 pin 13.  The PAL equations for
the ROM's are given below:

.DS
IF (PON) ROM1 =
         Count0 * Count3 * /ADD13 * /ADD14 * RSIZE
         + Count2 * /ADD13 * /ADD14 * RSIZE
         + Count0 * Count3 * /ADD13 * /ADD14 * /ADD15 * /RSIZE
         + Count2 * /ADD13 * /ADD14 * /ADD15 * /RSIZE

.DE
.DS

IF (PON) ROM2 =
         Count0 * Count3 * /ADD13 * ADD14 * RSIZE
         + Count2 * /ADD13 * ADD14 * RSIZE
         + Count0 * Count3 * /ADD13 * /ADD14 * ADD15 * /RSIZE
         + Count2 * /ADD13 * /ADD14 * ADD15 * /RSIZE

.DE
.DS

 ROM3 :=  Count2 * /ADD13 * ADD14 * /ADD15 * /RSIZE
 + Count0 * /Count1 * Count3 * /ADD13 * ADD14 * /ADD15 * /RSIZE

.DE

The ROM1 and ROM2 enable signals will be tri-stated when PON is low.  This
is done for test purposes and to prevent a bus conflict when power comes up.
(More on this later.)

.H 4 "LED Latch"

The LED latch (U32) is clocked by pin 14 of PAL2.  The LED's are turned on by
writing a zero to the corresponding bit.  The LED latch is also used to provide
a serial data path (output only) with two signals called FPCLOCK and FPDATA.
These signals are used by the AP card and are also used to monitor status
during environmental testing.  These two applications have different
requirements.  Both are described below.

AP card requirements:
.DL
.LI
To start a transaction the FPCLOCK line must be low for at least 500 ns
to reset the interface.
.LI
Data (FPDATA) must be set up for 100 ns before FPCLOCK goes high.
.LI
FPCLOCK will remain high and pulse low to clock in successive data bits.
It must not pulse low for more than 500 ns or the interface will reset.
(This is the normal way to end a transaction.)
.LI
When all the bits are transferred FPCLOCK is brought low again.
.LE

Environmental test requirements:
.DL
.LI
FPCLOCK must change slow enough for a Pascal program to determine that it has
changed.  It must be under direct software control.
.LE

Both of these requirements are met by the design.  The FPCLOCK line can be
set and cleared directly by software.  If FPDATA is written while FPCLOCK
is set, FPCLOCK will be pulsed low for 300 - 400 ns (depending on MID_BUS
clock).  This is provided by logicly anding the inverse of the signal that
clocks the LED latch with the FPCLOCK.  See the ERS for more details on how
to use these signals.

At power up all the LED's are turned on, FPCLOCK is cleared and PROCFAULT
is high.  This is done by connecting the clear input of the latch to PON.

The PAL equation for the LED latch is given below:

.DS
/LED_LATCH = /Count2 + Count3 + Count1 * /Count0
           + READ + /ADD13 + /ADD14 + /ADD15

.DE

.H 4 "Real Time Clock (RTC) Control"

There are three signals provided by PAL2 to control the RTC (U9).  The Write signal
is shared with the Stable Store.  The Write and Chip select signals are
buffered by transistors for protection from glitches during power up and power
down.  The PAL equations for the RTC are shown below:
.DS

 RTC_CS = /ADD13 + /ADD14 + ADD15

.DE
.DS
 
 RTC_READ =  Count0 * /Count1 * /ADD15 * ADD13 * ADD14 * READ
          + Count1 * /Count3 * /ADD15 * ADD13 * ADD14 * READ
          + Count2 * /ADD15 * ADD13 * ADD14 * READ

.DE
.DS
 
/WRITE :=  /Count2 
         + /Count1 * Count3
         + /Count0 * Count3
         + READ
.DE

The RTC is the slowest PDH device.  It has a worse case access time of 850 ns.
This is the device that determined how many states the state machine had to
be.  The RTC also takes 350 ns to turn off and so caution must be taken not
to turn on some other device to soon at the beginning of an access.

The RTC chip is a mm58274.  This chip is set up and controlled by use of 16
4 bit registers.  These registers are accessed through bits 4-7 of the
MID_BUS data bus.  For details on these registers see the ERS and the mm58274
data sheet.

.H 5 "Status Register"

The other 4 data bits (0-3) of the RTC address space are used as a status
register.  The status register is latched to insure that the data does not
change during the time that it is required to be stable on MID_BUS.
These 4 bits are described below:
.DL
.LI
 bit 0 - Stable Store Ready - This bit indicates that the stable store is
ready for an access.  The stable store cannot be accessed for 10 ms after
a write.
.LI
 bit 1 - POW_FAIL_L - This is the MID_BUS signal that warns that power is
about to fail.
.LI
 bit 2 - CNT_ENABLE_L - this is connected to the key switch.  It is used
to enable remote diagnostics.
.LI
 bit 3 - SEC_FAIL_L -  This is a MID_BUS signal that is only valid during power
up.  It can be used to determine if memory survived the last power fail.
The memory board latches this information and so it should not be needed here.
.LE

.H 4 "Stable Store"

Stable store is implemented with an 8K x 8 EEPROM (U1).
The chip enable
signal is different for the read and write cycles because of the setup time
and hold time requirements for the EEPROM.  The PAL equations for the EEPROM
are shown below:

.DS

EEPROM_OE =  Count2 * /ADD14 * ADD13 * READ
       + Count0 * /Count1 * Count3 * /ADD14 * ADD13 * READ

.DE
.DS

EEPROM_CE =  Count2 * /Count3 * /READ * /ADD14 * ADD13
         + Count2 * /Count0 * /READ * /ADD14 * ADD13
         + Count2 * Count1 * /READ * /ADD14 * ADD13
         + /Count3 * Count1 * /Count0 * /READ * /ADD14 * ADD13
         + Count2 * Count3 * READ * /ADD14 * ADD13
         + Count2 * Count0 * READ * /ADD14 * ADD13
         + Count3 * /Count1 * Count0 * READ * /ADD14 * ADD13

.DE

.H 3 "Power Down Considerations"

There are three areas of concern for power down.  The first is the isolation
of the RTC battery from the rest of the system.  The second is insuring that
the RTC and stable store are not written as power goes up or down.  The TTL
circuits do not specify what they are doing when VCC is out of spec.  The
third concern is insuring that there are not buffer conflicts when power comes
up, before the clock is valid.

.H 4 "Battery Isolation"

The battery for the Firefox RTC is on the mother board.  This was done so
that the batteries would be accessible from the front of the machine.  The
batteries are changeable by the user and should be changed about every two
years.  The clock will load the batteries with 10 micro-amps and the batteries
have a capacity of about 150 milli-amp hours.  The batteries are only used
when the machine is turned off.

The isolation for the battery is provided by 4 diodes.  The diodes were chosen
for there low forward voltage, there low reverse current and because the same
diode is used on the CPU board.

CR2 is to keep current from charging the battery when the +5V supply is up.

CR4 is used along with R16 to provide a voltage that is one diode drop below
ground.  CR3 provides the battery isolation when the power is off.

The mm58274 requires that the ground be isolated as opposed to Vdd because
there is a leakage path between Vdd and the inputs to the mm58274.  This
leakage path will continue through the drivers connected to the inputs into
the rest of the system.  This leakage could be on the order of hundreds of
micro-amps.

When power goes down the Vdd pin of the RTC is forced to 0 volts.  The
battery then forces the ground to -2.5 volts (battery voltage - diode drop).
CR3 keeps any current from leaking into the rest of the system.  If CR3 was
connected directly to ground then the ground pin of the RTC would be at
about .5 volts.  If the inputs went below .2 volts then there would be
greater than -.3 volts between the input and the ground pin which violates
the spec.

CR5 is provided to protect the RTC chip in case -2 is disconnected and 5V
is applied.

.H 4 "Write Protection"

The transistors Q1-3 are used to provide write protection during power up
and power down.  PON will be low when the power supply is out of spec.
This will cause Q3 to be turned off, which will not allow current to go through
Q1 or Q2.  The pull up resistor (R5) will keep the RTC and  EEPROM write line
high.  The pull up resistor R19 will keep the real time clock from being chip
selected.

When PON goes high, Q3 turns on and so Q1 and Q2 act as inverters.  The
transistors were chosen because they are fast switching transistors and they
are low cost.  They need to be fast because they are switching logic.  Q3
does not have to be fast, but the same transistor was used.  Larger resistors
were used to drive Q3 because it can be slower and the load on PON
needed to be minimized.

The chip select on the RTC is protected by PON to keep the chip from
turning on its outputs when power comes up.  As power comes up the chip
will tend to be enabled because the inputs are low.  This causes a surge
of current in the battery because it happens before the voltage is high
enough to switch out the battery ( about 3V).  Q1 insures that the RTC
is not selected as power comes up.

.H 4 "Buffer Conflict"

The state machine is designed to make sure that all devices are turned off
when PON is low.  The problem is that the state machine needs a clock in
order to work.  In Firefox VCC is present for several hundred milliseconds
before the MID_BUS clock starts.

The MID_BUS buffers are disabled because U16A is cleared by PON.  The internal
data bus is disabled because the PAL's are disable by PON through U14B and
U38D.  (There are 3 enables and a resistor pull down to all the inputs for better board
testing.)  The pull up resistors are need to pull the enables high (They are
negative true.) when the PAL's are disabled.

The MID_BUS address/data buffers were also disabled because this was easy
to do.  This should not be required when production CA chips are available.
We had hard failures in Firefox protos because several boards turned on their
address/data buffers during power up.  The CA chip on the 11 board was one of these.

.H 1 "MID_BUS Timing"

This section discusses the MID_BUS timing for the CA chip and the PDH.  Both
were originally designed to work in a 16 slot 10 MHz MID_BUS.  Firefox has an 8.33 MHz
9 slot MID_BUS.  The timing was made to meet the worse case MID_BUS to allow for
easy future expansion.  Last minute changes in the CA chip timing required
the design to be modified in a way that only allows it to work at 8.33 MHz.

.H 2 "CA MID_BUS Timing"

There are several critical specs that had to be met for the CA MID_BUS timing.
Some of these are discussed here.
These are the MID_BUS hold time, the MID_BUS set up time, preventing a
driver conflict between the MID_BUS buffers and the CA chip, and an internal
timing requirement of the CA chip.
The design
approach was to specify the minimum and maximum delay for each device in these
critical timing paths and then solve for the minimum and maximum delay line
requirements.

MID_BUS is designed to use a delay line off of the clock to generate a timing
edge for data to be changed.  It requires that signals and data be valid 50 ns
before the falling edge of clock (for  10 MHz clock) and be held for 19 ns after the falling edge.
The set up time will involve maximum delays because data is changed on the
delayed falling edge of one clock and must be ready at least 50 ns before the
next clock.  Conversely hold time involves minimum delays.  The buffer conflict
spec involves minimum delays because the buffer is turned around with clock
and data is driven on delayed clock.

The table below shows the timing budgets for the MID_BUS data hold time.

.DS
.TS
center tab (/) box;
l|n.
MID_BUS hold /19.0
AS1032 (U10c) min/-1.0
CA (U7) min/-2.0
F245 (U33 etc.) min/-2.0
PC board/-1.0
_
Required delay line (U8) min/13.0
.TE
.DE

The table below shows the timing budgets for MID_BUS set up time.

.DS
.TS
center tab (/) box;
l|n.
MID_BUS card delay/50.0
AS1032 (U10c) max/-6.3
CA (U7) max/-12.0
F245 (U33 etc.) max/-7.0
PC board/-1.0
_
Delay line (U8) max/23.7
.TE
.DE

The delay path through the CA for turning the MID_BUS buffers around is not
the same as the delay path for driving the buffers.  The main difference is
the buffers are driven directly with the delayed clock, but the MID_BUS
buffers are turned around with CLK1.  The problem with this is that there is
as much as 4.5 ns of delay in CLK1 relative to the clock coming in.  This combined with
the fact that CA output drivers may differ by 3 ns make the total skew for the
CA chip 7.5 ns.  The table below shows the budgets and minimum required delay
line to prevent a driver conflict.  The PC board delays will be very close to
the same for clock and delayed clock.  Some tracking is assumed for the two
buffers driving the clocks (U10a and U10c) because they are in the same package.

.DS
.TS
center tab (/) box;
l|n.
CA (U7) max skew/-7.5
AS1032 (U10a) max/-6.3
AS1032 (U10c) min/+1.0
U10 tracking/+1.5
F243 (U35) max/-7.5
_
Required delay line (U8) min/18.8
.TE
.DE

There is a spec for the CA chip that limits the delay that is allowed.
The problem is that if the delay is too long, data going to
the output buffers will change before it is latched.  The equation for this
spec is:

     Max Delay = ((MID_BUS cycle time) * .2 ) - 0.8.

Firefox has a 120 ns clock and so the maximum delay is 23.2 ns.  The delay
line needs to be between 18.8 and 23.2 ns.  The delay line used is specified
to be 21 plus or minus 2 ns.

If the design needs to be changed to run at 10 MHz there are a couple of things
that can be done.  The driver U10c can be eliminated and the input to the delay
line moved to the output of U10d.  If this is done it
needs verified that the a delay line can be found that has a fast enough
transition time.  The maximum delay becomes 19.2 ns and the minimum delay
is 15.0 ns because skew through U10 is not in the delay path that is used
in preventing a buffer conflict.


.H 2 "PDH MID_BUS Timing"

The PDH is very slow (10 wait states) but there are still a couple of lines on
the MID_BUS that have critical timing.  These are READ_WAIT and WORD_SLAVE.
Both of these lines must not be driven until after the tri-state and they
must both be driven low within 50 ns after this time (for a 10 MHz MID_BUS).
The READ_WAIT signal must be pulled high at the end of the transaction and
must meet the MID_BUS spec for hold time and setup time.  The WORD_SLAVE
line does not have to be restored, only released.

The table below shows the maximum delay for the delay line to allow the PDH
to assert WORD_SLAVE and READ_WAIT low and meet the MID_BUS timing (10 MHz):

.DS
.TS
center tab (/) box;
l|n.
AS02 (U11c) low to high/-4.5
AS74 high to low (U16)/-9.0
AS244 enable (U14a)/-7.5
PC board delay/-1.5
MID_BUS set up/50.0
_
Delay line (U8) max/27.5
.TE
.DE

.DS
The table below shows the requirements for the delay line to meet the
MID_BUS setup time for READ_WAIT going high.

.TS
center tab (/) box;
l|n.
AS02 (U11c) low to high/-4.5
AS74 low to high (U16b)/-8.0
AS244 low to high (U14a)/-6.2
PC board delay/-1.5
MID_BUS set up/50.0
_
Delay line (U8) max/29.8
.TE
.DE

.DS
The table below shows the minimum delay required for the delay line to
meet the MID_BUS hold time on READ_WAIT.

.TS
center tab (/) box;
l|n.
AS02 (U11c) low to high min/-1.0
AS74 low to high min (U16b)/-3.5
AS244 low to high min (U14a)/-2.0
PC board delay/-1.0
MID_BUS hold/19.0
_
Delay line (U8) min/11.5
.TE


.DE

There is not a problem with buffer conflicts because the 74ALS245 (U22) is
disabled as opposed to being turned around.

The delay line requirements for the PDH are looser than the requirements of
the CA chip and so the same delay signal can be used.

.H 3 "Address Latch"

The circuit involving U11B, U11A, and U11D has two purposes.  The first is
to latch the address into U21 and U31 with a clock pulse of sufficient
duration.  The second is to provide the PAL (U15) with B_NPAV.

The B_NPAV signal cannot be driven directly into the clock of U21 and U31
because it would not provide the correct data setup time.  It cannot be
simply gated with CLOCK_L because the pulse width spec would not be met.
The circuit that is used will delay the latching signal until CLOCK_L goes
low and the clock will remain high until CLOCK_L goes high (even though
B_NPAV may go high just a few nanoseconds after CLOCK_L goes low).

The PAL (U15) is clocked with the delayed clock and so it needs B_NPAV held
longer than is provided.  As long as the delay line is not longer than about
40 ns the circuit will provide the correct hold time even with worse case
MID_BUS clock.  B_NPAV going low is not delayed because the PAL needs 20 ns
setup time.

.H 1 "Math Chips"

The three floating point math chips (U4, 5, and 6) are located on the 11 board.
They are interfaced to the CPU through the MIU which is located on the CPU board.

The math chips are bussed together and go directly to the connector with no
buffers.  There is very little support circuitry.  The clock lines are
terminated with 180 Ohms to +5 and 120 Ohms to ground.

There are four supplies required by the math chips.  There are at least partial
plains for each of these.  The bus is driven from VDL and so it is important
to have a good plain on VDL (2.85 V).  A voltage is also needed that is a diode
drop below the +5 supply.  The other two supplies used are +5 and -2.

The math chips are arranged so that the hotter chips are down wind from the
cooler chips.


.H 1 "PC Board Design"

The PC board is basicly a class 4 board.  Class 4 would allow traces to be
put on 16 mil pitch (8 mil trace and space), but they are put on 25 mil
pitch (8 mil trace and 17 mil space) to reduce cross talk.

Two traces go between the IC leads only on outside layers on the PGA's.  When
they go between the legs the pitch is reduced to 22 mils.  The pads are 52
mils the traces are 8 mils and the space between the traces is 14 mils.  This
leaves 9 mils for the space between the pad and the trace.  The solder mask
has a keep out of 60 mils.  This allows it to off by 4 mils and still not
overlap the pad and it can be off by 5 mils and not expose the trace.  The
trace being exposed is a bigger problem than the pad being overlapped.

The 100 and 160 pin connectors are not exactly on grid.  The blank drawing
calls for them top be 10 mils off grid.  This would require a special PC
bare board test fixture.  The spec states that the holes need to be within
7 mils of a 100 mil grid.  To solve this problem the holes were moved
three mils to be within spec.  The mounting holes were left in the same
place as they were called out on the blank board drawing.  The 3 mils is
will within the tolerances involved with the connector.

.H 1 "CA Chip"

The channel adapter is the interface from the MID_BUS to the CIO bus.
The interface is straight forward other than the MID_BUS timing which was
discussed earlier.  For the most part the CA chip is just connected to
the MID_BUS and the CIO bus through buffers.  This section discusses the
other circuits connected to the CA chip.

.H 2 "Clock Inputs"

There are 1500 Ohm pull up resistors connected to the clock inputs of the CA
chip.  These are added to insure a high level of 4.5 volts.  The low level spec
is .6 volts.  Smaller values of resistors were tried and the low level margin
became worse and the high level transition time was not improved.  The signal
must get high within 10 ns.  The 74AS1032 buffer (U10) was used because it has
the capability of pulling high and low very fast even with a large load.  The
CA chip may have as high as 25 pF of capacitance on the clock lines.

.H 2 "Slow0 and Slow1 Jumpers"

These jumpers (JP1 and JP2) are used to determine the speed of the CIO channel.
JP1 is installed to pull Slow0 high and JP2 is installed to pull Slow1 low.
This adjust the CIO timing for an internal CIO as opposed to one with a 1.5
meter cable.

.H 2 "Voltage Regulator"

The clock voltage for the CA chip, V2 (U7 pin J15) is specified to be at 2.85V.
On the first CA chips this voltage needed to be changed to 3.4 volts.  Because
of this a shunt regulator was added, just in case the final chip needed some
other voltage.  The voltage from the regulator is controlled by R24 and R25:

       V = 2.5 * (1 + R24/R25).

The voltage is dropped across R23 from 5 volts.  The supply only need to
provide a couple of milliamperes.  The regulator should not have to be used
and so the U39, R23, R24, and R25 are not loaded.  R22 is loaded instead.
This resistor along with C55 and C56 will also act as a filter for the
2.85 Volts supple.  If the regulator is loaded then R22 should not be loaded.

.H 2 "Pull Up Resistors"

The pull up resistors of RP1 that connect to the CA chip are required to keep
the control lines for the MID_BUS buffers in the high state.  The CA chip
puts these lines in the high impedance state to allow two CA chips to share
the same set of MID_BUS buffers.

.H 2 "RDATA lines"

The RDATA lines can be used to interface to a IODC ROM.  These are not used
in Firefox because our IODC is part of our PDC.  (For more information on
what IODC and PDC are see the Spectrum IO_ACD.)  The lines need to be pulled
low in order for the software to know that there is not a IODC ROM.  The
resistor is required because if someone did try to read the ROM anyway the
CA would drive these lines high.

.H 2 "Slot Address"

The slot address for the CA is always going to be slot one for the Firefox
system board.  These lines are hard-wired as opposed to getting there address
from the connector.  One of the slot lines on the  connector has been used
as the PDH chip select line (B_NPAV).  The slot lines are connected on the
circuit side of the board to allow them to be easily cut and jumpered, if
there was a need to change the slot address.  Because the CA is in slot one
it has the lowest MID_BUS priority other than the CPU.

.H 2 "DIP Connector"

The DIP connector gives access to the DIP port on the CA chip.  This is used
by the Prism tester to help evaluate problems with the chip.

.H 1 "Test Features"

There are a few buffers used to make 3065 testing easier.  These are used to
disable the chips that share common busses.

U14B is used to disable the devices on the internal data bus.  PON will cause
all the devices on this bus to be disabled by causing a one to be driven on
EN1, EN2, and EN3.  This will also prevent buffer conflicts as power comes up.
U14B is enabled through a resistor (R20) to allow the three enable signals
to be driven directly by the 3065 tester.

EN1 can be used to to test PAL U15 and the address buffers U21 and U31.
When it is pulled high it will allow these lines to be driven by the 3065
tester to test the chips that are connected to the address bus.

EN2 is used to test U12A.  When it is disabled (pulled high) U13 and U22
can be tested.

EN3 is used to test U13.  When it is disabled the devices on the internal data bus
can be tested.

When the PAL's are disabled the control enable lines for the internal devices
will be tri-stated.  For this reason pull up resistors are needed on the lines.
These are provided by RP1 pins 1-5.
The PAL U15 will tri-state the CE signals of U3 and U37 when PON is low.

.H 2 "Clock Calibration"

There are two clocks in Firefox that are calibrated by software.  The frequencys
of the clocks are measured at 3065 test and the information is put into
the EEPROM.  This data is read by the program that sets up the stable store
(the EEPROM) and messaged to come up with four numbers that are used by the
software to calibrate the clocks.

.H 3 "System Clock"

The system clock is the 25 MHz clock that drives the CPU.  This clock is
divided by two and used to increment the CR16 counter.  During normal
operation the operating system uses the CR16 counter to keep real time.
There are two ways that the information on the clock frequency has to be
given to the operating system.  The first is as a double precision floating
point number that represents the frequency in MHz that the CR16 counter
is incremented at (about 12.5 for Firefox).  The second is an integer
that represents the number of CR16 tics in 10 msec.  The PDC code will
read these numbers from stable store and pass them on to the operating
system.

The steps that are followed in measuring the frequency of the system clock
and massaging the data to get the numbers used by the operating system
are detailed below.  An example is used help make the steps easier to follow.

The frequency of the clock is measured by the 3065 tester.  It must be between
25,012,500 Hz and 24,987,500 Hz or it is a failure.  (For the example assume
that the frequency measured is 24,992,161 Hz.)

The lower limit is subtracted from this number (Example: this gives 4661 = 1235H).
This number is written into stable store.  The LSB is written to the fourth
location in the PDH area (address 1000H is the first location).  The MSB is written to the third
location.  Zeros are written to locations 1 and 2.  The software address for the first location is F004_1000H and the
second location is F004_0004H.  The third location is F004_0008H etc.
(Example: F004_0000H contains 35H and F004_0004H contains 12H)

The software that sets the serial number will read these two locations and
use the data to generate the numbers needed by the operating system.

For the example the CR16 frequency is:

  (24,987,500 + 4661) / 2,000,000 = 12.4960805

When converted to a double precision floating point number it becomes
4028_FDFE_4367_5DDD hex.  The format is that the first bit is the sign
(0).  The next 11 bits are the exponent plus 1023 (402 Hex).  The last 52 bits
are the fractional part.  The first one of the binary number is assumed and
so is not included.  This number is written to stable store starting at the
first location with the MSB first.

The next number that is needed is the number of tics in 10 msec.  For this
example the number is 0001_E821 hex.  This number is written to the stable
starting at the 29th (address 28) location (MSB first).

.H 3 "RTC Calibration"

The time is keep by an MM58274 (U9) when power is down.  The clock for
this part is derived from a 32.768 KHz crystal.  Before the time is set it
is first multiplied by a calibration constant.  When the time is read it
is divided by the calibration constant.  In order to speed up the code
that reads and sets the time the division is eliminated by providing both
the calibration constant and the inverse of the calibration constant in
the stable store.

The calibration constant is normalized to 8000_0000 hex.  A value of
8000_0000 hex means that the clock is exact.

The 3065 tester measures the frequency by putting the RTC chip in test mode
and measuring the frequency on pin 13 of U9.  The RTC is put in test mode
by writing 15 dec to the control register (register 0).  The interrupt
register (register 15) should also be written to with zero.

The clock must be within 16384 mHz of 32768 Hz or it is considered a failure.
The number of mHz that the clock frequency is greater than 32751616 mHz is
written into the EEPROM (stable store).  The MSB is in the 6th location
and the LSB is in the 7th location.  Note that these must be read before the
system clock frequency is written because they are in the same area.  Zeros
are written to locations 4 and 5.

Example: If the number returned is 6789 hex (26505 decimal) then the clock
frequency would be 32778121 mHz.  The first calibration constant (used for
reading the clock) would be:

    (32768000 / 32778121) * 2**31 = 2146820569 = 7FF5_E1DA hex

This number is stored in stable store starting in the 9th location with the MSB
first.

The inverse of the number is calculated to be used in writing the time:

    (32778121 / 32768000) * 2**31 = 2148146943 = 800A_1EFE hex

This number is stored in stable store starting in the 13th location with the
MSB first.

