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

Reply to
Theo Markettos
Loading thread data ...

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

Reply to
mike

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 
 Click to see the full signature
Reply to
Tim Wescott

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.

Reply to
David Brown

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. 
 Click to see the full signature
Reply to
Stef

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).

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

Reply to
Theo Markettos

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 
 Click to see the full signature
Reply to
Frnak McKenney

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
Reply to
John Devereux

LOL!

Rick

Reply to
rickman

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

Reply to
rickman

I haven't studied DDR2 heavily, but if it is anything like SD or DDR there are only a small number of parameters that actually vary much between "flavors" of the same generic spec. Mostly it is timing details. As others said, run slow and your design should work with them all.

Rick

Reply to
rickman

You are right as far as I know.

David

Reply to
David Brown

A lot of the timing details are only used for simulation or to check that the timing will work. You might be able to put in things like "chip select off to hi-Z output" delays into the the FPGA DDR model, but that is not something you control.

It would be worth the effort reading through the DDR controller manual section for some microcontroller that supports DDR2. This will give you a very good idea of what is actually important in the setup.

Reply to
David Brown

No, you're not. It's been a while I used DRAM, so forgot about the fact you can program the CL to anything the chip supports even though the computer shop markets it as 'CL6'. Just be carefull to pick a number that is supported by most chips.

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

How's it going in those MODULAR LOVE UNITS??
Reply to
Stef

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.