classic Spartan-3 DDR2 and IOBs

Hello! I'm a bit ambitious (crazy?) and trying to get a Spartan-3
design talking to a set of DDR2 ICs. I'm exploring my termination
options, and I've seen the following:

1. The Spartan-3AN Starter kit terminates all of the DDR2 signals by
pulling them to 0.9V through a 50-ohm resistor.  The Spartan-3{A, AN,
E} series lack DCI on their IOBs.

2. The Spartan-3 (classic) datasheet shows that the part supports the
SSTL18_I_DCI IO standard, but sets the output impedance of the driver
to be 25 ohms (whereas everyone else seems to be using 50 ohms)

3. I've seen lots of comments suggesting I avoid using DCI in general,
as "it doesn't work" and "it's a power-hog".

So what are people's recommendations with respect to this particular
interface? I'd love to avoid having to manually place termination
resistors everywhere on my PCB, but if DCI doesn't work or if it's
going to conflict with the expected input impedance of my DDR2 ICs, I
may have no other option.

Thanks for any help or insight you can provide, DDR2 on S-3 (classic)
seems to be a bit of a no-mans land.

     ...Eric

On Oct 28, 1:26=A0pm, Eric <jo...@mit.edu> wrote:
> Hello! I'm a bit ambitious (crazy?) and trying to get a Spartan-3
> design talking to a set of DDR2 ICs. I'm exploring my termination
> options, and I've seen the following:
>
> 1. The Spartan-3AN Starter kit terminates all of the DDR2 signals by
> pulling them to 0.9V through a 50-ohm resistor. =A0The Spartan-3{A, AN,
> E} series lack DCI on their IOBs.
>
> 2. The Spartan-3 (classic) datasheet shows that the part supports the
> SSTL18_I_DCI IO standard, but sets the output impedance of the driver
> to be 25 ohms (whereas everyone else seems to be using 50 ohms)
>
> 3. I've seen lots of comments suggesting I avoid using DCI in general,
> as "it doesn't work" and "it's a power-hog".
>
> So what are people's recommendations with respect to this particular
> interface? I'd love to avoid having to manually place termination
> resistors everywhere on my PCB, but if DCI doesn't work or if it's
> going to conflict with the expected input impedance of my DDR2 ICs, I
> may have no other option.
>
> Thanks for any help or insight you can provide, DDR2 on S-3 (classic)
> seems to be a bit of a no-mans land.
>
> =A0 =A0 =A0...Eric

Hi Eric,

