Big DRAM chip for Propeller (32M bytes for $7.24)

cgracey · 2009-01-28 00:52

Historically, I always shied away from designing around big DRAM chips, as their sizes, hookup schemes, and packaging were always in flux states. This probably was due to PC's·soley driving the market,·keeping·product lifespans very short. It seems that now, though, maybe due to MP3 players, cameras,·and cell phones, there's some big cheap, stable DRAM available in relatively easy-to-use packages with simple interfaces.

You can now get a 256Mbit DRAM in·a 54-pin TSOP package for $7.24,·or $3.90 in 10k volume:

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=557-1289-2-ND

I checked around, and this 256Mb is definitely the sweet spot. These chips run purely off 3.3V, too.

I'm trying to figure out how to incorporate this into Prop II somehow, but somebody could make an object for the current Propeller right now. This would take a lot of I/O pins, but if you used the 4-bit-wide version (there are also 8-bit and 16-bit versions for the same price), you could do it in 24 pins. You could save a lot of pins, too, by using 74HC595 serial-to-parallel converters, and then operating the DRAM in burst mode to get the speed back up. That could cut the pin count·in half.

Just a thought. I'm excited that there's a big, cheap, stable DRAM platform out there now. This opens some big doors.

·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

Post Edited (Chip Gracey (Parallax)) : 1/28/2009 1:00:26 AM GMT

Cole Logan · 2009-01-28 01:22

I would say that it is always a very good thing when the guy making the chip is excited. I'm going to have to look more in to this but I don't know if I would have the expertise to make it work.

Mike Green · 2009-01-28 01:47

Refreshing is an issue with DRAM. You really don't want the Propeller to have to do that because, if there's a programming error, or even on a reboot, you'll probably lose the contents of the memory. The only way I'd want to use a DRAM would be if there's a memory controller on-chip or some kind of external controller that's a "set and forget" sort of thing.

I did look at the datasheet and there is a Self-Refresh mode.· With a little external logic, it looks like the chip could be made to do self refreshing if it's not active.· If the chip is active, there needs to be externally managed refresh cycles every few microseconds.· This would not be in the "easy to use" category and there would be some situations where easy programming errors could make you lose your memory contents.

Post Edited (Mike Green) : 1/28/2009 1:57:16 AM GMT

Mark Swann · 2009-01-28 02:00

Mike Green said...
Refreshing is an issue with DRAM. You really don't want the Propeller to have to do that because, if there's a programming error, or even on a reboot, you'll probably lose the contents of the memory. The only way I'd want to use a DRAM would be if there's a memory controller on-chip or some kind of external controller that's a "set and forget" sort of thing.

Why can't a cog perform the job of the memory controller?

I don't understand your concern for the DRAM losing its memory after a reboot. It seems natural that when the Prop loses knowledge of its current state, that it should also not trust the state of the DRAM.

Mark

Mike Green · 2009-01-28 02:31

A cog can certainly perform the function of a memory controller. Whether its important to maintain the content of memory during programming problems or over a reboot or download depends on how the memory is to be used. We're talking about 256MBit which is 32MB. There's not a lot of need for 32MB in a microcontroller except for persistent storage and that would require some kind of circuitry to ensure that, if the Prop isn't refreshing the memory properly, the memory's self-refresh kicks in automatically.

awesomeduck · 2009-01-28 03:11

I think there is a need for a lot of memory in a microcontroller. Its hard to do anything on an Ethernet without some big buffers. Problem is this is really going to eat up pins. If only it was possible to cram a MB of RAM inside the Propeller the game would completely change. The places you could use the Prop with minimal extra logic would be huge.

kwinn · 2009-01-28 03:37

This chip looks like a great fit for Cluso,s multi prop board. Dedicating a prop to access memory and run an emulator could be done for the 32Mx8 or the 16Mx16 and provide plenty of memory.

PS This is an sdram so I think refresh can be set up to occur automatically. Have not had time to take a careful look at the data sheet so I am not positive, but that is generally how sdrams work.

Post Edited (kwinn) : 1/28/2009 3:43:21 AM GMT

cgracey · 2009-01-28 03:51

There is a 13-step (I think) initialization procedure for this SDRAM. It reminds me of a Hitachi 44780 LCD controller. This is complex enough that a cog would have to AT LEAST perform the initialization, then maybe turn over access to some hardware.

Big RAM could be great for data buffering and signal processing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

heater · 2009-01-28 05:03

32MB and ImageCraft C. Linux will come to the Propeller.....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

hinv · 2009-01-28 05:28

heater, that is exactly what I was thinking!

Mike, I don't know how many times people have come up great plans only to find that they didn't have enough memory(ie VGA drivers). In my opinion, that is the biggest thing holding the propeller back, of course, the b version of the prop would let you have the pins to handle that ram also.
If it was me, I would rather have the B version prop in 3 months, and the Prop II in 15 months rather than no B version and prop II in 12 months.

Yes 32MB is big, but if it is only 1 chip, and you can attach it to 24 pins, it doesn't sound too much of a problem. If someone makes an object to support it, and the schematic, I would be a one size fits all solution at $7.40. If you didn't need that much memory and more pins, don't attach as many pins.

just my 10 bits worth,
Doug

Cluso99 · 2009-01-28 05:43

Chip: Excellent find. Thankyou.

Now, how can I add it to my "Blade"? It is SMT 0.8mm pin spacing and that is too fine for most hobbyists.

I don't recall how long the prop takes to boot. Can a cog setup the SDRAM within the 100uS? I am fairly sure my "Blades" cannot achieve this, so will have to do a little thinking.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)

My cruising website is: ·www.bluemagic.biz

Dr_Acula · 2009-01-28 05:54

Nice find. Big memory is good! Code will expand to fill the available space, even if it is 32Mb or more. Audio processing, video processing, FFTs, data logging, big array manipulation, neural network simulations, the list goes on.

Hmm, a 54 pin chip with those tiny pins. If the memory is allowed to be something other than a DIP and it is allowed to have >40 pins, then is a Prop II also allowed to have lots of pins? Then the "running out of pins" problem isn't such an issue. Eg 64 or 100 pins in a format that can fit in one of those adaptors that changes to a standard DIP, or at least 0.1" spacing. Are extra pins hard or expensive to add to a chip designed from scratch?

jazzed · 2009-01-28 07:48

I put a 1MBx8 DRAM on a Prop-proto in the summer. Performance sucks. Refresh is easy.
If there were not so many steps to make it work (load ras, load cas, access data), it might be ok.
Burst mode access doesn't make up for lost setup time so much.
Now if you threw 2 or more COGS at the problem it could be better. How would you do that though?

My DRAM Access cycle times:
  Write 1 byte: ~ 1.0 us
  Read  1 byte: ~ 1.1 us
  Write 2 byte: ~ 2.2 us
  Read  2 byte: ~ 2.2 us
  Write 4 byte: ~ 3.7 us
  Read  4 byte: ~ 3.8 us

I'm working on an 2MBx8 SRAM version which uses many more pins and has better performance.
I've allowed for a 12 bit parallel bus (8D,2A,2C) to a piggy-back propeller for expansion.

New SRAM 16bit-ALE Access cycle times:
  Write 1 byte: ~ 1.1 us 
  Read  1 byte: ~ 1.5 us (read/modify/write)
  Write 2 byte: ~ 1.05 us
  Read  2 byte: ~ 1.1 us
  Write 4 byte: ~ 1.25 us
  Read  4 byte: ~ 1.5 us

Having 2 Propellers working in parallel to use the same physical memory device might open interesting possibilities.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Ale · 2009-01-28 10:03

@Chip,

Any help from the Propeller to access the SDRAM will be welcomed. I think you mentioned enough opcode place ?. Something like 2 HUB opcodes one load address one read/read next and one write/write next will be ok. If the clocks and all that is done by the prop. That would enable the propeller to grow without going to excessive hoops.

Baggers · 2009-01-28 10:24

@Chip,

Giving the PropII additional access to this external DRAM would be cool, I'm sure we'd all be happy if it was like a hub-op, and you only get access to it after X cycles, but from accessible from anycog like hub-ram is, would be awesome [noparse]:D[/noparse]
If you can do it, ( well we all know you can do it!! so ) I say go for it!!!

Jim.

edit: or even if it's some kind of DMA to and from HUB-RAM?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

william chan · 2009-01-28 11:24

How do you tell if a product is going to be stable and available for the next 15 years?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my

kensong · 2009-01-28 11:57

Hi Chip, and all,

Normally I'm too shy to speak. But I read the "long thread" (cogs/RAM one), and this has been rattling around in
my head since before Christmas and if I don't say it, I'll regret it. RAM issues:

It seems to me that on the next Prop it might be best to make it (almost) all RAM, from the layouts it looks to
me like you could turn the 256k/256k into 384k of RAM, given that at about Page 15-20 you (Chip), with Phil
and co. seemed to largely solve the "multi tasking" problems (thus making 8x160mHz Cogs enough), and that
the Prop will allways need a boot ROM (production process) it seems more logical for you to put your great genius to work on a (simple?) boot loader(s), possibly for more than one ROM source, ie cover the bases on
future ROM options (and prices).

This "extra" 128k RAM would seem useful to the geniuses that came up with the LMM and C progressions, as I
imagine the HUB ram will always be the fastest available (certainly to all cogs).

The other advantage I see of doing this is that now you have this rather talented team of "outlaws", the SPIN
interpreter can be one option, with various other boot load options being possible. Equally you don't have to
be as rigourous in SPIN testing as you were before, well, OK you do, but it won't count so much if you find an
enhancement 6 months after release. I hope this could add to the longevity and applicability of your wonderful
processor architecture.

I see what you mean bout the "cheap" dRAM though. Sorry if I've gone "off topic", but it made me think about
RAM.

K

hinv · 2009-01-28 12:33

The prop was designed from the beginning to have 64 I/Os eventually. This is the B version I was talking about. DIRB and OUTB registers already in the current prop, they just aren't wired. If they didn't run into the trouble with their chip verification software, we might have had one already.
Of course, it wouldn't fit in a DIP package with 64 I/Os, but

