.OP
.PF "''COMPANY CONFIDENTIAL   Firefox memory IRS  September 16, 1986''"
.H 1 "FIREFOX RAM IRS"

The purpose of this IRS is to document how the Firefox memory board implements
the SPECTRUM memory architecture.  It also documents the implementation
dependent features of the RAM board (features added to aid in diagnostics).

.H 2 "Spectrum Architecture Implementation"

The Firefox memory controller implements the architecture with out the use
of IODC.  The registers are defined to comply with the IO_ACD.  The memory
controller supports error logging and hard error recovery.

The following registers are implemented to comply with the IO_ACD.  Some
other registers are implemented for diagnostic purposes and will be
discussed later.

.DF
Register  Mode      Name               Description

   2       W        IO_DC_ADDRESS     I/O-dependent code address
   2       R        IO_DC_DATA        I/O-dependent code data
   8       B        IO_FLEX           Flex field of HPA
   9       W        IO_SPA_ADDRESS    Soft physical address
  12       RW       IO_COMMAND        Command register
  13       R        IO_STATUS         Status register
  14       RW       IO_CONTROL        Control register
  16       R        IO_ERR_ADDRESS    SPA offset of memory error
  17       R        IO_ERR_SYNDROME   Syndrome of memory error
  19                res
  20       W        IO_MAP_ADDRESS    Hard error recovery address
  21       W        IO_MAP_SYNDROME   Hard error recovery syndrome

In the mode column "R" indicates that the register can be read and "W"
indicates that it can be written.  A "B" indicates that it responds
to broadcast writes.  All the registers are mapped only to the
privileged page.  Register 18, IO_ERROR_MASTER, is not implemented and
reads zero.
.DE


.H 3 "I/O Dependent Code"

The I/O dependent code is accessed by writing an address to register 2 and
then reading the data back from register 2.  The data bytes are address
justified and all four bytes will be valid when any one is read.  The lower
two bits of the IO_DC_ADDRESS are ignored.  The contents of the 8 bytes of
IODC are listed in the table below.  Note that the Firefox memory controller
does not support bus EDC checking as indicated by the lowest order bit of
the hardware model number.  A software model number of 8 indicates that the
memory controller is an architected implementation and that it is capable
of power fail protection.

.DF
.TS
center tab (/) box;
c|c|c
n|c|l.
Hex Address/ Binary Data/ 
_
0 / 00000000/ Hardware model (note 1)
1 / 0010xxxx/ 
2 / 0011xxxx/ SPA (note 2)
3 / 01000001/ Type of model
4 / 00000000/ software model
5 / 00000000/ 
6 / 00001000/ 
7 / 00000000/ 
.TE
  note 1 - There will be 4 jumpers mapped into the hardware model
           rev number.

  note 2 - xxxx depends on the board size.  0101 for 2 Mbytes, 0110 for 4
           Mbytes, 0111 for 8 Mbytes and 1000 for 16 Mbytes.  For rev 1 MC-F
           bit 2 (third bit from left) is zero.

.DE


.H 3 "Flexible Address Register"

This is a write only register that determines the flex portion of the memory
controllers I/O address (bits 4-13).  At power up
the memory controller will not be visible.  A broadcast flex command is
required to enable the controller.  The memory controller will respond to
the following binary address-

.DF
.TS
center tab (/) box;
c|c|c|c|c|c.
 F /   flex   / fixed/pr/  reg    / 0 
.TE
     0  3 4         13 14    19  20  21       29 30 31

   flex - flex field
   fixed - MID_BUS slot address (00<SLOT(0..3))
   pr - privileged (0)
   reg - register address
.DE


.H 3 "Soft Physical Address"