This is indeed a tricky area. I've implemented an S3 talking to DDR2
components myself, and termination gave us loads of headaches.
First of all, what frequency are you trying to run at? I assume it's
somewhere around 133MHz, which is pretty slow by DDR2 standards and
you therefore you can ignore all of the dire warnings you see in
datasheets about correct termination being mandatory (assuming your
trace lengths aren't too long).

DCI is a power-hog, but only when you use standards that have parallel
termination. In this case the DCI comprise a "Thevenin equivalent"
200R accross the 1V8 supply for each IOB which can add up to a lot of
power dissipation. For series termination such as SSTL18_I_DCI the
series resistor adds little to the power consumption.
Therefore, for address and control signals I would recommend you use
SSTL18_I_DCI at the FPGA and termination to Vtt at the memory end. You
could probably also just use SSTL18_I at these speeds without any
problems.

For the DQ/DQS signals I would use SSTL_18_II with an external 50R to
Vtt at the FPGA end, this needs to be fairly close to the FPGA pin,
but again at these frequencies it isn't that critical. At the memory
end use the ODT feature and save yourselves loads of termination
resistors.

HTH,
Rob

> Hi Eric,
>
> This is indeed a tricky area. I've implemented an S3 talking to DDR2
> components myself, and termination gave us loads of headaches.
> First of all, what frequency are you trying to run at? I assume it's
> somewhere around 133MHz, which is pretty slow by DDR2 standards and
> you therefore you can ignore all of the dire warnings you see in
> datasheets about correct termination being mandatory (assuming your
> trace lengths aren't too long).
>
> DCI is a power-hog, but only when you use standards that have parallel
> termination. In this case the DCI comprise a "Thevenin equivalent"
> 200R accross the 1V8 supply for each IOB which can add up to a lot of
> power dissipation. For series termination such as SSTL18_I_DCI the
> series resistor adds little to the power consumption.
> Therefore, for address and control signals I would recommend you use
> SSTL18_I_DCI at the FPGA and termination to Vtt at the memory end. You
> could probably also just use SSTL18_I at these speeds without any
> problems.
>
> For the DQ/DQS signals I would use SSTL_18_II with an external 50R to
> Vtt at the FPGA end, this needs to be fairly close to the FPGA pin,
> but again at these frequencies it isn't that critical. At the memory
> end use the ODT feature and save yourselves loads of termination
> resistors.
>
> HTH,
> Rob

Rob,
   This is fantastic help, esp. since I just got quotes on IBIS
simulators that exceed my
 entire budget for this project. :) I'm shooting for somewhere between
125 MHz and 150 MHz
 for my clock, and plan on having a very simple, bursty interface.
I'm basically trying to clock this thing as slowly as I possibly can.
I am using a single DDR2
IC (16-bit wide) per interface which will be directly connected to the
FPGA as closely as possible.

For the control signals, you recommend SSTL18_I_DCI on the FPGA side
and a pull-up
to VTT on the DDR2 side.

You're then recommending using the SSTL_18_II IO standard for the DQ/
DQS signals on
the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just
using ODT on
the DDR2 side.

If I understand correctly we can't use ODT for the address/control
signals on the DDR2 side
because DDR2 only supports ODT on data-related signals.

For your interface, did you use the Xilinx Memory Interface generator,
or do your own interface
by hand? MIG tries to place what seem like significant restrictions on
pin location, as well
as being a bit too general-purpose for our applications, but I'm
guessing if there
are pin constraints there's a reason for it.

Also, may I ask how far away your DDR2 ICs were from your FPGA, and if
there was only
a single IC per interface or multiple ICs?


Thanks,
   ...Eric

"Eric" <jonas@mit.edu> wrote in message 
news:bbf396a8-4678-461d-90b8-e29b26b165c7@v13g2000pro.googlegroups.com...
>
> Rob,
>   This is fantastic help, esp. since I just got quotes on IBIS
> simulators that exceed my
> entire budget for this project. :) I'm shooting for somewhere between
> 125 MHz and 150 MHz
> for my clock, and plan on having a very simple, bursty interface.
> I'm basically trying to clock this thing as slowly as I possibly can.
> I am using a single DDR2
> IC (16-bit wide) per interface which will be directly connected to the
> FPGA as closely as possible.
>
> For the control signals, you recommend SSTL18_I_DCI on the FPGA side
> and a pull-up
> to VTT on the DDR2 side.
>
> You're then recommending using the SSTL_18_II IO standard for the DQ/
> DQS signals on
> the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just
> using ODT on
> the DDR2 side.
>
> If I understand correctly we can't use ODT for the address/control
> signals on the DDR2 side
> because DDR2 only supports ODT on data-related signals.
>
> For your interface, did you use the Xilinx Memory Interface generator,
> or do your own interface
> by hand? MIG tries to place what seem like significant restrictions on
> pin location, as well
> as being a bit too general-purpose for our applications, but I'm
> guessing if there
> are pin constraints there's a reason for it.
>
> Also, may I ask how far away your DDR2 ICs were from your FPGA, and if
> there was only
> a single IC per interface or multiple ICs?
>
>
> Thanks,
>   ...Eric
>
Eric

Have you looked into running slower than 125 mhz (with the dll disabled)?  I 
want to do this, at probably around 33mhz, but I'm having trouble getting 
any information about it:  namely can I do it and will it work?  Just 
wondering if you knew anything about that.

Dan 

On Fri, 31 Oct 2008 11:12:50 -0600, "Dan Kuechle" <danielgk@visi.com>
wrote:


