Purchasing memory DIMMs for embedded projects

We're doing a project that uses about 150 DDR2 SODIMMs.  Because we're
using an FPGA, rather than a conventional motherboard chipset, the DDR2
controller IP demands we have to burn the DIMM timing into the FPGA when
synthesising it, rather than reading the EEPROM at runtime.  The FPGA DDR2
memory system is a lot less bulletproof than the average motherboard, so it
needs to be heavily tested with a specific DIMM.

That means sourcing memory for this thing is a bit of a headache, because
supply of DIMMs tends to change from time to time.  For cost reasons we're
buying from standard PC parts suppliers, not the DRAM vendors' distributor
themselves (suspect this won't be high enough volume to make sense
wholesale).

Part of the fix for this is buying a particular part number of DIMM.  But
I'm particularly worried about things like the DRAM part or PCB changing,
without the DIMM part number changing.  Witness all the wireless routers
with the same model number but even a completely different CPU arch inside.

One way is to buy them all at once, and do exhaustive testing on examples. 
But it's a bit awkward to persuade a supplier to take them all back if it
doesn't work out.

An alternative is to assume the same part number means identical components,
perhaps between a sampling phase and a bulk purchase phase.  Is this likely
to be true?  Or does revving still happen in this sector?

Has anyone experience of using such commodity items in an embedded project?

Thanks
Theo

On 11/22/2012 10:51 AM, Theo Markettos wrote:
> We're doing a project that uses about 150 DDR2 SODIMMs.  Because we're
> using an FPGA, rather than a conventional motherboard chipset, the DDR2
> controller IP demands

What do you mean by "demands"???
Is this a contractual arrangement that they refuse to negotiate?
You can't be the only user who expects to need different memory over
the life of the product.

I think you're working on the wrong end of the stick.

Here's my horror story. We used a display controller.  We represented
somewhere near 0% of the vendor's component market.
Over time, they kept modifying
the timing spec so they could ship us whatever fell on the floor...take it
or leave it.
Wasn't a difficult process.  For every batch, we had to test them
and modify the EEPROM that programmed the FPGA.
Management was not interested in actually fixing the problem.

Well...one day, the purchasing manager decided that he could increase
his bonus by converting to a mask-programmed PGA and save $20 a pop.
Over my strenuous objections, they did it. First time we got a new
batch of display controllers, the line shut down.  Since it was MY
incompetence, I got downsized.  Good times...

Bottom line...
If you can't reasonably assure yourself of compatible component supply
over the life of the product, you're asking for BIG trouble.  Murhpy
reads the newsgroups, so he's already got your number.

  we have to burn the DIMM timing into the FPGA when
> synthesising it, rather than reading the EEPROM at runtime.  The FPGA DDR2
> memory system is a lot less bulletproof than the average motherboard, so it
> needs to be heavily tested with a specific DIMM.
>
> That means sourcing memory for this thing is a bit of a headache, because
> supply of DIMMs tends to change from time to time.  For cost reasons we're
> buying from standard PC parts suppliers, not the DRAM vendors' distributor
> themselves (suspect this won't be high enough volume to make sense
> wholesale).
>
> Part of the fix for this is buying a particular part number of DIMM.  But
> I'm particularly worried about things like the DRAM part or PCB changing,
> without the DIMM part number changing.  Witness all the wireless routers
> with the same model number but even a completely different CPU arch inside.
>
> One way is to buy them all at once, and do exhaustive testing on examples.
> But it's a bit awkward to persuade a supplier to take them all back if it
> doesn't work out.
>
> An alternative is to assume the same part number means identical components,
> perhaps between a sampling phase and a bulk purchase phase.  Is this likely
> to be true?  Or does revving still happen in this sector?
>
> Has anyone experience of using such commodity items in an embedded project?
>
> Thanks
> Theo

On Thu, 22 Nov 2012 18:51:36 +0000, Theo Markettos wrote:

