Re: SDRAM Tutorials or Guides

I would appreciate any links to articles or source code on tests to

> determine the size and timing of the SDRAM and setting up the > controller.

In a nutshell: don't do that.

For an embedded application, you almost certainly shouldn't ever end up in a situation where you have to "determine" these --- you would use parts with strictly defined parameters instead and hard-wire them into the board.

Boot-time auto-detection of SDRAMs is notoriously messy and complicated business, if you want to be able to cope with whatever somebody decides to stick into those DIMM sockets. This issue is one of the few things that distinguishes well-done PC motherboaard BIOSes from el-cheapo ones, so obviously it's hard enough that even with 20 years of experience, not all BIOS programmers manage to get it right. I don't know about you, but I'd be scared at the prospect of having to re-invent *that* whell.

Sure, in principle it should be simple (read out the on-board self-description data out of the SPD chip and use those). But in practice you'll find all kind of nonsense on those SPDs, esp. in the cheaper sticks. And that's before you consider raw SDRAM chips instead of DIMM sockets, which of course won't have an SPD to begin with...

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker
Loading thread data ...

Hi Jack,

The best place to find those types of documents is from the SDRAM supplier. Micron has some great app notes regarding setting up SDRAM with Motorola MPC8xx processors, and I'm sure that they have stuff for the ARM achitecture also. Atmel should have some app notes on thier web site also, especially regarding setting up the memory controller.

Did you buy a reference design? The few thousand dollars spent on those can save weeks and weeks of debugging the memory controller configurations, and can simplify part selection.

HTH and good luck!

Elroy

Reply to
Elroy the Seedy Impaler

On 6 Aug 2003 10:49:16 GMT, Hans-Bernhard Broeker wrote in comp.arch.embedded:

I appreciate your opinion, although I did not go into great detail about the project and you made some understandable but incorrect assumptions.

I will be using an SDRAM chip soldered on the board, so I won't have an SPD.

But the product life cycle in my particular industry is very long. When the product first ships (12 ~ 16 months from now), it will be on the market for something in the range of 5 to 10 years. From the day the last unit is sold, we must support it with service, tech support, and spare parts (including new boards) for an additional 10 years.

All of this means that planning for dealing with parts obsolescence over time. In Flash, SRAM, and DRAM that means looking for a package designed for higher densities, so we will be able to move up to newer, higher capacity chips as the older, lower density ones become discontinued. A very important factor is designing the board to be able to do this without changing the copper.

So while I plan to use a 8Mb SDRAM right now (2MB x 32 bit), the layout of the board allows 16Mb, 32Mb, and 64Mb parts to be used as well. Eventually the 8Mb part may be gone but the 32Mb or 64Mb may still be available. They will have far more space than we need, but they will save the decision between a large lifetime buy or a copper spin.

Ideally, over the years as we might need to move up to 16Mb, then

32Mb, etc., it would be nice to avoid firmware changes because it was originally designed, and tested, to detect and work with the various sizes.

It would be nice if there were something for SDRAM along the lines of CFI for Flash, sigh...

Still, if you have any other suggestions, I will welcome them.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

Jack,

I read your previous post. Micron also has a good app note regarding density migration and planning for that in your schematic. Just FYI...

Elroy

Reply to
Elroy the Seedy Impaler

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.