>
>Have you looked into running slower than 125 mhz (with the dll disabled)?  I 
>want to do this, at probably around 33mhz, but I'm having trouble getting 
>any information about it:  namely can I do it and will it work?  Just 
>wondering if you knew anything about that.

Check a DDR2 memory datasheet for its minimum operating frequency. May
be 83 or 125 MHz (I can't remember offhand); set by the internal DLL
delay length used to generate signal timings. 

It is possible to turn the DLL off (with a mode register setting) - that
may allow operation at lower speeds, but you're operating outside the
datasheet and you'd beon your own as far as timings go.

- Brian

"Dan Kuechle" <danielgk@visi.com> wrote:

>
>"Eric" <jonas@mit.edu> wrote in message 
>news:bbf396a8-4678-461d-90b8-e29b26b165c7@v13g2000pro.googlegroups.com...
>>
>> Rob,
>>   This is fantastic help, esp. since I just got quotes on IBIS
>> simulators that exceed my
>> entire budget for this project. :) I'm shooting for somewhere between
>> 125 MHz and 150 MHz
>> for my clock, and plan on having a very simple, bursty interface.
>> I'm basically trying to clock this thing as slowly as I possibly can.
>> I am using a single DDR2
>> IC (16-bit wide) per interface which will be directly connected to the
>> FPGA as closely as possible.
>>
>> For the control signals, you recommend SSTL18_I_DCI on the FPGA side
>> and a pull-up
>> to VTT on the DDR2 side.
>>
>> You're then recommending using the SSTL_18_II IO standard for the DQ/
>> DQS signals on
>> the FPGA side, with a 50 ohm pullup to VTT at the fpga side and just
>> using ODT on
>> the DDR2 side.
>>
>> If I understand correctly we can't use ODT for the address/control
>> signals on the DDR2 side
>> because DDR2 only supports ODT on data-related signals.

You won't need ODT because you can run the address/control signal at
half the memory frequency. You may even get away with LVCMOS signals
with lower drive strenghts to reduce power even more.

>> For your interface, did you use the Xilinx Memory Interface generator,
>> or do your own interface
>> by hand? MIG tries to place what seem like significant restrictions on
>> pin location, as well
>> as being a bit too general-purpose for our applications, but I'm
>> guessing if there
>> are pin constraints there's a reason for it.

Be aware that the MIG tool tries to get the maximum speed from the
FPGA for marketing purposes. If you roll your own interface and aim at
a lower frequency, the pin restrictions vanish and the complexity of
the interface is greatly reduced.

>Have you looked into running slower than 125 mhz (with the dll disabled)?  I 
>want to do this, at probably around 33mhz, but I'm having trouble getting 
>any information about it:  namely can I do it and will it work?  Just 
>wondering if you knew anything about that.

The datasheet specifies a minimum operating frequency. But whats the
use of DDR2 when using it at lower speeds? Perhaps DDR or SDRAM is a
better choice in such situations.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

On Nov 2, 4:04=A0am, n...@puntnl.niks (Nico Coesel) wrote:

[snip]

> >Have you looked into running slower than 125 mhz (with the dll disabled)=
? =A0I
> >want to do this, at probably around 33mhz, but I'm having trouble gettin=
g
> >any information about it: =A0namely can I do it and will it work? =A0Jus=
t
> >wondering if you knew anything about that.
>
> The datasheet specifies a minimum operating frequency. But whats the
> use of DDR2 when using it at lower speeds? Perhaps DDR or SDRAM is a
> better choice in such situations.
>
> --
> Programmeren in Almere?
> E-mail naar nico@nctdevpuntnl (punt=3D.)

The best reason for DDR2 is small chip size, low price (sweet spot in
price per bit) and high bit density.  Single data rate chips are bulky
and
expensive if you want 1 Gbit or more (i.e. multiple chips vs 1 DDR2).
DDR 1 uses more power, can be even harder to use, and still has
a minimum operating frequency requirement.

That being said, if you don't need that much memory, a single-rate
mobile SDRAM or even DDR mobile SDRAM will reduce your
interface parts count.