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??

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.

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

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

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

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

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