> We're doing a project that uses about 150 DDR2 SODIMMs.  Because we're
> using an FPGA, rather than a conventional motherboard chipset, the DDR2
> controller IP demands we have to burn the DIMM timing into the FPGA when
> synthesising it, rather than reading the EEPROM at runtime.  The FPGA
> DDR2 memory system is a lot less bulletproof than the average
> motherboard, so it needs to be heavily tested with a specific DIMM.
> 
> That means sourcing memory for this thing is a bit of a headache,
> because supply of DIMMs tends to change from time to time.  For cost
> reasons we're buying from standard PC parts suppliers, not the DRAM
> vendors' distributor themselves (suspect this won't be high enough
> volume to make sense wholesale).
> 
> Part of the fix for this is buying a particular part number of DIMM. 
> But I'm particularly worried about things like the DRAM part or PCB
> changing, without the DIMM part number changing.  Witness all the
> wireless routers with the same model number but even a completely
> different CPU arch inside.
> 
> One way is to buy them all at once, and do exhaustive testing on
> examples. But it's a bit awkward to persuade a supplier to take them all
> back if it doesn't work out.
> 
> An alternative is to assume the same part number means identical
> components,
> perhaps between a sampling phase and a bulk purchase phase.  Is this
> likely to be true?  Or does revving still happen in this sector?
> 
> Has anyone experience of using such commodity items in an embedded
> project?
> 
> Thanks Theo

I think you either need to find (or make) DRAM IP that can deal with 
configurable timing parameters, or you need to chuck the idea of using 
DIMMs and just buy DRAM chips (and hope that they don't change or go 
obsolete).

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

On 22/11/2012 19:51, Theo Markettos wrote:
> We're doing a project that uses about 150 DDR2 SODIMMs.  Because we're
> using an FPGA, rather than a conventional motherboard chipset, the DDR2
> controller IP demands we have to burn the DIMM timing into the FPGA when
> synthesising it, rather than reading the EEPROM at runtime.  The FPGA DDR2
> memory system is a lot less bulletproof than the average motherboard, so it
> needs to be heavily tested with a specific DIMM.
>
> That means sourcing memory for this thing is a bit of a headache, because
> supply of DIMMs tends to change from time to time.  For cost reasons we're
> buying from standard PC parts suppliers, not the DRAM vendors' distributor
> themselves (suspect this won't be high enough volume to make sense
> wholesale).
>
> Part of the fix for this is buying a particular part number of DIMM.  But
> I'm particularly worried about things like the DRAM part or PCB changing,
> without the DIMM part number changing.  Witness all the wireless routers
> with the same model number but even a completely different CPU arch inside.
>
> One way is to buy them all at once, and do exhaustive testing on examples.
> But it's a bit awkward to persuade a supplier to take them all back if it
> doesn't work out.
>
> An alternative is to assume the same part number means identical components,
> perhaps between a sampling phase and a bulk purchase phase.  Is this likely
> to be true?  Or does revving still happen in this sector?
>
> Has anyone experience of using such commodity items in an embedded project?
>
> Thanks
> Theo
>

I agree with other posters' suggestions to get a better DDR2 controller 
in your FPGA.

But there is also a simpler method.  DDR timings are always a range - 
there is a minimum and a maximum clock speed, CAS delay, etc.  Figure 
out the slowest speed that most DIMMs support, and use that.  Then it 
doesn't matter if the actual DIMMs can run faster.

In comp.arch.embedded,
David Brown <david@westcontrol.removethisbit.com> wrote:
>>
>
> I agree with other posters' suggestions to get a better DDR2 controller 
> in your FPGA.
>
> But there is also a simpler method.  DDR timings are always a range - 
> there is a minimum and a maximum clock speed, CAS delay, etc.  Figure 
> out the slowest speed that most DIMMs support, and use that.  Then it 
> doesn't matter if the actual DIMMs can run faster.

That will work for the clock speed, but not for the CAS Latency, that
is an exact number of clock cycles. So if you make sure you only use
modules with the same CL, this may work. But higher speed modules often
have higher CL, just to allow them to internally get the data.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

I love children.  Especially when they cry -- for then someone takes them away.
		-- Nancy Mitford

David Brown <david@westcontrol.removethisbit.com> wrote:
> I agree with other posters' suggestions to get a better DDR2 controller 
> in your FPGA.

That's a bit difficult.  The FPGA vendor's IP doesn't support that, and I
just looked at another major FPGA vendor and I don't think their IP supports
it either.  Using third-party IP is likely beyond the budget, and volumes
are small enough that we're looking at a 'lifetime buy', because the next
release we'll probably change to a new FPGA with DDR3 anyway.  The board
isn't ours either, so the only option for using known chips is making our
own DIMMs - which seems rather pointless (and risky).

> But there is also a simpler method.  DDR timings are always a range - 
> there is a minimum and a maximum clock speed, CAS delay, etc.  Figure 
> out the slowest speed that most DIMMs support, and use that.  Then it 
> doesn't matter if the actual DIMMs can run faster.

Interesting idea... I'll have a look.  I suspect it will be tricky, given
the setup takes about 100 parameters, and getting DDR2 to behave reliably on
a completely custom setup is enough of a problem...

Theo

On 22 Nov 2012 18:51:36 +0000 (GMT), Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
> We're doing a project that uses about 150 DDR2 SODIMMs.  Because
> we're using an FPGA, rather than a conventional motherboard chipset,
> the DDR2 controller IP demands we have to burn the DIMM timing into
> the FPGA when synthesising it, rather than reading the EEPROM at
> runtime.  The FPGA DDR2 memory system is a lot less bulletproof than
> the average motherboard, so it needs to be heavily tested with a
> specific DIMM.

Hi, Theo.

Two questions, born from ignorance:

 1) Can the FPGA read values from an EEPROM-or-alike?

 2) If this is not an OTP situation, if the FPGA gets loaded at "boot
    time" ( whatever that means in your situation ) could you replace
    the image when you replace the DIMMs?

Jes' asking...


Frank
-- 
  With fashionable subjects like physics or astronomy the corres-
  pondence between model and reality is so exact that some people tend
  to regard Nature as a sort of Divine Mathematician.  However
  attractive this doctrine may be to earthly mathematicians, there are
  some phenomena where it is wise to use mathematical analogies with
  great caution.  The way of an eagle in the air; the way of a serpent
  upon a rock; the way of a ship in the midst of the sea and the way
  of a man with a maid are difficult to predict analytically.  One
  does wonder sometimes how mathematicians ever manage to get married.
      -- J. E. Gordon / "Structures, or Why things don't fall down"
-- 
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney aatt mindspring ddoott com

Theo Markettos <theom+news@chiark.greenend.org.uk> writes:

> David Brown <david@westcontrol.removethisbit.com> wrote:
>> I agree with other posters' suggestions to get a better DDR2 controller 
>> in your FPGA.
>
> That's a bit difficult.  The FPGA vendor's IP doesn't support that, and I
> just looked at another major FPGA vendor and I don't think their IP supports
> it either.  Using third-party IP is likely beyond the budget, and volumes
> are small enough that we're looking at a 'lifetime buy', because the next
> release we'll probably change to a new FPGA with DDR3 anyway.  The board
> isn't ours either, so the only option for using known chips is making our
> own DIMMs - which seems rather pointless (and risky).
>
>> But there is also a simpler method.  DDR timings are always a range - 
>> there is a minimum and a maximum clock speed, CAS delay, etc.  Figure 
>> out the slowest speed that most DIMMs support, and use that.  Then it 
>> doesn't matter if the actual DIMMs can run faster.
>
> Interesting idea... I'll have a look.  I suspect it will be tricky, given
> the setup takes about 100 parameters, and getting DDR2 to behave reliably on
> a completely custom setup is enough of a problem...

I have found with most memory parts the "replacements" tend to be faster
anyway (process shrinks I guess). So this seems like a good idea.

-- 

John Devereux

On 11/22/2012 6:57 PM, mike wrote:
>
> Bottom line...
> If you can't reasonably assure yourself of compatible component supply
> over the life of the product, you're asking for BIG trouble. Murhpy
> reads the newsgroups, so he's already got your number.

LOL!

Rick

On 11/23/2012 8:30 AM, Stef wrote:
> In comp.arch.embedded,
> David Brown<david@westcontrol.removethisbit.com>  wrote:
>>>
>>
>> I agree with other posters' suggestions to get a better DDR2 controller
>> in your FPGA.
>>
>> But there is also a simpler method.  DDR timings are always a range -
>> there is a minimum and a maximum clock speed, CAS delay, etc.  Figure
>> out the slowest speed that most DIMMs support, and use that.  Then it
>> doesn't matter if the actual DIMMs can run faster.
>
> That will work for the clock speed, but not for the CAS Latency, that
> is an exact number of clock cycles. So if you make sure you only use
> modules with the same CL, this may work. But higher speed modules often
> have higher CL, just to allow them to internally get the data.
>

No, CAS latency is a range, well, 2 or 3, depending on the chip and your 
timing, but *you* program it into the chip at boot up.  At least the 
chips I've read the data sheet for let you select the latency. 
Typically they run at CAS2 for slower speeds, but to get the max speed 
you have to drop back to CAS3.  Of course there may be chips that won't 
do anything but CAS3, but the point is that there is a bit in the set up 
to control that.

Am I wrong about this?

Rick