awesomeduck · 2009-01-28 14:32

jazzed...I agree...a sort of multiport RAM communication between two Props opens up lots of very cool applications.

Can some point me to the thread that explains what the Prop B is....I gather there is a version that brings out all the IO in the works...would like to follow that thread bu can't seem to find it.

Bob Lawrence (VE1RLL) · 2009-01-28 15:03

@awesomeduck

Chip Gracey (Parallax) said...
Posted 4/20/2006 1:01 PM (GMT -4)

We plan to make a 64-I/O-pin version of the current Propeller soon. It will be identical, except for the addition of a 32-pin 'B' port, and of course a bigger package with more pins. This chip should be ready in six months. We are also working on the next-generation Propeller chip, which will be an order of magnitude faster than the current chip. It is probably a year away.

http://forums.parallax.com/showthread.php?p=582770

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob

Mark Swann · 2009-01-28 16:20

Bob Lawrence (VE1RLL) said...
@awesomeduck

Chip Gracey (Parallax) said...
Posted 4/20/2006 1:01 PM (GMT -4)

We plan to make a 64-I/O-pin version of the current Propeller soon. It will be identical, except for the addition of a 32-pin 'B' port, and of course a bigger package with more pins. This chip should be ready in six months. We are also working on the next-generation Propeller chip, which will be an order of magnitude faster than the current chip. It is probably a year away.

http://forums.parallax.com/showthread.php?p=582770

Look at Chip's posting date. That's two years ago. Hmm.

Baggers · 2009-01-28 19:04

@Mark,
That was a while ago, but since then they've also stated that they had problems with bugs in the software that lays out the chip, and thus have not been able to proceed with the design of that [noparse]:([/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

awesomeduck · 2009-01-29 21:46

So can someone fill us in....will there ever be a full 64 IO pin version of the chip available?

Paul Baker · 2009-01-29 22:45

The Prop 2 is 64 IO pin so yes (I know this wasn't what you were asking).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker

cgracey · 2009-01-29 23:39

awesomeduck said...
So can someone fill us in....will there ever be a full 64 IO pin version of the chip available?

We have the layout almost done for a 64-pin version of the current Propeller chip. There are just·"twelve" LVS (layout-versus-schematic) errors that need to be located and fixed. These errors crop up when the cogs are merged into the rest of the layout, even though every block LVS's separately, just fine. This is a bit of a needle-in-a-haystack problem. The LVS engine says that there are twelve extra MOSFET devices present in the layout, beyond what the schematic indicates. When it encounters a problem like this, it causes the verification effort·to abort early, so that there are few indications as to WHERE these devices might be. Ultimately, this delay is my own·fault, as I have not worked closely with the layout engineer on finding the problem. This has dragged on for so long that we are wondering if it is worth the $80k to bring this device to production, given the closeness of the next Propeller.

Are many of you·interested in a 64-pin version of the current Propeller? The current Propeller architecture will always be the lowest-power. The next version is much faster, but will also leak 1mA, due to the 180nm process.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

Cole Logan · 2009-01-29 23:50

I would think that the 64 pin one would be great for Mobile devices. One example that I can think of would be if you wanted to use a 24 RGB lcd like that made by sony for the PSP. I'm working on two projects right now where having more pins would be a plus. Ones a Home Automation Device where I'm monitering several things in a room and controlling several things at once. Another WOuld be for Christmas Light Controller.

Timothy D. Swieter · 2009-01-30 00:05

An $80K bill just to get the 64 pin Prop 1 out?! Well....I don't think Parallax should spend that money on account of my opinion alone, so I hope other speak up, but I could find uses for the 64 pin version. I could make more items controlled in parallel instead of serial which would make the overall system faster. I don't have any exact, specific, applications yet, but I can start dreaming and have something ready. There are a couple different displays I have been wanting to play with and using parallel would be best. Of course, then I will want more RAM and the speed of the Prop II - oh how I have ideas for a Prop II........

.....what was that book? If You Give a Mouse a Cookie?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto for SunSPOT, BitScope
www.tdswieter.com

ProcessingData... · 2009-01-30 00:07

I say make it. We·could use·a chip with the prop1's cogs, and the prop2's I/O's. With these extra pins, we can create robots with more sensors, better Openstomp like projects, and minicomputers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Basic Stamp,···· Propeller,·· · SX,·· FUN!

START:·
>Proccessing Data. . . .··
>Task Complete. . .·.
>Saving Data. . . .
>Entering SLEEP Mode. . . .
>Signing OFF

·

Mark Swann · 2009-01-30 00:14

Will it slow down release of the Prop II ?

cgracey · 2009-01-30 00:23

Mark Swann said...
Will it slow down release of the Prop II ?

No. It just takes money.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

Rayman · 2009-01-30 00:29

I would definitely be interested in a 64-pin version!·

Wait a minute...· What kind of packages would it come in?

Big DRAM chip for Propeller (32M bytes for $7.24)

Comments