Searching \ for '[OT] RAS/CAS on DRAM?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=dram
Search entire site for: 'RAS/CAS on DRAM?'.

Exact match. Not showing close matches.
PICList Thread
'[OT] RAS/CAS on DRAM?'
1998\11\09@052834 by Radboud Verberne

flavicon
face
Hi,

SInce I do not know excatly how DRAM is used i was looking for a site where
i can find find the basics of accessind DRAM with a microprocessor.

Because DRAm is very cheap nowadays it looked to like a cheap way of storing
data. RAM is far more expensive. In my project I need a buffer
for a data steam, which can be upto 200k/s. So I was thinking about a normal
72pin SIMM of 4/8Mb. (Yes, an overload of the buffer will not happen often!
:-)

Greetz,
       Radboud Verberne

ICQ     : 918640 (I Seek You)
HAM  : PE1RUH

1998\11\09@134934 by John Payson

flavicon
face
|SInce I do not know excatly how DRAM is used i was looking for a site where
|i can find find the basics of accessind DRAM with a microprocessor.

|Because DRAm is very cheap nowadays it looked to like a cheap way of storing
|data. RAM is far more expensive. In my project I need a buffer
|for a data steam, which can be upto 200k/s. So I was thinking about a normal
|72pin SIMM of 4/8Mb. (Yes, an overload of the buffer will not happen often!

I think you'd be better off with a 30-pin SIM, since those are
8 or 9 bits wide rather than 32-36.  But otherwise...

A typical DRAM chip has three control wires: /RAS, /CAS, and R/W.
When you're not doing anything with the chip, these wires should
all be high (de-asserted).

The normal mode of access on the chip is to select a row (causing
all the data in that row to be copied to a special buffer within
the DRAM chip), perform any desired writes/reads to/from that row,
and then deselect it (causing the buffer to be written back to that
row).  Note that the data within the memory array will "fade" quite
quickly, but selecting a row and then deselecting it will cause all
of the data on that row to be refreshed.

Selecting a particular row is simply a matter of giving the chip the
desired address and asserting /RAS.  While /RAS is low, bits within
the row may be read by supplying the address and asserting /CAS, or
written by supplying the address and data and asserting R/W followed
by /CAS.  Once all desired accesses on the row have been performed,
releasing /RAS will cause the row buffer to be written to the array.

Note that you must wait a certain length of time after asserting /RAS
before you can read or write data to/from the chip, and you must also
wait a certain length of time after releasing /RAS before you can ass-
ert it again.  In addition, most chips have a maximum allowable /RAS
time (i.e. the amount of time a particular row can be selected contin-
uously).  Since most access speeds are under 100ns, you probably won't
have to worry about any of these except perhaps the maximum /RAS time.

To keep the memory refreshed, it's necessary to select each row at least
once a milisecond or so.  Most DRAMs have a couple of useful features to
help you out here:

[1] Even on megabit-plus parts, there are usually several sets of 256 or
   512 rows; thus, rather than having to perform e.g. 2048 reads to re-
   fresh a 4Mbit part, it will suffice to perform 512 (the 9 LSB's of
   the row address are what matter here).

[2] If /CAS is asserted when /RAS is asserted, the device will ignore the
   supplied address and instead use an internal counter which it will then
   increment by one.  Provided you meet the access/precharge timing require-
   ments (probably hard not to with a PIC) you may refresh the entire array
   by asserting /CAS and then hitting /RAS 512 times; if preferred, you may
   divide this labor into smaller steps (e.g. 16,000 times a second, assert
   /CAS and hit /RAS 32 times).

You'll want to look at some DRAM data sheets to ensure compliance with any wierd
timing requirements the chips may impose, but they shouldn't be too hard to use
if you can manage the timing restrictions and refresh.  BTW, a 30-pin SIMM is
nothing more than 8 or 9 DRAM chips with their address and control lines all tie
d
together.  You may opt to use one of these, or you may opt to simply use some
discrete DRAM chips.  Neither way should be too diffucult (though the entire con
-
tents of the RAM array will vanish if the CPU stops refreshing it--could be a pa
in
if you're using an emulator).

1998\11\09@185032 by James Cameron

flavicon
face
John Payson wrote:
> [an excellent description of interfacing to dynamic RAM]

So is it okay to only refresh the portions of RAM that I want
refreshed?  The designed amnesia is not contagious?

I imagine that the single-bit chips like 4164 could be used as a sort of
serial RAM.  I've got a few of them lying around.  Might be fun.

--
James Cameron                                      (spam_OUTcameronTakeThisOuTspamstl.dec.com)

OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.

"Specialisation is for insects." -- Robert Heinlein.

1998\11\10@104642 by Peter L. Peres

picon face
On Tue, 10 Nov 1998, James Cameron wrote:

> So is it okay to only refresh the portions of RAM that I want
> refreshed?  The designed amnesia is not contagious?

Er, no. There is no guarantee that you won't have some side effects. imho.

> I imagine that the single-bit chips like 4164 could be used as a sort of
> serial RAM.  I've got a few of them lying around.  Might be fun.

About 10 years ago the 1st tapeless announcement answering machines used
41256 and a Toshiba chip to do just that ;) Anyway, anything short of a
FPGA will require lots of chips to implement your functionality.

Peter

1998\11\10@125945 by William Chops Westfield

face picon face
   > I imagine that the single-bit chips like 4164 could be used as a sort of
   > serial RAM.  I've got a few of them lying around.  Might be fun.

   About 10 years ago the 1st tapeless announcement answering machines used
   41256 and a Toshiba chip to do just that ;) Anyway, anything short of a
   FPGA will require lots of chips to implement your functionality.