The memory is enabled by writing to the SPA register with bit 26 set to 1.
Bits 0-11 determine the starting address of the memory for the 1 Mbyte
board (0-10 for the 2 Mbyte board and 0-9 for the 4 Mbyte board).  All
other bits are ignored.  Firefox memory boards will align to a boundary
corresponding to their size (i.e. a 4 Mbyte board will align to a 4 Mbyte
boundary).  There is no check by the memory controller to prevent the memory
board SPA from being set to the I/O space.  There will not be a problem
with configuring the system if for some reason the SPA is set to the
I/O space because the memory board will only respond to cache line accesses.
The enable bit of the SPA is cleared at power up, by command reset, and when
a transaction is end by an error condition.


.H 3 "Command Register"

Commands can be sent to the memory controller when the ry bit of the status
register is 1.  For all commands the ry bit will not change to zero because
the command will complete before the start of another MID_BUS cycle.
The memory controller will not respond to any broadcast writes to the command
register. The following commands are supported by Firefox:

.DF
  Value   Command         Description

    3     CMD_CLEAR       Resets all error conditions
    5     CMD_RESET       Initializes the memory controller
   32     CMD_MAP         Remaps the ECC circuitry
.DE

CMD_RETRY is not implemented because the Firefox memory controller does
not buffer transactions. Sending the command will have no effect.

.H 4 "Error Condition Clear"
The device error bit (de) is cleared by this command.  This command is also
used to clear the lost bit in the status register.

.H 4 "Reset"
The reset command will initialize the memory controller to the power up
condition.  The SPA address will be disabled.  Care must be taken not
to reset the memory card that the code is running out of.
controller registers.

.H 4 "Map ECC"
This command is used to map out hard errors.  The IO_MAP registers must
first be loaded before this command is written to the command registers. 


.H 3 "Status"

The IO_STATUS register is read only and has the following format:

.DF
.TS
center tab (/) box;
c|c|c|c|c|c|c|c|c.
     0      /res/lost/ dstat/ 0/de/me/ry/mstat
.TE
0          13     14    15 16    21 22     23   24   25 26   31

     res - Reserved (reads as a 1)
     lost - Indicates if memory survived a power fail
     dstat - Status of device error
     de - Device error
     me - Module error (always 0)
     ry - Ready to receive a command (always 1)
     mstat - Status of module error
.DE

.H 4 "Memory Lost"
The memory lost bit (lost) indicates that the memory did not survive the last power
fail.  This bit is cleared by a CMD_CLEAR command and set when a power loss causes the
memory to become invalid.  The memory controller will never automaticly clear
the lost bit (one indicates that the memory is lost).  MC-F will clear the lost
bit if power fail is high when PON goes high (small bug).


.H 4 "Device Error"

The de bit will be one if the memory controller detected a device error.  The de
bit is cleared by a command.  The memory array is treated as a device on
the memory controller.  Errors within the memory array are reported as device
errors.  When there is a device error the device status field (dstat) 
can contain one of the following decimal values:

.DF
   VALUE    NAME          DESCRIPTION
     24     DERR_SOFT     Recoverable soft error
     25     DERR_HARD     Unrecoverable error
     26     DERR_MAP      Recoverable soft error that can be mapped
.DE

The most recent error will be in dstat.
Firefox will never report DERR_SPA because there is never an unimplemented
area of SPA.  The SPA size is equal to the size of the memory.

.H 5 "Mappable Soft Errors"
When dstat contains DERR_MAP, the error has been corrected and there has not
been a hard error in the memory bank.  The Firefox memory controller is
capable of mapping out a single hard error.  If the run time diagnostics
determine that the error is a hard error, the error can be mapped out.

PROGRAMMING NOTE:

     An error can be determined to be hard because of a high
     frequency of errors or by writing the data back to the
     location and reading it again to see if it is still in
     error. (more on this later)

.H 5 "Soft Errors"
When dstat contains DERR_SOFT, the error has been corrected and there has
already been a hard error logged in the memory bank.  If the error is
determined to be hard, the board is no longer capable of correcting soft
errors and should be repaired.

.H 5 "Unrecoverable Errors"
When dstat contains DERR_HARD, there has already been a high priority
machine check.  The diagnostic software can use this to help isolate the
cause of the high priority machine check.


.H 4 "Module Error"

The module error bit is defined to be a 1 if the memory controller detects a
module error.  Firefox will never report a module error.  Data parity errors
are the only module type error that the Firefox memory controller
detects.  These will cause a high priority machine check but they will
not cause an error status bit to be set.


.H 3 "IO_CONTROL"

The IO_CONTROL register has the following definition:

.DF
.TS
center tab (/) box;
c|c|c|c.
 diag   /     0     /edc_enb/  res            
.TE
 0         2 3          23 22     23 24               31
 
           edc_enb - Enable error correction
           diag - Used for test and diagnostics
.DE

.H 4 "Enable Error Correction"
The edc_enb bit effects only reads.  When the edc_enb bit is cleared data will be read from
the memory without being corrected.  Multi bit errors will not be reported.
The syndrome bits are ignored.  At power up the ec bit will be cleared (error
correction disabled).


.H 3 "Error Logging"

Registers 16 and 17 are used for error logging.  When a soft error is
reported by the memory controller the address of the error will be in
IO_ERR_ADDRESS and the syndrome word for the error will be in
IO_ERR_SYNDROME.  These registers will contain the information on the
most resent error.


.H 3 "Hard Error Recovery"

Registers 20 and 21 are used for mapping out hard errors.  When a mappable
soft error has been determined to be a hard error, the address of the error
is written to IO_MAP_ADDRESS and the syndrome is written to IO_MAP_SYNDROME.
The format of the address and syndrome is the same as was read from
IO_ERR_ADDRESS and IO_ERR_SYNDROME.  After the map registers are loaded,
CMD_MAP (32 decimal) is sent to the command register.  The next access to
the memory board will have the mapping invoked.

When a single bit error is detected in a bank of memory that has already
been mapped the error will be reported as DERR_SOFT unless the syndrome
matches the syndrome in IO_MAP_SYNDROME.  It the syndromes match no error
will be reported (This is a known hard failure and so there is no need to
report it).

Mapping is cleared by setting the rs in the control register.  In rev 1
this does not work.  There is no way to clear the IO_MAP_ADDRESS.  This
makes this feature untestable.

.H 2 "Memory Accesses"

The SPA space of the Firefox memory board supports the following MID_BUS
transactions:

.DL
.LI
	READ16 - Read 16 bytes
.LI
        READ32 - Read 32 bytes
.LI
	WRITE16 - Write 16 bytes
.LI
	WRITE32 - Write 32 bytes
.LI
        CLEAR16 - Read and clear 16 bytes
.LE

A read transaction returns the bytes in the same order that they were written.
The 32 byte transactions ignore the lower 5 bits (27-31) of the address.
If memory is written to with a 32 byte write and then read with 16 byte reads,
address line 27 will determine what set of 16 bytes are returned.  If address
27 is zero the first 16 bytes written by the 32 byte write will be returned.
The CLEAR16  (load and clear) transaction is just like a READ16 except
that the first word (4 byte) will be set to zero after the transaction.
The other 3 word are not effected.


.H 2 "Initialization"

This section discusses how to initialize the Firefox memory board.
It is recommended that memory initialization
software be written so that it works with any memory board that complies
with the Spectrum architecture.

All references to registers in this section assume the registers on the
privileged page.  The firefox memory controller has no registers on the
non-privileged page.  Writes to the non-privileged page will have no effect
and reads will return undefined data.


.H 3 "Bus Initialization"

There is an architected method for determining which processor will initialize
which bus.  When a processor has determined that it is supposed to initialize
the modules on a bus it may start the initialization of the memory controllers.
The memory controllers IO registers are enabled by doing a broadcast write to
the IO_FLEX register.  This sets the FLEX portion of the HPA.


.H 3 "Finding the Memory Boards"

Modules can be found by writing to register 2 of all modules on the bus.  If
there is an address error then there is not a module at that location.  The
architecture allows up to 64 modules on a bus. All 64 locations should be
checked.  The fixed address on a bus is determined by bits 14-19.  Bits 18
and 19 will always be zero for Firefox memory modules because only one
memory controller per MID_BUS slot is supported.

