Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!qucdn!leek
From: LEEK@QUCDN.QueensU.CA
Newsgroups: comp.sys.amiga.tech
Subject: Re: Parity Checking / ECC RAM on the A3000
Message-ID: <90160.020651LEEK@QUCDN.BITNET>
Date: 9 Jun 90 06:06:51 GMT
References: <756@bilver.UUCP> <1990May27.101258.24470@zorch.SF-Bay.ORG>
 <321@tlvx.UUCP> <1990May29.204550.27961@zorch.SF-Bay.ORG> <9 <3649@tymix.UUCP>
 <90159.133447LEEK@QUCDN.BITNET>
Organization: Queen's University at Kingston
Lines: 60

Some asked me a question about why I could use ECC for the whole 32-bit word
and not a parity bit per 32-bit word...  I guess I should bring my data books
to work next time so that when I goof off to do comp.sys.amiga, I would have
all the reference I need.  The following is my reply to the EMAIL
-----------------------------------------------------------------------------

Subject: Parity bit business

The 680x0 family can do either 8-bit, 16-bit (and the 020 and above can do 32
bit access)

MSB                          LSB

33222222 22221111 111111
10987654 32109876 54321098 76543210
|<---->| |<---->| |<---->| |<---->|   Byte access
|<------------->| |<------------->|   16-bit words
|<------------------------------->|   32-bit long words

The thing is the CPU can address each of the 4 byte individually.  One would
 ot be able to use a single parity bit for the whole group.  The parity for
the MSB access would not be the same as the one for the LSB.  The only way to
use a single parity bit is to some how access the whole 32-bit chunk at a time.
This is messy.    One would need a parity bit for each byte for performance
reasons  (see below)  The PC/AT implement parity bit this way.

This is how they do the ECC for 32-bit memory.  (I though they have a easier
way. :( )  The memory write cycle is changed into a Read-Modify-Write cycle.
The read cycle let the ECC chip reads in the 39-bit word (32-bit for data,
and 7 bit for ECC parity bits).  The ECC now look at the byte/word to be
written and compute the 7 bit parity for the whole 32-bit word.  The
data and ECC parity bits are passed to the memory in the write cycle.
Hmmm..  This is not a pretty sight as a Read-Modify-Write cycle imposes
quite a bit of speed penality.  It is quite a bit longer than just a write
cycle.  The thing is for 32-bit ECC, there are special ECC chips that works
with the DRAM controller and are designed to provide necessary timings and
other stuff.  There are no parity bit chips at VLSI level for parity bits.
If one only want parity bit, one have to sit down and build from descrete
components (MSI or PALs) and it is ususally much easier to have 1 parity
bit per byte rather than 1 parity bit for the 32-bit word.

Sorry I guess I should have made the article at home rather than at work.
The fact still remains the same - it is more worth while to use ECC than
parity bit(s) due to availability of components.  There are VLSI designed
for 32-bit buses vs TTL MSI/PAL decrete chips design for parity bit(s) only
designs.(By the time one get down to using only 1 parity bit/32-bit word,
the amount of MSI/PALs would be as complicated if the thing was designed
with 1 parity/byte.  The added penality for Write going to a R-M-W cycle
throw away the saving in number of RAM chips.)   Due to performance/designs,
one usually have 1 parity bit per byte. (eg. PC/AT)  I guess the memory
controller market people do not believe in parity bit - either it is ECC or
nothing at all.  (same here for me)

Hope this clear up the mess.

----------------------------------------------------------------------------
K. C.

I guess I should drink coffee when I work.  Hmmm that doesn't make sense as
I would be awake during working hours...   Zzzzz away.