initialization sequence and auto refresh for sdr-sdram

Does anyone here know the purpose of the SDRAM initialization sequence?

I have never implemented it and never noticed any sort of failure in my designs.

This may be because I mostly use it for frame buffers and fifos (sequential access), not cpu (random access) designs.

Alan Nishioka

I am not sure I understand what you're saying. You never implemented the initialization sequence? Isnt it essential to do it irrespecitve of the way the sdram is used? or maybe you meant auto-refresh? Please do clarify.

I am also working on frame buffers and noticed that some of the scan lines looked wrong. Auto-refresh seemed to be the only command that affected the image.

- Subhasri.K

I have never implemented the SDRAM init sequence. The manual says it is essential, but not why.

Also, I don't refresh (auto or otherwise) since I am continually writing and reading every row that I am interested in.

This has worked fine for me with several different designs and several different SDRAMs (Hitachi, Micron and Samsung that I am certain of).

It seems that you are trying to do a similar thing, so I don't know what is causing you problems. I didn't use refresh (auto or otherwise) because I didn't need it and it would have interrupted my stream at an inconvenient time.

Alan Nishioka

It means 2 auto-refresh commands, as though you were doing a distributed refresh.

Are you simulating using the Verilog or VHDL models provided by Micron, and if so, do you have the debugging statements turned on? Micron has excellent HDL simulation models that check many, if not all of the signal timing relationships.

No, the device is in the idle state because of the Precharge command; the auto-refresh doesn't activate any banks. If the device is not idle before auto-refresh, I don't think the manufacturer guarantees anything. The Micron HDL models will spot these problems.

--
Joe Samson
Pixel Velocity

To prepare the memory for the first access (by making sure that the device is in idle, all open rows precharged, and recently refreshed) and to set the mode register.

--
Joe Samson

I suppose that's all the SDRAM init sequence is for. I guess I was expecting something deeper. And it confirms my belief that it is unnecessary in my frame buffer application.

Alan Nishioka

So the address is being generated internally and refresh is performed at regular intervals. What if I donot issue any more refreshes after these initial two auto-refresh command? Also, I am wondering if there is any difference between these two ways of writing to an sdram with 256 columns in each row.

1) Open a row. Write 256 values continuously (single burst). Close row. 2) Open a row. Write about 30-32 pixels(once a fifo is almost full). Close row. Open row again after fifo reaches almost full and write 30-32 pixels. Close row and so on... Is there a timing constraint in the second case that I should be aware of. For the first case I am able to get the sdram to work.

Thanks for the pointer. I was able to download it and I am going take a look.

Subhasri.K

I don't see how that follows at all from my explanation.

1. "To prepare the memory for the first access"

- Unless you don't plan on having a first access, you will need to make sure that the memory is in idle before you open a row.

1. "to set the mode register"

-You need to tell the memory the burst size, CAS latency, burst sequence...

--
Joe

As long as you are reading every row within the distributed refresh time spec you should be OK.

There's no need to close the row just because you have stopped reading or writing. It may simplify your state machine, but the memory is happy to NOP until you get back to it. In my last SDRAM controller, I could have as many as 4 rows open at a time (one per bank). I'd keep them open unless I had to change rows or do a (distributed) refresh. There is a spec (Tras) on how long a row can stay open.

The second case looks identical to the first except for the length of the burst. If you're designing a memory controller, you need to be aware of every timing constraint.

There are a lot of good postings in comp.arch.fpga on SDRAM controller design and board layout. You should go through them. I seem to recall a good discussion on what's actually happening inside a DRAM (although I can't find it now).

--
Joe Samson
Pixel Velocity