Dual-port SRAM? Or something else? - Page 1
Forum section: electronics / beginners

author: MacAttak
author_rank: Unknown
timestamp: April 03, 2013, 06:24:46 am
content: Hi!I'm tinkering with some digital circuits and would like to be able to share a memory buffer between two stages of processing. The two stages would be operating with different (unsynchronized) clocks. The slower (and irregular) clock will only ever bewritingto the buffer, and the faster (and regular) clock will only ever bereadingfrom the buffer. The total amount of data that would need to be buffered for now is less than 2 KB, ideally using an 8-bit parallel bus so I don't have to waste clocks on shifting bits in and out.The fast "reading" side would be mostly a repeating sequential scan of a segment of the buffer, while the slower "writing" side would be almost entirely via random address access.To me, as a novice, this sounds like something that a small dual-port SRAM chip would be appropriate for. But maybe I am looking at this wrong and perhaps there is a better solution? The smallest SRAM PDIP chips I could find are 48-pin, and seem fairly expensive at $7 - $12 each for 16Kb, with minimum quantity restrictions... which is a red flag to me that this isprobably notthe "normal" way of solving such a problem. Also, the fact that all signal data is "one-way" through the buffer makes me question whether using SRAM is the right answer since it is designed to allow read/write from either port.Are there any suggestions for better ways of accomplishing this? Or maybe suggestions for certain parts I might not have found in my searches?I am currently using 5v logic parts in this but am perfectly OK with switching to 3v if needed.Since this is living on a breadboard for now I prefer PDIP (and cheap) parts... but if I really need to solder a QFP or PLCC onto a breakout board then I am OK with doing that too.I know I could do this easily with a small microcontroller or FPGA, but I'd like to see if it is solvable in a reasonable manner using plain logic silicon first.

author: AndyC_772
author_rank: Super Contributor
timestamp: April 03, 2013, 06:31:35 am
content: Dual port RAM sounds like a perfectly reasonable solution to the problem to me.You may find the chips are expensive because there are relatively few designs which use a discrete RAM instead of just using the internal memory blocks in an FPGA.

author: digsys
author_rank: Unknown
timestamp: April 03, 2013, 08:58:44 am
content: FIFO RAM. No address lines needed. Only have a couple control lines in and out.Only limitation - you can only read out in the same order they were written in.

author: David_AVD
author_rank: Super Contributor
timestamp: April 03, 2013, 09:16:13 am
content: I suspect the OP wants to read the contents out repetitively at a fast rate, while only updating it every so often.Can I ask is this to do with LED light strips?

author: westfw
author_rank: Super Contributor
timestamp: April 03, 2013, 09:25:13 am
content: The normal way of doing this probably involves DMA, which you can think of as a way of multiplexing the address and data buses of a memory between two different pieces of access hardware. Dual-Port RAM is theoretically "ideal", but as you not is quite expensive, and tends to be reserved for applications that really need the high speed or low latency, or that have special natures that make it easier to implement ("video RAM", for example.)

author: SeanB
author_rank: Super Contributor
timestamp: April 03, 2013, 03:59:16 pm
content: Simple solution is to use ram a little faster than the fastest acess ( read in your case) and arrange a set of double buffered latches to latch address and data for the write, then write it to the ram during the period when it is not being read ( reading having a clock, write being done in the inactive clock period).

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 03, 2013, 04:21:47 pm
content: QuoteDepending on speed, MCU or FPGA would be the easiest & cheapest way to do it. On an MCU, an interrupt task and/or DMA would be set up to do the output as a background task.Depending on the content, You may want to double-buffer it to avoid "tearing" artifacts - where a partially rendered object is displayed for one frame.If an MCU isn't fast enough, it would be easy to do using the internal dual-port RAM in most FPGAs.Doing it in hardware with normal SRAM gets messy because of the address multiplexing - doable, but there are just easier and cheaper ways of doing it nowadays. CPLD+SRAM is another option which may be cheaper than FPGA, but as long as the RAM size and speed allows, and MCU is going to be the optimal solution.Dedicated dual-port RAMs are pretty rare nowadays as most systems that would use them would probably be using FPGAs anyway, which have the DP RAM functionality built in.

author: MacAttak
author_rank: Unknown
timestamp: April 03, 2013, 11:28:35 pm
content: Quote from: David_AVD on April 03, 2013, 09:16:13 amIt's not for LED light strips, although I think you have the general idea of what I want to do. It is for a data visualization experiment, where the data being visualized (a subset of the total data stored) needs to be read repetitively and quickly, and the data itself is updated infrequently by comparison and by totally different circuitry.In programming terms (which comes more easily to me), it would be like a N-dimensional data array (N > 3, so it is hard to visualize), where a 2D slice is being used to drive a point matrix to visualize the shape of those dimensions selected for the slice.

author: MacAttak
author_rank: Unknown
timestamp: April 03, 2013, 11:44:30 pm
content: Quote from: SeanB on April 03, 2013, 03:59:16 pmInteresting approach, it seems like it should work, as long as the variable input clock never cycles faster than the output clock.I was thinking there would need to be a "busy" signal to let the memory circuit know when the latches are loaded and ready to be written, so that it doesn't re-write the data again on the next cycle if there wasn't anything needing to be written... but on second thought that really wouldn't matter because it would just be writing the same data into the same location anyways.So yeah, I like this approach and will see how it works out.

author: SeanB
author_rank: Super Contributor
timestamp: April 04, 2013, 05:33:27 pm
content: I saw that in an Elektor article that used it to write to a ram used to make a long persistence adaptor for a standard analogue scope. It had a fast readout, and a slow write into the ram chip, which was only updated when the address was equal to the desired value.