[SI-LIST] Re: SSTL/DDR series termination

It's difficult to tell whether the interface violates the spec without
seeing the waveforms. In SSTL2, for example, the maximum swing is specified
as 2.5V but an additional 1.2V is allowed for overshoot in both rising and
falling edges of strobe and data signals as long as it's momentary and ramps
down within a certain amount of time. I have yet to see the SSTL18 standard
before making any comment but guessing similar requirements the
compatibility of waveforms must be evaluated with that in mind.
I understand your desire to eliminate Vtt by not using any pull-ups there
but you may have more control on the voltage waveform with pull-ups than the
series terminations alone. Besides, I'd be more worried for the read case
where strong memory buffers drive the bus than the controller FPGA where
you'll probably have more flexibility with proper slew rate and drive
strength selection. As generic IC makers, the memory designers have to
address a broad user spectrum where their devices may have to drive several
loads. For point-to-point interfaces, their devices usually become too
strong. Some of them have configurable internal terminations but since you
don't mention it I gather yours is not in that class. In the end, even if
you opt to use a series termination you may want to revise your decision
about where to place them after the simulation results...

Regards.

Ihsan Erdin
Nortel




On 10/21/05, Brad5m@xxxxxxx <Brad5m@xxxxxxx> wrote:
>
> Hi all -
>
> This is my first time here -- please be gentle, and thanks for your help!
>
> I'm doing a design using a single 512Mb DDR2 attached to an FPGA and I'm
> entertaining the use of series termination for at least some of the
> interface
> between them, but still trying to convince myself that it will all work
> OK. The
> major impetus in using series term is that I could potentially entirely
> lose
> the Vtt supply, which would be highly desirable. The only thing *more*
> desirable is that it all works when I'm done.
>
> The scheme is as follows:
> -point-to-point connection between FPGA and DDR2
> -trace lengths in the .75-1.25" range (a guess)
> 1) The unidirectional signals (e.g., address) from FPGA to DDR2 will be
> "series terminated" by judicious setting of the FPGA output drive.
> 2) Same for the bidirectional signals (e.g., data) when driven by the
> FPGA.
> 3) My 1st choice for managing the DDR=>FPGA data direction would be to
> select a trace impedance that works well with one of the two available
> DDR2 drive
> strengths (maybe 75 ohms/reduced drive?). If that doesn't work, I could
> presumably use resistors by the DDR to series terminate the "read"
> direction.
>
> I have simulated the FPAG=>DDR2 direction, and with appropriate output
> current settings on the FPGA it seems to look fine. It looks pretty much
> just like
> the parallel terminated (50-Vtt) case, only it has more amplitude. I
> haven't
> done the other direction yet (IBIS problem), but don't expect it to be
> *too*
> different since it is also an SSTL18 driver.
>
> The SSTL18 and DDR2 JEDEC specs contain a receiver parameter "Vswing(max)"
> that appears to say that signal amplitude must be no greater than 1Vpp. If
> I am
> reading that correctly, then it would appear that my series termination
> scheme would violate the specs as it would generate > 1Vpp signals. Am I
> reading
> this correctly??
>
> So my questions are:
> 1) Any comments on Vswing(max)? Does it preclude the use of series
> termination alone, or am I somehow reading it wrong? Any ideas of the
> risks if I
> ignore it??
> 2) Anyone else out there already done what I'm attempting to do here, and
> want to tell me about it? I am especially interested in hearing comments
> such as
> "don't even think about it" or "no problem" -- but only if they're true!
> 3) Any other comments/potential gotchas/etc.?
>
> The goal here, as always, is to have the simplest design possible, but no
> simpler.
> Thanking the DDR2/SSTL/SI experts in advance ...
> Brad Cook
> 5M Consulting
> Ann Arbor, MI
>
>
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from si-list:
> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
> or to administer your membership from a web page, go to:
> http://www.freelists.org/webpage/si-list
>
> For help:
> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
> List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
> List technical documents are available at:
> http://www.si-list.org
>
> List archives are viewable at:
> http://www.freelists.org/archives/si-list
> or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
> Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
>
>


--
Regards
Ihsan

------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field

List FAQ wiki page is located at:
                http://si-list.org/wiki/wiki.pl?Si-List_FAQ

List technical documents are available at:
                http://www.si-list.org

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu

Other related posts: