🚀 go-pugleaf

252u3130@fergvax.unl.edu (Phil Dietz) writes:

>In article <15571@brahms.udel.edu> don@brahms.udel.edu (Donald R Lloyd) writes:
>>
>>	I've been looking for information on the various type of RAM for a week
>>or so, (more out of curiosity than out of any real need to know), and so
>>far have found only what I already knew:
>>
>>	DRAM is relatively slow & has to be periodically refreshed
>>	static RAM is fast & needs no refresh
>>

>I'm not too sure that TRUE statis rams are faster.  In my book Computer
>Organization (Hamacher Vranesic Zaky ver 3 pg 322) it quotes
> 
>"MOS transistors are higher-impedence devices; they yield circuits that
>have lower power dissipation.  Their disadvantage is their slower speed
>of operation."

The vast majority of static RAMs available today are CMOS devices, so it's
not the device technology that is responsible for the speed difference
here.  The primary reason DRAMs are slower than SRAMs is found in the design
of the memory cell.  DRAMs implement "memory" by storing charge on a
capacitor, whereas SRAM uses an active circuit (transistors with feedback -
yes I'm simplifying).  When the gating transistor of a DRAM cell is enabled
(i.e. when that bit is read), only the charge stored in the capacitor is
available to change to state of the bit line.  Since the capacitance of the
cell is very small compared to the capacitance of the bit line, sense
amplifiers must be used to detect the small change in voltage on the bit
line.  The memory cell in SRAMs consists of an active circuit of 4
transistors (for CMOS) that can drive the bit line much more quickly than
the minimally sized capacitor can.  The active circuit (i.e. it's connected
to the power supply) is responsible for both the faster response time and
the freedom from refresh.  Also, DRAM bit lines must be "pre-charged" to
a reference value before the memory cell is read so that the sense amps will
properly detect the voltage change when the charge of the memory capacitor
is added to the bit line charge.  This is why 'access time' is only half the
story with DRAMs.  Well, this is getting a little long, so I'll stop here.

>>	I also found brief mention of "pseudo-static RAM" (in Tannenbaum's
>>"Stuctured Computer Organization", 3rd edition), which is basically
>>dynamic RAM with some refresh circuitry on-chip (?).
>>	Questions:
>>		Why is DRAM slower than SRAM?  I can't see how having to refresh it
>>		would cause any tremendous slowdown.
> 
>Well, everything takes time.  It may only take nanoseconds to refresh
>the RAM, but it is ALWAYS refreshing the RAM.  The time slowly but
>surely adds.....

But in a good design, refresh amounts to very little time.  Dave Haynie
recently answered somebody's question asking how often refresh occured
(although in that case it was a question related to the power consumption of
an expansion board with excessive refresh).  Since he will certainly read
this :-), maybe he will post those minimal refresh rate numbers again.  I
would have to look them up.

>>		While I'm at it, why are ROMs inherently so slow?

They aren't.  A chip designer makes tradeoffs between density and speed.  If
you are targetting maximum density, then you will certainly be sacrificing
speed.  You can buy ROMs that are as fast as very fast SRAM, but don't expect
to find either of these in 1 Mbit sizes.  (yeah I know you can buy 1 Mbit
SRAM, but I said *very fast*!)  

Not that long ago I commented on the cost or ROM vs. RAM, and I questioned
the wisdon of ever instaling Kickstart on ROM in the A3000.  Although Dave
H. said that ROM was less expensive than RAM, I still question this.  The
only way ROM is going to be less expensive than RAM is if you have huge
volumes!  I know I won't get a direct answer from Commodore, but can the
volume numbers for the A3000 possibly justify this?  Like I said, I still
don't believe this.

>>		Where's my free 68040 upgrade for the 3000 I just ordered?

Probably lost with my free 68040 upgrade.

Marcel A. LeBlanc  --  Electrical Eng. Computer Group, Univ. of Toronto
-----------------------------------------------------------------------
leblanc@eecg.toronto.edu		else: uunet!utcsri!eecg!leblanc