When a module is found a 3 should be written to register 2 (IO_DC_ADDRESS).
On Firefox writing a 3 is the same as writing 0 because the lower two bits
of the IODC address are ignored.  When the register 2 is read (IO_DC_DATA)
bits 3-7 of the third byte (bits 27-31 of the word) will contain the module
type.  This will be 1 for memory modules.

Bit 25 of the word will be a one indicating that the IODC is being sent back
as words as opposed to bytes that are right justified.  Notice that this
information is in the third byte so that it can be obtained without knowing
if the module returns the IODC in word mode or byte mode.

On Firefox bit 24 will be a 0 indicating that there is not IODC code.  If
this bit came back as a 1 the initialization should be completed by use of
the IODC entry points because the module may not follow the architected
register definition. (See the IO_ACD for entry point descriptions)


.H 3 "Setting the SPA"

Once a memory module has been located the SPA can be set.  The SPA capable
byte is the third byte of IODC (bits 16-23 of the word).  Bit 16 should always
be a zero for memory modules.  Bits 19-23 contain size of the soft physical
address space.  For Firefox the size of the soft physical address space is
the same as the size of the implemented memory for the module.  The size
of the memory board can be determined by taking 2^shift (shift is the number
given bits 19-23).  Firefox memory boards can be 1, 2 or 4 Mbytes (shift
equal to 20, 21 or 22).

The IO_SPA_ADDRESS (register 9) is set to the lowest value of the SPA.
The SPA will align to boundaries corresponding to the size of the memory
board.  Only bits 0-11 are used as part of the SPA for the
1 Mbyte board (0-10 for 2 Mbyte board, 0-9 for the 4 Mbyte board).
Bit 26 enables the memory array when it is set to one.  All unused bits
are ignored.


.H 3 "Initializing the Array"

The Firefox memory controller does not test or initialize the memory array.
Some minimal test may be desirable to insure that code can execute out of
the memory.  All location must be written before they are read to prevent
the memory board from causing a high priority machine check.  At power up
error correction is disabled.  This is done to allow the memory to be
initialized without causing high priority machine checks.  After all the memory
has been written, bit 23 of IO_CONTROL (edc_enb) should be written as a one
to turn on error correction.


.H 2 "Error Logging and Recovery"

This section discusses how errors are logged and and what is done when
hard errors are detected.


.H 3 "Unrecoverable Errors"

There are two types of errors that will cause high priority machine checks.
One is when a data parity error is detected during a write and the other
is when a multiple bit error is detected during the read of the RAM array.
These errors indicate that there has been a loss of data and any data
stored in the module may be bad.  It is fairly likely that if one location
is bad that other data has also been lost.

It is up to the operating system to decide what to do with the RAM module
that caused the error.  As a minimum the error should be logged and the
RAM board should be initialized.  In some systems this may require re-booting.

These type of errors will cause the SPA to be disabled.


.H 3 "Logging Soft Errors"

The run time diagnostics need to periodicly check the IO_STATUS[de] bit to
see if there has been a soft error.  If the run time diagnostics detects
an error, the IO_STATUS[dstat] field should contain either a 24 or a 26
(decimal).  These are the only ones defined and if something else is
returned the memory controller has failed and so the error should be treated as
an unrecoverable error.

The following information should be logged when a soft error is detected.

.DL
.LI
The IO address of the memory module.
.LI
The address of the error. (IO_ERR_ADDRESS)
.LI
The syndrome of the error. (IO_ERR_SYNDROME)
.LE

The IO address is needed to identify the board.  The flex portion can be used
to identify the bus in a multi-bus system.  If the system is reconfigured
for some reason, the diagnostics need a method to keep the logged errors
associated to the propper boards.  The fixed portion of the address can be
used to identify the board.