Nonsense.  Well within the capabilities of a PIC, for instance.  It's fully
possible to drive a DRAM entirely in software, even on a moderately slow
microcontroller...

BillW

1998\11\11@161911 by John Payson

flavicon
face
> So is it okay to only refresh the portions of RAM that I want
> refreshed?  The designed amnesia is not contagious?

|Er, no. There is no guarantee that you won't have some side effects. imho.

There's no plausible mechanism for side-effects.  A row of
DRAM memory is nothing more than a bunch of capacitors that
can be connected to a large bus (all the switches on a row
are controlled by the same gating signal).  If the capacitors
are never connected to the bus, nothing is going to care how
charged or discharged they are.

On the other hand, I think /CAS-before-/RAS refresh is probably
the best way to handle the refresh with minimum effort(*), and
there is no way to restrict the chip's internal counter to only
count in a limitted range.

(*) Using a 20MHz PIC, refreshing 16 rows of memory would only take
   about 8us [using an unrolled loop].  Using /RAS-only refresh
   and having the PIC output real addresses would take at least
   half again as long.  Unless the refreshes already occur as an
   implicit consequence of whatever else you're doing, I don't
   think you'd save enough to be useful.

> I imagine that the single-bit chips like 4164 could be used as a sort of
> serial RAM.  I've got a few of them lying around.  Might be fun.

|About 10 years ago the 1st tapeless announcement answering machines used
|41256 and a Toshiba chip to do just that ;) Anyway, anything short of a
|FPGA will require lots of chips to implement your functionality.

Naw.  That's what micros are for.  If you need to be able to get
data into and out of the chip at CPU-bus speeds (i.e. millions of
accesses per second), a hardware-based DRAM controller is needed,
but if data rates in the tens or hundreds of thousands of accesses
per second are okay, a micro should be able to handle that in add-
ition to various other duties.


Attachment converted: wonderland:WINMAIL.DAT (????/----) (0001D12D)

1998\11\11@161955 by Peter L. Peres

picon face
On Tue, 10 Nov 1998, William Chops Westfield wrote:

>     > I imagine that the single-bit chips like 4164 could be used as a sort of
>     > serial RAM.  I've got a few of them lying around.  Might be fun.
>
>     About 10 years ago the 1st tapeless announcement answering machines used
>     41256 and a Toshiba chip to do just that ;) Anyway, anything short of a
>     FPGA will require lots of chips to implement your functionality.
>
> Nonsense.  Well within the capabilities of a PIC, for instance.  It's fully
> possible to drive a DRAM entirely in software, even on a moderately slow
> microcontroller...

