Xref: utzoo comp.sys.next:18465 comp.arch:23079
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!uunet!sobeco!jlee
From: jlee@sobeco.com (j.lee)
Newsgroups: comp.sys.next,comp.arch
Subject: Re: parity is for farmers?
Message-ID: <1991Jun4.143404.17535@sobeco.com>
Date: 4 Jun 91 14:34:04 GMT
References: <1991May21.232331.24888@cs.umn.edu> <1991May22.234515.24685@milton.u.washington.edu> <1991May23.203950.20953@zoo.toronto.edu> <1991May25.062358.13694@m.cs.uiuc.edu>
Sender: usenet@sobeco.com
Organization: Groupe Sobeco, Montreal, Canada
Lines: 26
Nntp-Posting-Host: sobeco.sobeco.com

In <1991May25.062358.13694@m.cs.uiuc.edu> gillies@m.cs.uiuc.edu (Don Gillies) writes:

>Actually, wouldn't it be pretty easy to provide "optional parity" on
>non bank-switched memory?  At boot time, sense whether there are
>parity simms installed, and if so, enable the parity checking
>hardware, which uses a single simm to parity-check all the other simms
>in the system.  One byte from the parity simm is used to check 8 words
>of main memory.

Sorry, parity is one game where either you're in or you're out.
The complexity is in the parity generation and detection circuitry;
even parity checking is not instantaneous and careful design is
needed to avoid slowing down accesses to memory.  The expense of
the extra bit-per-byte is minimal (or should be in bulk if enough
people used parity).

For speed, you need to access the parity bits in parallel with the
RAM bits that they guard; for simplicity, you want them on the same
bus; for byte-addressible memory, you want to have a separate parity
bit for each byte to simplify the update problem.  You *don't* want
to require a Read-Modify-Write cycle to update the parity bits.
That means using 9-bit SIMMS (or similar schemes).  You could
arrange to disable the parity checking (or at least the trap), but
if you have gone to the trouble to support it, why turn it off?

Jeff Lee -- jlee@sobeco.com || jonah@cs.toronto.edu