When an error is detected the location with the error should be read and
written back to correct the bad bit.  This will keep the single soft error
from being reported more than once and will also lower the probability of
getting an unrecoverable double bit error.  If IO_ERR_ADDRESS is used to
re-write the data the lower bits must be masked to insure that the address
is on a cache line boundary.  Only the the SPA offset portion of IO_ERROR_ADDRESS
is valid and so it must be masked and the SPA address added.

The error bit is cleared by writing a CMD_CLEAR (decimal 3) to the IO_COMMAND
register (register 12).


.H 3 "Determining Hard Errors"

There are two ways in which a memory board could exhibit hard errors.
The first is a stuck bit which can be tested by writing data and reading it
back and checking to see if there is still an error.  A second type of hard
error is one where the memory chip cannot retain the data over some period
of time.  This type of hard error is detected by counting soft errors and
at some threshold considering it a hard error.  A soft error should only
be considered to be at the same location if they are from the same memory
module and they have the same value returned in IO_ERR_SYNDROME.  The
IO_ERR_ADDRESS register does not have to match.


.H 3 "Handling Errors"

The Spectrum architecture allows hard errors to be mapped out by the
memory controller.  There are two statuses that can be returned in
IO_STATUS[dstat].  If the status sent back is 24 and
the error is determined to be hard then the hard error cannot be mapped
out and the board should be removed or repaired as soon as possible because
there is no longer soft error protection.  If the status is 26 the error
can be mapped out.  The Firefox memory controller allows one memory chip
to be mapped out per 2 (8) Mbyte bank.
When a memory chip is mapped out, errors in
the bad chip will not be reported.  Single bit errors in the
rest of the memory bank will be reported as soft errors with an
IO_STATUS[dstat] of 24.

.H 4 "Mapping Out The Error"
Hard errors are mapped out by writing the address that was returned in
IO_ERR_ADDRESS to IO_MAP_ADDRESS and the syndrome that was returned in
IO_ERR_SYNDROME to IO_MAP SYNDROME, and then writing CMD_MAP (decimal 34)
to the command register.

.H 3 "Error Coverage"

The amount of error coverage for error correction and detection is not
specified in the architecture because different systems have different
reliability and availability requirements.  It is also possible for
different memory arrays to have error rates that are different by
orders of magnitude.  System designers will have to determine the coverage
needed for the systems that they are designing.

The Firefox memory board trades off the ability to guarantee that double
bit errors will be detected in order to be able to map out a single hard error.
Double bit errors will be very rare.  If the average memory location is
accessed at least every 100 hours, and the soft error rate is 10000 FIT
(This is much higher than the spec), the mean time between double bit errors
will be about 1,000,000 years.  The small decrease in detection coverage
is well worth the large increase in reliability for Firefox systems.


.H 2 "Test and Diagnostic Features"

This section discusses the test and diagnostic features of the Firefox
memory board.  These features are implementation dependent.  They are intended
to be used for doing QA on the memory controller and for implementation
dependent diagnostics.


.H 3 "Architected Registers"

There are many modes of access that the architecture leaves undefined.
The IO space will respond only to READ4 and WRITE4 (except
that the IO_FLEX register responds to BROAD4).  The memory
space (SPA) will respond only to READ16, READ32, WRITE16, WRITE32, and
CLEAR16.  Access to unimplemented registers will not cause address errors
but may cause side effects on writes (some registers may be multiply mapped).
Reads have no side effects.

.H 4 "IODC"
Only bit 29 is stored on writes to IO_DC_ADDRESS.

.H 4 "IO_FLEX"
Directed reads and writes to the IO_FLEX register are supported.  This is not
a requirement of the architecture but can be used by Firefox specific
diagnostics.  Only bits 4-13 are defined.

.H 4 "IO_SPA_ADDRESS"
Reads of the IO_SPA_ADDRESS are supported.  Only bits 0-11 and bit 26 are
defined.  The same data written to these bits will be returned.

.H 4 "IO_COMMAND"
Unimplemented commands are ignored with no side effects.  Reads of the command
register will return the last command sent.  Only bits 25-31 are defined.

