🚀 go-pugleaf

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

    The fastest reasonably priced (and available in quantity) static RAM
    runs on the order of 20ns these days.  The fastest reasonably priced
    DRAM (and available in quantity) is 80ns.

    80ns DRAM = 80ns page mode / static column access, 160ns random access.

    So, for random accesses static RAM runs about 8 times faster.

    DRAM has about 4 times the storage capacity for equivalent chip areas,
    due to requiring four transistors per cell.  A DRAM requires only one
    transistor and a capacitor.

    STATIC RAM uses a completely static design and thus takes very little
    power... picowatts in standby mode (I am assuming CMOS here, of
    course), whereas DRAM requires refresh and takes a lot of power even
    when 'idle'.

    The REFRESH required for DRAM takes less than 1% of the available
    bandwidth ... you basically do not notice it.  It does complicate
    your board design, though if you use an existing DRAM controller it
    does not.

    STATIC RAM requires more PINS than DRAM due to the way addressing
    works.  DRAM chips are thus a lot smaller (fewer pins).

>	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 (?).

    Essentially.  I would not touch pseudo static RAM with a 10-foot poll
    personally.

>	Questions:
>		Why is DRAM slower than SRAM?  I can't see how having to refresh it
>		would cause any tremendous slowdown.

    Static RAM is basically combinational logic all the way to the memory
    storage cell.  You put an address on the bus and X ns later you can
    drive the WR line, or Y ns later the results of a read will have
    propogated back.  No clocking is required.

    DRAM requires a two phase address cycle.  For a full random access
    you drive the address lines with one half the address and then bring
    RAS low.  You then drive the address lines with the other half of
    the address and bring CAS low.  You hold CAS for X ns and if reading
    the data becomes available.  If writing data  you place on the data
    lines gets written.  You then release CAS.

    On the next cycle you have the option of driving a new CAS address
    while the dram maintains the original RAS address.	In this case
    you leave RAS low.	This is called a page mode access.  A similar
    access called 'static column mode' access allows you to clock
    successive columns without doing anything.	(I believe you can clock
    4 columns in without having to supply a new address).

    However, if the RAS address would be different you must bring RAS high
    (passive) for a full cycle (i.e. 80ns for 80ns DRAM) before you can
    begin the next cycle.

    DRAM requires refresh.  This does NOT slow down DRAM.  The reason
    DRAM requires refresh is because the CAPACITOR used for each memory
    storage cell leaks and must periodically be re-energized.

>		What is static column RAM?  I've been told it's the same as static
>		RAM, but that doesn't seem right (otherwise the 3000 would be
>	 a good bit faster and a good bit more expensive).  Is it the
>		equivalent of what Tannenbaum calls pseudo-static?

    As I mentioned above, static column mode DRAM is the same as page-mode
    DRAM (DRAM is either one or the other type but not both) except that
    it uses a different access method for 'fast' accesses when the RAS
    address does not need to be changed.

    Forget pseudo static RAM, it's a complicated mess that is supposed
    to give a static RAM board storage capabilities similar to DRAM boards
    but doesn't really (you just use DRAM).

>		What about VRAM?  Somehow specially designed for video memory, or
>		just some marketer's way to make the static RAM on a video card
>		sound superior?

    VIDEO DRAM is DRAM.  The difference is that VIDEO DRAM has two internal
    FIFO's.  An entire COLUMN of memory (i.e. if you have 9 address lines
    the DRAM addresses 9x2=18 or 256KBits with one data line, a single
    column represents 9 address lines or 512 bits of information).

    As I was saying, an entire COLUMN (even two columns depending on the
    design) is latched into this FIFO and may then be serially clocked
    out of the DRAM *COMPLETELY INDEPENDANT OF WHAT WE WOULD TERM NORMAL
    DRAM ACCESSES*.  Specifically, you apply a video clock to the DRAM
    serial clock and only have to do a single random access cycle to
    latch in the 'next' 512 bits (or whatever, depends on the DRAM).
    The FIFO's are usually double buffered ... you latch data into one
    FIFO while the video clock is shifting data out the other.

    The AMIGA uses normal DRAM for its video RAM and thus the video takes
    a lot of bandwidth.  This isn't quite fair because when you use video
    DRAM you are extremely limited in the resolutions you can support.

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

    ROMs used to be slow because CMOS used to be slow (well, I am just
    guessing).	EPROMs these days are on the average 100ns access time,
    up to 200ns is standard.  As of 5 years ago 300ns+ was pretty
    standard.  ROMs generally go faster... custom ROMs will run faster
    than static RAMs.  EEPROMS and EPROMS are limited by the way cells
    are made.

>		Why is there air?

    A very difficult question.	One might also ask "Why is there Vodka"

>		How many licks does it take to get to the center of a Tootsie Pop?

    Three!

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

    Comming to stores near you the moment motorola puts the stuff into
    mass production, assuming they fixed the problem with the chip getting
    so hot it has a cardiac arrest :-)

				    --

    Actually, if you are at all interested in digital design I would
    seriously look at HCMOS vs TTL and normal CMOS.  HCMOS is a few
    years old and goes basically as fast as TTL (ALS, and AS in the TTL
    arena can really be said to go faster by any significant amount).

    HCMOS is great because:

	* CMOS power dissipation, which is 3 orders of magnitude less
	  than TTL and an order of magnitude less than NMOS.  At high
	  frequencies HCMOS runs about an order of magnitude less power
	  than TTL.  HCMOS draw 0 power (well, a couple of picoamps
	  actually) when idle.	HCMOS power dissipation is directly
	  proportional to the frequency at which you run it.

	* Symetrical output drive capability.  An HCMOS output is
	  essentially connected to BAR (+5) or GND, and the drive
	  curves are symetrical.

	* CMOS DRIVE capability.  Since CMOS inputs do not draw any
	  current, a CMOS output can drive esssentially an infinite
	  number of CMOS inputs.  The limitation is in bus and input
	  capacitance... the more capacitance you have to drive the
	  slower the rise and fall times.  HCMOS can directly drive
	  TTL with a fanout of 10 or 20 (though TTL has problems driving
	  HCMOS sometimes because it gets nowhere near BAR or GND in its
	  outputs)

	* HCMOS has CMOS noise immunity, which means glitches on inputs
	  can go nearly 50% of the power supply down from BAR or up from
	  GND without effecting the output.

	Basically, we (where I work) use nothing but HCMOS these days.
	The only thing you have to be careful about is to put a small
	bypass capacitor across power and ground near each [H]CMOS chip...
	more than one would normally put on a board populated with TTL.
	This is because HCMOS outputs temporarily short BAR to GND
	when changing state (< 1ns) and while this generally does not
	effect other HCMOS chips due to their noise immunity, it does
	effect other types of chips and allowing glitches to propagate
	on your power bus leads to very noisy designs.


>	Thanks for any info you can provide.

	I aims to please!

>--
>  Gibberish		 Soon to be Amiga 3000 owner/fanatic! (I hope)
>  is spoken		 Contact don@brahms.udel.edu for more information.
>    here.		 DISCLAIMER:  It's all YOUR fault.

--

				    -Matt

    Matthew Dillon	    dillon@Overload.Berkeley.CA.US
    891 Regal Rd.	    uunet.uu.net!overload!dillon
    Berkeley, Ca. 94708
    USA