help to understand "memory" ?!?!?!

nicolad76

Hello everyone.....I have been browsing this web site for months...I am now looking fo a memory chip to implement a kind of video driver for a specific display I have. It requires at least 64KByte. For many reasons I prefer not to use the "tiles" technique of existing video driver since my Prop would need its memory for other processes...

In order to understand what you guys are doing, I have been reading this forum for a long time.
I could see that many of you are using different types of memory (flash, eeprom etc...) but they all have one problem in common...100.000 read/write cycles limit.

I understand that the·chip would be rated at least 100.000 cycles but...do you think it is reliable? do you find that number enough for your application? I wouldn't use it for a video support since I would quicly reach such number of write/read operations....
I cannot believe you guys use such memoriy chips just for data loggin so some of must have had same problem I am facing now.

What I want to understand is, how do you guys workaround such limit, i it a real limit?
I have been looking to parallel NVRAM providing unlimited (?!?!?) read/write cycles but they are too expensive to play with.

Please shade some light [noparse]:)[/noparse]

Thanks!!!!!
Nicola

Mike Green

What kind of access speed do you need?

EEPROM (or even FRAM) is not good when you're going to have high speed continuous access to the memory. Flash EEPROM doesn't wear out on reads, but wears out as you indicated on writes. Writes also take a long time (milliseconds). FRAM is faster and more durable, but wears out with read or write cycles and, if you're accessing memory every few microseconds, it only takes a few hours to wear the memory out.

There are some memories that combine a SRAM with unlimited and fast access along with EEPROM used only on power on/off cycles, but it's expensive as you mentioned.

Can you use plain SRAM. It's pretty cheap. In parallel form, it's available in 32K byte and (I think) in 64K byte sizes. If you don't need the speed, you can also get 32K byte SPI SRAM. You could even put a couple in parallel to ease the speed hit (by transferring a block of 4 or 8 bytes at a time).

nicolad76

My application does not require fast access memory.
It will draw the image in memory and the display is b/w 800x600 with an estimated refresh of half second...so I would say planty of time...

I will follow your suggestion and I will look for SRAM...but, still, what kind of application will accpet the limit of read/write cycles besides data logging?

Thanks Mike

kwinn

Nicola, when you say b/w do you mean shades of gray, or do you mean each pixel is on or off only? The answer makes a big difference in the amount of memory required. If it is only pixel on/off you need 480,000 bits, which is only 60,000 bytes of memory. If however you want shades of gray you need much more, for example for 256 shades of gray you need 480,000 bytes. As Mike said earlier SPI SRAM may work for this application, but most video display circuitry uses the faster parallel SRAM.

nicolad76

yhea...u r right... I meant 2 colors so each pixel would be either on or off.
Thanks!

Mike Green

Many applications (including operating systems) do mostly reading of data. That's why flash memory cards work so well for general computing. These use the same type of memory cells as flash EEPROMs with the same write limitations including time to write. They're designed to work a little faster by pre-erasing blocks of memory and separating the erase from the write cycle, but they're pretty much the same internally. The flash cards also include some smart processing with large SRAM buffers and the memory controller does load leveling where it chooses where to put data based on how heavily that section of memory has been used. If you rewrite a sector a lot, it will be moved around so that it's physically in different locations in the memory array over time. The memory controller keeps track of its actual location so it knows where to go to read it when it's wanted later.

potatohead

Does the image change much?

What I'm getting at is let's say the image is written to something cheap, that does not tolerate tons of write cycles. Maybe don't write to it at all!

Break the display into zones, or build it like a scan line renderer used often here for games.

For each scan line, fetch the primary image from the bulk storage device.

Then mask in the changes from small RAM buffers

Draw!

That way, you only use a little bit of RAM for those things that change, leaving your choice of devices high.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

kwinn

I would suggest keeping it simple. A 1Meg SRAM chip (128Kx8) costs less than a 512K one does and provides a second page of screen memory so you can be displaying one page while creating the next one.

I am curious though, does this monitor actually scan that slowly (once per second or so) or is that how often the image in memory is updated? That will make a difference to the circuitry. Also, do you already have the circuitry for this and just need the memory?

nicolad76

The display itself it is not able to have faster refresh since it is eink. The driver of such display requires a bitmap to be transmitted 1 byte at the time.
In the current solution I have divided the screen orizontally in three tiles and I generate and transmit one part at the time.

The system works but there is a lot of overload due to the fact I have to manage object that appears on more then 1 "tile".
I use only three tiles because I could have many small object to display and I do not want to loop several time to draw each tile.
In order to do so, the memory buffer I use is quite big (800x600)/3/8=20KB.
I was looking for a simpler solution in order to free up memory and draw objects only once.

kwinn

That clears up a lot of questions for me. In that case I would really suggest you use the 1Meg SRAM chip.

nicolad76

ok! Thanks!

hinv

hi kwinn,

Do you have a specific chip in mind? How to interface it?

Thanks
Doug

evanh

Heh, go completely object based rasterising, forget the framebuffer and tiles. [noparse];)[/noparse]

Another tidbit, have a read of the list on the right-hand side for a crazy list of memories.

kwinn

Hi Nicola,
I would suggest the Cypress CY7C1019DV33 128Kx8 ram.
You will need 17 address lines (16 if you only want to use 64K), 8 data lines, and 3 control lines (*CE, *WE, *OE) for the chip.
These could be taken directly from the prop I/O pins if you had them to spare, but most likely you do not.
You can use 8 I/O pins for data and 5 I/O pins for control lines, 3 8 bit latches to hold the address and *CE.
If you want you can use the 6 unused outputs of the third latch for outputs.
Take a look at Dennis Ferrons Propeller Laptop project to see something similar. The only thing I would suggest is using 74AC574 latches instead of the 244's. Easier to wire the 574's.
If you really want to use the absolute minimum number of pins you can use shift registers to get the address out and data in.