Ok, so you want to spend money for a PIC16C64 or higher for the IO pin
count, and for a DRAM to tie most of the pins up (unless you can multiplex
the pins, but even then it is expensive). Ok.

The 16C64JW was more expensive than a Lattice 1016 or 2032 FPGA the last
time I checked, and the FPGA puts its IO pins to much better use than a
PIC, for the same money and clock speed.

I did not say that it cannot be done with a micro, I said a FPGA is
better in this case.

And yes, it can be done with a PIC, for example the much quoted 16C64.

Peter

1998\11\11@194109 by John Payson

flavicon
face
>     About 10 years ago the 1st tapeless announcement answering machines used
>     41256 and a Toshiba chip to do just that ;) Anyway, anything short of a
>     FPGA will require lots of chips to implement your functionality.
>
> Nonsense.  Well within the capabilities of a PIC, for instance.  It's fully
> possible to drive a DRAM entirely in software, even on a moderately slow
> microcontroller...

|Ok, so you want to spend money for a PIC16C64 or higher for the IO pin
|count, and for a DRAM to tie most of the pins up (unless you can multiplex
|the pins, but even then it is expensive). Ok.

|The 16C64JW was more expensive than a Lattice 1016 or 2032 FPGA the last
|time I checked, and the FPGA puts its IO pins to much better use than a
|PIC, for the same money and clock speed.

If you want to use a 1Mx8 SIMM with a PIC, you'll need a
total of 21 PIC port pins dedicated to that task.  Although
that is a rather hefty chunk of port pins, that would still
leave 11 port pins on a 40-pin device which could be used
for other purposes.

If more I/O is needed that what would remain after the DRAM
was interfaced, then use of extra hardware or a PLD to aid in
the DRAM interfacing might be warranted.  As for pricing, my
impression of the PLD/FPGA situation is that going much beyond
a 22V10 requires expensive development tools.  Is this no longer
true?

In any event, the key point to remember here is that different
applications demand different solutions.  The cost difference
between, e.g., a 16C62 and a 16C64 isn't all that huge and if
using the latter means there's only one chip that needs to be
"burned" instead of two, so much the better.

1998\11\13@041519 by Peter L. Peres

picon face
On Wed, 11 Nov 1998, John Payson wrote:

> If more I/O is needed that what would remain after the DRAM
> was interfaced, then use of extra hardware or a PLD to aid in
> the DRAM interfacing might be warranted.  As for pricing, my
> impression of the PLD/FPGA situation is that going much beyond
> a 22V10 requires expensive development tools.  Is this no longer
> true?

The latest info is that most development tools have trial/demo versions
that will let you use a small subset of the parts from that manufacturer
for a limited amount of time at least. Registration is also not in the
'killing' class anymore, $500 will get you going pretty far. Entry level
packages are from $0 to $199 or so.

The most popular makes use a downloader cable that is simpler than the
simplest DIY PIC programmer.

I believe that there will be A LOT more FPGA use in amateur and startup
circles in the following year. This is not going to affect PICs imho
(PICs are very lean + mean for their price).

I have said before that I did an IDE disk interface with a PIC16C64 and I
believe that a SIMM can be driven in the same way. The only point is, that
most beginners jump into a design head on without computing anything. A
serial RAM or two and a small PIC may end up being cheaper than doing it
all from scratch with a SIMM and will beat the SIMM at power requirements,
data retention and more.

Peter

1998\11\14@092737 by uter van ooijen / floortje hanneman

picon face
Is a description of your IDE interface available somewhere?
regards,
Wouter.


> I have said before that I did an IDE disk interface with a PIC16C64 and I
> believe that a SIMM can be driven in the same way. The only point is,
that
> most beginners jump into a design head on without computing anything. A
> serial RAM or two and a small PIC may end up being cheaper than doing it
> all from scratch with a SIMM and will beat the SIMM at power
requirements,
> data retention and more.
>
> Peter

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...