Jack Klein <jackklein@spamcop.net> wrote:
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.
On 6 Aug 2003 10:49:16 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> 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
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