.H 4 "IO_STATUS"
Only bits 15-31 are defined.  The IO_STATUS register can be written to.  When
read bits 24 and 22 will always be zero and bit 25 will always be 1.

.H 4 "IO_ERR_ADDRESS"
Writes to IO_ERR_ADDRESS are ignored with no side effects.  The address
points to the word that had the error.
The word is 8 bytes aligned.
There is no information on what type of access caused the error.

.H 4 "IO_ERR_SYNDROME"
Writes to IO_ERR_SYNDROME are ignored with no side effects.  Bits 24-31
contain the syndrome of the error.  Bit 10 indicates what bank caused the
error.  Bits 0-9 and 11-23 will always be 0.  Bank information is included
as part of the IO_ERROR_SYNDROME register because the operating system does
not know about the bank size of the memory.

.H 4 "IO_MAP_ADDRESS"
Only bit 10 is stored on writes to IO_MAP_ADDRESS.  Reads will return bit 10
and all other bits are undefined.

.H 4 "IO_MAP_SYNDROME"
Reads of IO_MAP_SYNDROME will return the current syndrome register pointed to
by bit 10 of IO_MAP_ADDRESS.  There are two syndrome registers, one for
each two Mbyte bank.  Only bits 24-31 are defined.


.H 3 "Module Dependent Registers"

Registers 32-1023 are undefined by the architecture and can be used for
module dependent functions.  Some of these registers and the most significant
bits of the IO_CONTROL
register are used by the Firefox memory controller for test features.

.H 4 "IO_CONTROL"
The IO_CONTROL register has the following definition:

.DF
.TS
center tab (/) box;
c|c|c|c|c|c.
fs/fe/rs/     0     /edc_enb/  res           
.TE
  0    1    2  3          22    23     24              31
 
           edc_enb - Enable error correction
           fs - Force syndrome
           fe - Force error
           rs - Read syndrome
.DE

.H 5 "Enable Error Correction"
The edc_enb bit effects only reads.  When the edc_enb bit is cleared data will be read from
the memory without being corrected.  Multi bit errors will not be reported.
The syndrome bits are ignored.  At power up the ec bit will be cleared (error
correction disabled).

.H 5 "Force Syndrome"
The fs bit effects only writes.  When the fs bit is set syndrome bits are
not generated and the contents of the FORCE_SYNDROME registers are written
into the syndrome bits of the array instead.

.H 5 "Force Error"
The fe bit effects only writes.  When the fe bit is one the data bits are
exclusive ored with the FORCE_ERROR registers.  The syndrome bits are generated
from the data before it is exclusive ored.

.H 5 "Read Syndrome"
The rs bit effects only reads.  When the rs bit is set the syndrome bits are
read out instead of the data bits.
The syndrome bits will be returned in the even words in
bits 24-31.  The rs bit will take precedence over the dc bit.  Setting the rs
bit will have the side effect of clearing hard error mapping.

.H 4 "FORCE_SYNDROME Registers"
There are eight 4 bit registers used with the fs bit to force syndromes into
the memory array.  These registers are right justified and are at addresses
32-35 on the privileged page.
The FORCE_SYNDROME registers are both readable and writable.

.H 4 "FORCE_ERROR Registers"
There are eight 32 bit registers used with fe to force errors into the memory
array.  These registers are are addresses 40-47.  Any bit set to a one will
cause the corresponding bit in a cache line transfer to be inverted in the
array.

.H 4 "Transaction Buffer"
To allow for single stepping it was necessary to buffer one MID_BUS
transaction (only to the SPA space).  This buffer is readable
through the IO address space.  The syndrome bits for the last
read are stored right justified in registers 48, 50, 52, and 54.
The data bits for the last MID_BUS transaction will be in registers
56-63 (read or write).  All 16 byte transfers will be in the first
4 registers (56-59).  There is no way to tell what type of transaction
the last transaction was or if it was a read or a write.

.TC

