[SI-LIST] Re: Planar DDR and LVTTL I/O
- From: Mike Brown <bmgman@xxxxxxxxxx>
- Date: Tue, 01 Oct 2002 23:09:14 -0500
Robert,
I was advised many years ago to "Fire the Engineer who is not cost
conscious". I was also advised - by the same man - to avoid the "Save
Money at Any Cost" trap. You seem to be cost conscious, but I'm not
sure where you are with the latter.
Jim brings up some valid points, below. DDR timing is not easy to make
work worst-case. Even at 100 MHz. Since signalling is
source-synchronous, skew must be managed carefully. It's amazing how
fast you can eat up a 3.5 ns or less stable data window. And that's all
you have to work with, worst case.
I would not say that you can't use LVCMOS in your application, but I'd
burn a lot of SPICE cycles before doing so; assuming that you can get
your vendor's IO SPICE models. However, the problem is more general
than just the IO cell type selection. You might first try doing a
timing budget with the available driver/receiver voltage and timing
specs to see just how much margin you might have, even before burning
the SPICE cycles. Don't forget to include signal risetimes, and rising
versus falling delays, in the analysis. When the thresholds have 1 volt
or so of uncertainty, it doesn't take much risetime degradation to
introduce considerable skew. You can minimize risetime degradation by
allowing the line to overshoot, but then you have to control the amount
of overshoot so that line settling doesn't get into the timing, or that
you don't latch something up. Also consider skews in on-chip
input/output wiring timing and clock skew for both the chip clock and
for the DQS distribution. Establish budgets for these things. That will
make you sensitive to the tradeoffs involved if some budget cannot be met.
Since things work off off both edges of DQS, duty cycle distortion (DCD)
is an issue. Most LVCMOS drivers and receivers are not well-specified
from that standpoint. LVCMOS drive strengths tend to be asymmetric, and
the receiver thresholds are usually specified 40% of VDD apart. Using
VREF receivers will minimize the receiver contribution to the DCD skew.
The threshold uncertainty window is Vref +- a couple hundred mv,
instead of the 40% spread .
DQ and DQS routing must be length-matched within a somewhat small
window. At least, it might be perceived as small by your layout shop,
if they aren't used to high-speed designs. You will have to determine
how small it has to be from your timing analysis. This true even with
SSTL2 IO.
The DQS-DQ relationship is fairly well controlled by the JEDEC DDR spec
JESD79 - within a single DDR RAM. It is much less so across multiple
RAMs. Your single-chip design doesn't have that issue.
A parting question for you - How much would you pay for an insurance
policy against a delayed delivery of your product? By the time you prove
that LVCMOS would work, you can have a great deal of progress made on
the rest of the chip design if you select SSTL2. You are still going to
need to do the timing analysis, but you can start with a high degree of
assurance that the results will be positive, or at least that the
required tweaks will be small. "No design iterations" is generally a
valuable thing.
That's more than I intended to write when I sat down at the keyboard.
Hope it is useful to you.
Regards
Mike
jim freeman wrote:
>Hi Robert,
> A vref for the input buffers may be essential. The duty cycle variation
>for the output of the input buffer may be too great to run at greater than
>100Mhz clock frequency. There are also duty cycle variations for the clock
>driver that are quite stringent. I asume that your bus width is wide enough
>to require more than one memory chip. If you are able to use only one memory
>chip, the skew between the dqs and the data may be intolerable for the ASIC
>controller.
>
>Thanks
>Jim Freeman
>
>Robert Lindsell wrote:
>
>>Hello si-listers,
>>
>>Does anyone know if it's possible to use 2.5V LVTTL/LVCMOS buffers with
>>a planar, point-to-point implementation of DDR (ie. no DIMMs, just one
>>DDR chip and an ASIC controller)
>>
>>Our ASIC library vendor wants $50k for SSTL-2 buffers, which seems a bit
>>extreme... but maybe it isn't????
>>
>>Any info and opinions welcome.
>>
>>Regards,
>>
>>Robert
>>
>>--
>>Robert Lindsell, Principal Hardware Engineer
>>Canon Information Systems Research Australia
>>PO Box 313 NORTH RYDE NSW 2113
>>mailto:robert.lindsell@xxxxxxxxxxxxxxxxxx
>>Fax: +61-2-9805-2929 Phone: +61-2-9805-2876
>>
>>------------------------------------------------------------------
>>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:
>>//www.freelists.org/webpage/si-list
>>
>>For help:
>>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>
>>List archives are viewable at:
>> //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
>>
>
>------------------------------------------------------------------
>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:
>//www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List archives are viewable at:
> //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
>
>
>
------------------------------------------------------------------
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:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List archives are viewable at:
//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:
