EmbeddedRelated.com
Forums

Purchasing memory DIMMs for embedded projects

Started by Theo Markettos November 22, 2012
On 11/23/2012 8:54 AM, Theo Markettos wrote:
> 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
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
On 24/11/12 02:34, rickman wrote:
> 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? >
You are right as far as I know. David
On 24/11/12 02:37, rickman wrote:
> On 11/23/2012 8:54 AM, Theo Markettos wrote: >> 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 > > 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. >
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.
In comp.arch.embedded,
rickman <gnuarm@gmail.com> wrote:
> 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?
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??