torch@attctc.Dallas.TX.US (Jay Finger) (09/23/89)
I don't have any info from Apple which will allow me to say all this with 100%
certainty, but the comments I've seen here to the effect that parity checking
will slow memory accesses seem rather silly. What follows is my explanation
of why I think that the parity feature probably does not slow down the memory
subsystem, and even better yet, that it's all a moot point anyhow. It tends
to get a bit technical, and I'm not going to bother explaing any terms here.
Before I go rambling on here I guess (for fairness' sake) I should state that
allthough I do support myself to some degree by designing digital circuits
(I mostly do software) I have little experience with dynamic RAM system design.
If I say something wrong I'd appreciate being set straight.
Let's assume for a moment that Apple used a discrete off-the-shelf chip to
do the parity generation and checking. A 74FCT833B could combine the data
bus buffering (which has to be done whether or not you're using parity) and
the parity logic on one chip. I picked that chip only because it was in a
databook that I had sitting on my desk, not because it's the fastest
available (I'd be surprised if it were). When writing to memory the data
would get through the chip only 4ns before the parity bit. When reading from
memory an error signal would be available 1ns after the data. Allthough
these are worst case conditions (typical response times would be better) any
halfway decent engineer uses the worst case values. Even though the 4ns
needs to be considered in the timing chain there are other things going on
at the same time. For starters, address decoders need to figure out which
bank of ram you're accessing, and there are certain minimum pulse widths
for the strobe signals that are sent to the RAMs. As a result there are many
places where that 4ns could be hidden.
Now the assumption that Apple would use an off-the-shelf general-purpose chip
for this purpose is ludicrous when you consider how many large ASICs they
designed for that board. The internal delays in these chips are much shorter
that the delays encountered when using discrete logic chips. Also, since you
have so many gates available to you you can handle much of the memory logic in
one chip in whatever way best suits your situation. What this all adds up to
is that the designer now has tens (if not hundreds) of places in which to
hide the time that it takes to do the parity generation/checking. By hiding
I'm not trying to imply that somebody's coming up with a kludge, it's merely a
matter of doing separate things in parallel.
Now that we have a way to lose the extra time it takes to handly the parity
bit, I'm happy to tell you that it probably doesn't matter anyhow. The
chances are quite good that the IIci systems without parity support actually
do all the work all the time anyhow: it's probably all a matter of disabling
the signal that generates an interrupt when an error is found. Writing a
parity bit to a RAM chip that doesn't exist (the empty 9th space on your 8-bit
SIMM) certainly doesn't hurt anything. When read from 8-bit SIMMS you'll get
a parity error 50% of the time since that 9th data bit will be more or less
random, but since we've disabled the interrupt, who cares? To not implement
the no-parity feature in this way could end up leading to two separate timing
circuits.
I felt that this was all pretty important because I'd hate for anyone to
pass up parity merely because of a false belief that your computer will
suffer a speed penalty. While it's true that you increase the potential
of a memory error by 9/8, you will have greatly increased the chances of
your finding out about it when it does happen. I personally would like to
know if a piece of date in a spreadsheet (or whatever I'm working on) changes
randomly.
I hope I haven't spread any falsehoods here, but if I have I would be more
than happy to be corrected/educated.
------------------------------------------------------------------------------
Jay Finger (214) 298-5915 |If all you do is treat symptoms, you'll
UUCP: {ames, mit-eddie}!attctc!torch|continue to see more symptoms forever.
DOMAIN: ames!torch@attctc.dallas.tx.us| -- Tom van Vleck
==============================================================================torch@attctc.Dallas.TX.US (Jay Finger) (09/23/89)
My comment that parity increased the likelihood of a memory error by 9/8
was wrong (a small case of brain-lock on my part). It's really only
12.5%.
------------------------------------------------------------------------------
Jay Finger (214) 298-5915 |If all you do is treat symptoms, you'll
UUCP: {ames, mit-eddie}!attctc!torch|continue to see more symptoms forever.
DOMAIN: ames!torch@attctc.dallas.tx.us| -- Tom van Vleck
==============================================================================roy@phri.UUCP (Roy Smith) (09/24/89)
In <9451@attctc.Dallas.TX.US> torch@attctc.Dallas.TX.US (Jay Finger) writes: > Writing a parity bit to a RAM chip that doesn't exist (the empty 9th space > on your 8-bit SIMM) certainly doesn't hurt anything. As long as the missing chip is the same speed as all the other chips in the SIMM. Don't go mixing 80ns chips with 70ns spaces or you'll get memory heartburn! :-) -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
torch@attctc.Dallas.TX.US (Jay Finger) (09/25/89)
In article <4009@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > In <9451@attctc.Dallas.TX.US> torch@attctc.Dallas.TX.US (Jay Finger) writes: > > Writing a parity bit to a RAM chip that doesn't exist (the empty 9th space > > on your 8-bit SIMM) certainly doesn't hurt anything. > > As long as the missing chip is the same speed as all the other chips > in the SIMM. Don't go mixing 80ns chips with 70ns spaces or you'll get > memory heartburn! :-) > -- > Roy Smith, Public Health Research Institute If that 9th chip is missing how can it have a speed. The idea here is that the CAS, RAS, WR, etc signals are just going off into never-never land. The parity bit will never get written (since there's nothing to write it into). When you read it back there's no chip to drive the data line, so it either comes back random or it'll float low or high all the time. It doesn't matter because if you're using 8-bit SIMMS you've parity disabled so the error is never caught. ------------------------------------------------------------------------------ Jay Finger (214) 298-5915 |If all you do is treat symptoms, you'll UUCP: {ames, mit-eddie}!attctc!torch|continue to see more symptoms forever. DOMAIN: ames!torch@attctc.dallas.tx.us| -- Tom van Vleck ==============================================================================
roy@phri.UUCP (Roy Smith) (09/26/89)
In article <4009@phri.UUCP>, I wrote:
-> Don't go mixing 80ns chips with 70ns spaces or you'll get memory
-> heartburn! :-)
In <9460@attctc.Dallas.TX.US> torch@attctc.Dallas.TX.US (Jay Finger) replies:
-> If that 9th chip is missing how can it have a speed.
Uh, Jay. Didn't you notice the little smiley face I put in?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"