Dr_Acula

I'll second kwinn's suggestion.

Memory has got confusing. Back in the olden days you didn't have memory that "wore out".

Luckily the chips that don't wear out, ie static ram chips (SRAM) are still around, and in lots of sizes from 2k up to 512k (and probably further).

Static ram chips can usually be configured to retain their memory with a battery backup using a cheap DS1210 chip, and that works out a lot cheaper than non volatile ram packages.

But you don't need permanent storage here. You just want a ram chip you can read and write millions of times. And it will be millions of times, probably millions of times in a few seconds.

There are stores with so many ram chips it gets confusing. I kind of like futurlec because they seem to have what I want but not much stuff I don't want, so less to wade through. This page summarises the sort of ram that you could use: http://www.futurlec.com/ICRAM.shtml Just watch the 5V/3V issue - though this seems to be easily fixed with rows of 1k resistors. Or sram chips that run on 3V. This could be as cheap as $2.90 plus 24 resistors.

Post Edited (Dr_Acula (James Moxham)) : 1/4/2009 6:53:28 AM GMT

evanh

Dr_Acula (James Moxham) said...
... static ram chips (SRAM) are still around ...

In case people might think SRAM is rarely used now, it is the memory type built into all logic circuits. This includes CPUs, GPUs, FPGAs, and pretty much everything. SRAM and mask ROM are the only memory types fast enough to keep up with high-end logic. Cache RAMs (Both external and internal types) are SRAM.

evanh

SDRAM is another one, particularly the DDR variants. It's burst transactions are achieved through the use of banks of SRAM and logic to handle the mux'ing and clocking translation between the external memory bus and the internal bulk DRAM.

Baggers

Hi Nicola,
Just to throw a spanner in the works, have you seen Andre's HX512 SRAM card for the Hydra?
that is 512KB which is ample for your requirements, but it comes with pre-written ram read/write routines, etc.
might be an easier route for you? it also only needs 10 io pins iirc.

http://www.xgamestation.com/view_product.php?id=43

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

·

nicolad76

Wow...a lot of good information here...thanks to you all....
I considered that since I will probably write one byte at the time but I will read at least 1 KB at the time and send it to the display, I will use a counter to set up the address, does it make sense to you?
One more question, I would like to make it a little bit more difficult.... I would like to share pins between display and memory (they both have chip-enable) so they have a bus in common, what kind of circuitry should I use? I believe that soldering the pins directly to the common bus wouldn't be a good idea....
Thanks
Nicola

kwinn

Using a counter makes very good sense. Take a look at the 74ALS867. The only problem is it is a 5V chip. As for connecting the display pins directly to the data bus, if it is possible (8 bit, input only or tristate) I think it would be good to connect them. That way you could set up the memory chip to put the data out on the bus and write it directly to the display. No need to input it to the prop first then write it to the display.

Baggers is right about the HX512 ram card although I counted 12 lines in the block diagram not 11. If it would work for your application it is the easier way to go.

rjo_

Nicola... there IS a LOT to digest on this thread. So, trying to be helpful... let me add my two cents... which use to be worthless, but the penny is making a comeback in my part of the world (Kenya West... the Obama heartland... Illinois):

1. Baggers is always right.

2. Andre includes a lot of information with his little card ... very clear documentation that might be the shortest path to your goal.

AND if you want to do more... he also includes tools and documentation that will take you beyond his card if that is where you choose to go.

Very interesting project.

Rich

nicolad76

Hi guys,
I see a lot of new things for me... HX512 seems to cost $60...I was looking for something cheaper...
My system is not so "high tech" to require such memory system but I like it..indeed...

I'll try to put all your comments together and come out with some smart design (well...forget about "smart" [noparse]:)[/noparse] )
Thanks again

Andrew E Mileski

You can hook-up static RAM chips.

For Example: Using two 74HC374 Octal D-Type Flip-Flops (or 74HC373 Octal D-Type latches) to create a multiplexed 8-bit parallel data bus with 16 bit parallel address bus, and connecting two 32 kbyte 62LC256 (and equivalents) SRAMS. These old SRAMS are quite common on E-Bay. They are usually 5 Volt parts, so the usual steps have to be taken to interface them to the 3.3 Volt Propeller. The chips usually have 70 ns or slower access times.

P0-P7: DATA0-DATA7 / ADDR0-ADDR7 / ADDR8-ADDR15 <- to data bus on both SRAMS, and latch inputs
P8: ~WE <- to both SRAMS ~WE
P9: ~OE <- to both SRAMS ~OE
P10: LOW_CLK <- To 74HC374 that outputs the low byte of the address to the SRAMS
P11: HIGH_CLK <- To 74HC374 that outputs the high byte of the address to the SRAMS
P12: ~CS0 <- to the first SRAM chip select
P13: ~CS1 <- to the second SRAM chip select

If you are really constrained for I/O pins, one can even use 74HC595 and 74HC165 parts to do it all serially, but it makes access much slower.

Post Edited (Andrew E Mileski) : 1/6/2009 7:29:21 PM GMT

kwinn

Nicola, the people who have responded to your request have covered pretty much very way of interfacing a prop to memory. Which one is best for your use will depend on exactly what you want to accomplish, how fast you want to get data in and out of the memory, and how many I/O pins are available on the prop after your other I/O pin needs are taken care of. Beware of using older parts to accomplish what can be done with fewer new chips. By the time you add in things like sockets, connectors, board space, and wiring it often ends up costing more and taking longer. It is also a good idea to include a little more memory, processing power, and I/O than you think is required initially.