SDRAM sustained bursts

Hello,

I am not sure if this is the right NG, but since it concerns memory driven by an FPGA, here goes.

My question is about burst writes to SDRAM memory (be it standard, DDR or DDR2).

Is it possible to sustain a burst write for an undefined number of words? Here is my setup: I have some incomming flow of data arriving at a constant speed of, say 250 MWords/s, which needs to be written to memory in a sequential order, until a Stop signal ends the burst. The length of the flow can be as long as several times the size of the memory, in that case the latter data overwrites the old one.

Do SDRAM require dedicated refresh cycles, even if the write cycles will access in turn every possible location in the memory?

Alternatively, would there be a way of refreshing a bank while writing into another one, without interrupting the 250 MWrd/s data flow?

If this is technically possible, do SDRAM Controller IPs available from FPGA vendors (i.e. Xilinx, Altera) support sustained writes with no gaps in data flow?

Any pointers to litterature, memory types, SDRAM controller IPs, would be appreciated.

Alex

Reply to
Alex Ungerer
Loading thread data ...

dont expect any available IP core to be able to do this. you will have to get fully custom version of the and SDRAM controller specially made for you application.

Antti

Reply to
Antti Lukats

I'm suspect you'll need regular refreshes. You'll need to raise the internal SDRAM clock rate to allow for refresh cycles and for initiating write cycles... after all, you can only burst write a page at a time. These operations all require multiple clock cycles to perform.

You could parallel multiple SDRAMs. SDRAM controller cores will generally let you do that. This increases the number of required connections substantially, but also multiplies the amount of data stored per clock transition and multiplies the amount of data that can be stored per write burst, drastically reducing the necessary SDRAM clock rate for a given data rate. This also reduces the number of refresh cycles that would be required per datum stored.

Dwayne Surdu-Miller

------------------------------------------------ Alex Ungerer wrote:

Reply to
Dwayne Surdu-Miller

You don't need to refresh memory as long as you touch (write or read) every row of every bank within the refresh period specification in the datasheet.

There is no "buried" refresh. Even at large burst sizes where the control could overlap access to another bank, you would need to do a read to the unused bank which would necessarily take over the part's data bus. If you have more than one physical bank of parts (i.e. more than one chip select) you could run refresh cycles on the unused parts. Note that auto refresh (what was CAS-before-RAS in the old days) requires ALL banks of the part to be pre-charged so you can't bury it during access to another bank of the same part.

I've used parts of a Xilinx reference design to start similar IP of my own. Generally the hard part of the design is getting the DDR data to look like SDR data at twice the width. I use the reference design for this data timing, and then use my own control logic to generate the sequence of commands I want to the RAMs.

You didn't mention a vendor. If you haven't picked the part yet, I would suggest looking into Lattice EC, Altera Stratix 2, or Xilinx Virtex 4. All of these parts make the high-speed data interface simpler.

Reply to
Gabor Szakacs

So long as you get the banking right so you can overlap the precharges, then doing the writing is no problem. You'll need to explicitly change row/bank each time you fill a row up, otherwise you'll just wrap around on the row.

If you change bank, then you can "start" the access (do the RAS bit) just before the current bank/row is full and then the data will be able to stream continuously.

So long as you "touch" each row in each bank often enough you don't have to do refreshes. I have done this in video applications where data is continually being read out, so no refreshes were required.

I think you can do this as well.

I don't know, but it wasn't that much effort to write my own when I got around to it!

I seem to recall that the Altera core has a fairly low-level interface so you may be able to overlap commands like you want to. Dunno about the Xilinx one.

Micron have *lots* of good datasheets.

Happy reading!

Cheers, Martin

--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
 Click to see the full signature
Reply to
Martin Thompson
250MWords/s that's often enough (you need to do a little math here to make sure it works), as Martin said, you dont have to refresh SDRAM during writing (assume you use write with auto precharge). But the problem araise when you stop the burst, what you going to do with the SDRAM? Pause & wait for user command? or read it out immediately... at what speed?
Reply to
thangkho

Looks like you have several different answers to your question. The data sheet I looked at says you can do this.

"Precharging one bank while accessing one of the other three banks will hide the precharge cycles and provide seamless, high-speed, random-access operation."

I did something very much like this once and had a printed app note (that's how long ago it was...) from Micron that described the operation of SDRAMs pretty well. I can't find an electronic version, but most of the info in the Micron data sheet which is not too bad. That Asian data sheets are not nearly as good, but they all work the same other than initialization details and they all are compatible with some basic init sequence.

The way to make this work without gaps is to overlap the precharge and read/write commands with the current command. So just make sure you set things up enough so that you meet all the timing specs, and there are a lot of them!!! If your clock speed varies it will be a lot harder to design.

BTW, you didn't say if you needed to do this on reads as well? Doesn't the unit play back too, or does it go directly into a PC?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Thanks everybody for your help, this will definitely help me make a decision. So far I have always worked with SRAM (Synchronous SRAM), but these beasts tend to get expensive when you need bigger sizes.

To answer Rickmans question, I do need to read the written data, but it can be done at much slower speed. This also implies that there will need to be some refreshing done when the SDRAM is not written to at high speed.

Alex

Reply to
Alex Ungerer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.