[SI-LIST] Re: DDR-Length matching
- From: "Tom Dagostino" <tom@xxxxxxxxxxxxx>
- To: "'Moran, Brian P'" <brian.p.moran@xxxxxxxxx>, "'Dan Smith'" <Dan.Smith@xxxxxxxxx>, "'Cheng, Chris'" <chris.cheng@xxxxxx>, "'Kinger.cai@xxxxxxxxx'" <kinger.cai@xxxxxxxxx>, "'steve weir'" <weirsi@xxxxxxxxxx>
- Date: Tue, 3 May 2011 13:52:59 -0700
Brian
Thanks for the insight. But I've always wondered why these (suggested)
specs are in mils and not psec? We design by time not distance.
Tom Dagostino
Teraspeed Labs
9999 SW Wilshire St.
Suite 102
Portland, OR 97225
USA
503-430-1065 Cell
971-279-5325 Office
971-279-5326 FAX
tom@xxxxxxxxxxxxx
www.teraspeed.com
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Moran, Brian P
Sent: Tuesday, May 03, 2011 12:43 PM
To: Dan Smith; Cheng, Chris; Kinger.cai@xxxxxxxxx; steve weir
Cc: Loyer, Jeff; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR-Length matching
Hi All,
This was a good thread overall and as a guy that does at times write DDR
design guidelines I will take all those comments to heart. I'd would like to
add one more piece of insight. Its unfortunate but true that Design
Guidelines mean different things to different people. It is also true that
the objectives of authors are not always consistent with the needs of the
end user. In an ideal world a Design Guide would define the boundaries of
the solution space and provide maximum implementation flexibility to the end
user. That is what I would want if I were designing a platform.
On the otherhand, its also expected that Design Guidelines have been fully
vetted and validated. So there is also a competing need to restrict the
solution space to only that which has been built and validated. What
generally happens is the Design Guide defines a subset of the solution
space, which has been validated via various validation platforms.
Manufacturers such as Intel do extensive amounts of platform level
validation of not only the silicon, but also the platform reference design
and associated design guidelines, and provide turnkey platform solutions.
However, not all customers want turnkey solutions, and so we must also
provide implementation flexibility as well.
As someone mentioned, in some cases the design guide is closer to a written
description of a specific reference design, than a true solution space
definition. In market segments where the motherboard form factor and
placement is standardized this makes perfect sense. In market segments where
there is no such standard implementation a more generic and flexible
guideline is required. But there is a tradeoff involved. The less you stray
from the validated reference solution the less platform specific validation
is required. All our guidelines are validated via simulation of course, but
you are limited to a quantum number of actual hardware validation platform
configs. We prefer to limit the solution space defined in our design guides
to that which has been fully validated. This is why our design guidelines
can sometimes appear arbitrary of overly restrictive.
We try to provide for implementation flexibility, while also ensuring the
Design Guide does not extend into solution space which has not been fully
hardware validated. This is not done out of laziness, but rather out of an
abundance of caution. If you are willing to take ownership of that
validation you can often find solution space beyond the limits of our Design
Guide.
Brian Moran
Signaling Development Group
Client Platforms
Intel Corporation
-----Original Message-----
From: Dan Smith [mailto:Dan.Smith@xxxxxxxxx]
Sent: Monday, May 02, 2011 10:03 PM
To: Cheng, Chris; Kinger.cai@xxxxxxxxx; steve weir
Cc: Moran, Brian P; Loyer, Jeff; si-list@xxxxxxxxxxxxx
Subject: RE: [SI-LIST] Re: DDR-Length matching
As engineers we need to keep holding the vendor's feet to the fire. DDR
"rules" are usually hogwash as most typically they come from vendors that
regurgitate what they did on their EVAl boards. Hell, I even had a vendor
tell me once that "they don't recommend memory vendor-A but memory vendor-B"
I dove into this cause and at the end of the day it was because there EVAl
board had vendor-B.
That is absurd engineering!
There is nothing magical about DDR designs relative to timing (DDR2,
DDR3...). There is a flip flop on one side with a delay relationship
between the data out and the signal that is clocking it, and there is a
requirement needed at the far end with a setup and hold time relative to the
clocking signal and the data. This is HW engineering 101. Of course we
know SI can eat into timing as well and is easily simulated for a given
topology.
As much as it can be a struggle, force the chip vendors who make memory
controllers to provide this timing information for their chips (across their
transmission lines in their OWN package)! Think about it, any chip vendor
who does not know this information about their DDR delivery should get out
of the business! It then becomes a simple flip-flop timing math equation
across the medium of transition (PCB). That's just part of the up-front
engineering math.
Dan
"Make everything as simple as possible and no simpler" - Albert Einstein
-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx [mailto:si-list-bounce@xxxxxxxxxxxxx] On
Behalf Of Cheng, Chris
Sent: Monday, May 02, 2011 9:36 PM
To: Kinger.cai@xxxxxxxxx; steve weir
Cc: Moran, Brian P; Loyer, Jeff; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: DDR-Length matching
No, that's just the case when certain company not willing to admit their
common mode clock to q is out of spec by 50% and when confronted with
measured data their application engineer dig up ANY word in the spec that
doesn't match the actual design to run away from responsibility.
Don't bring me up on those package skew numbers that are in the 1ps-5ps
range in a DDR2 design that need to be matched. That's just nuts.
Chris Cheng
-----Original Message-----
From: Kinger.cai@xxxxxxxxx [mailto:kinger.cai@xxxxxxxxx]
Sent: Monday, May 02, 2011 9:14 PM
To: steve weir
Cc: Cheng, Chris; Moran, Brian P; Loyer, Jeff; si-list@xxxxxxxxxxxxx
Subject: Re: [SI-LIST] Re: DDR-Length matching
Chris's case might need a global length matching of the routing in both
package and on board, while the package routing length (or delay) table have
to be provided together with the design guideline.
Overall it is much easier to achieve a global length matching than local
length matching particularly for tight timing budget of higher DDR data
rate.
Thx,
Sent from kinger's iPhone
On May 2, 2011, at 8:23 PM, steve weir <weirsi@xxxxxxxxxx> wrote:
> Chris, I think the rules are well-intended, but as your story and
> Aubrey's story both point-out, that while these ideas are guidelines
> that can be useful in many situations in other situations they are
> counterproductive. Design guidelines and best practices should be
> clearly delineated from performance: specifications / requirements /
> rules. I ask that the people who sit on specification committees
> avoid assumptions as much as possible. Paraphrasing Bruce
> Archambeault: "We are engineers. We are supposed to think."
>
> Best Regards,
>
>
> Steve.
>
> On 5/2/2011 7:21 PM, Cheng, Chris wrote:
>> My concern is there are company out there who use these ridiculous
matching rules as a "get out of jail free card" when things doesn't work.
>> I have personally seen a certain design where the clock to q coming out
of the IC has clearly exceeded the maximum spec by the vendor by over a 1ns.
And yet when confronted with the problem, the application engineer pull out
the spec and claim because I exceeded the maximum length in design guide by
120mils, the part is no longer guarantee to work and it's my own fault. I am
lucky to still have my job but I have heard people losing their job on these
kind of bogus excuses.
>> The tin foil side of my brain thinks whoever wrote these rules knows how
ridiculous they are but keep it anyways just so if they run into real
problems they can hide behind them to blame their customers.
>>
>> Chris Cheng
>>
>>
>> -----Original Message-----
>> From: si-list-bounce@xxxxxxxxxxxxx
>> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Moran, Brian P
>> Sent: Thursday, April 28, 2011 10:09 AM
>> To: Loyer, Jeff; steve weir
>> Cc: si-list@xxxxxxxxxxxxx
>> Subject: [SI-LIST] Re: DDR-Length matching
>>
>> Hi All,
>> The tight +/-10 mil spec usually refers to matching within the DQS
>> pairs and in some cases between DQ and their respective DQS strobes.
>> +/-10 mils is reasonable for the diff pair matching, but perhaps a bit
tight for DQ to DQS. The tighter you match the better your margins.
>> Most designs have some margin to give, but on the other hand, once
>> you start matching traces you might as well match to the tightest
>> reasonable guideline. Why leave margin on the table. But you can do
>> the math as far as how much margin you give up by loosening the matching.
I agree its not a matter of pass/fail. Its more a matter of optimization.
>>
>> Note that most controllers provide timing control per byte lane, so
>> there is no need to length match across byte lanes. Individual byte
>> lanes themselves are usually matched to some relatively large window
>> around CLK length, similar to how CTRL, and CMD/ADR groups are length
>> matched. In Intel guidelines we generally recommend matching CTRL
>> groups and CMD/ADR groups for a given channel within the group to a
>> fairly tight guideline, but then allow the group length as a whole to be
matched to CLK using a more generous guideline. This then allows the CTRL or
CMD/ADR groups to be alighned to CLK using internal timing circuits.
>>
>>
>> Brian Moran
>> Signaling Development Group
>> Client Platforms
>> Intel Corporation
>>
>> -----Original Message-----
>> From: si-list-bounce@xxxxxxxxxxxxx
>> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of Loyer, Jeff
>> Sent: Thursday, April 28, 2011 9:16 AM
>> To: steve weir
>> Cc: si-list@xxxxxxxxxxxxx
>> Subject: [SI-LIST] Re: DDR-Length matching
>>
>> My apologies - I should not have used the word 'spec'. I was referring
to what are often called 'Design Guidelines'.
>>
>> For most accurate reading, replace 'spec.' w/ 'guideline'. I think the
terms 'specify' and 'specified' are ok.
>>
>> Jeff Loyer
>>
>>
>> -----Original Message-----
>> From: steve weir [mailto:weirsi@xxxxxxxxxx]
>> Sent: Thursday, April 28, 2011 9:00 AM
>> To: Loyer, Jeff
>> Cc: karthi keyan; si-list@xxxxxxxxxxxxx
>> Subject: Re: [SI-LIST] Re: DDR-Length matching
>>
>> For all you guys that sit on these committees, I recommend calling
>> these unnecessarily tight matches "Guidelines" and "Best Practices",
>> and restricting specifications to actual performance requirements.
>> This avoids building assumptions about tools and practices into
>> specifications, without losing the benefit of practical experience in
>> the guidelines.
>>
>> Steve.
>>
>> n 4/28/2011 8:25 AM, Loyer, Jeff wrote:
>>> +/-10 mils tolerance means that all signals in that group must be within
20 mils of each other.
>>> If your longest trace is 6.253", and your shortest is 6.234", you have
met the spec.
>>> If your longest trace is 6.253", and your shortest is 6.232", you fail
the spec.
>>>
>>> The spec. could call out '+/-10 mils' or 'within 20 mils', with the same
meaning.
>>>
>>> The '+/- 10 mils' verbiage is usually used to align with popular layout
tools' conventions, where you specify +/- xx mils of a defined target.
Finding that target is part of the process for your particular design.
>>>
>>> When they specify this kind of tolerance, they usually also insist on
routing on the same layer, so propagation velocity differences don't come
into play.
>>>
>>> This tight a tolerance (within 20 mils, or about 3-4ps) is usually
specified because experience has proven that it doesn't take CAD folks much
longer to meet a +/- 10 mil spec. than a +/- 100 mil spec., and we can
reduce the skew from routing to essentially zero.
>>>
>>> Jeff Loyer
>>>
>>> -----Original Message-----
>>> From: si-list-bounce@xxxxxxxxxxxxx
>>> [mailto:si-list-bounce@xxxxxxxxxxxxx] On Behalf Of karthi keyan
>>> Sent: Thursday, April 28, 2011 2:42 AM
>>> To: si-list@xxxxxxxxxxxxx
>>> Subject: [SI-LIST] DDR-Length matching
>>>
>>> Hi experts,
>>> I am working on boards having DDR interface. on layout we are
>>> following the below groupings& length matching
>>>
>>>
>>> Group1- Data signals,strobe,Mask with in group +/-10 mils tolerance
>>> Group2- Add/Ctrl/Cmd/Clk--with in group +/-10mils tolerance
>>>
>>> i am clear on groupings but on length matching i want to know
how
>>> to calculate the exact Min& max length matching tolerance .
>>>
>>> can you please let me clear on DDR length matching?
>>>
>>>
>>> Thanks,
>>> Karthikeyan
>>>
>>>
>>> ------------------------------------------------------------------
>>> 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 technical documents are available at:
>>> http://www.si-list.net
>>>
>>> List archives are viewable at:
>>> //www.freelists.org/archives/si-list
>>>
>>> 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 technical documents are available at:
>>> http://www.si-list.net
>>>
>>> List archives are viewable at:
>>> //www.freelists.org/archives/si-list
>>>
>>> Old (prior to June 6, 2001) list archives are viewable at:
>>> http://www.qsl.net/wb6tpu
>>>
>>>
>>>
>>
>
>
> --
> Steve Weir
> IPBLOX, LLC
> 150 N. Center St. #211
> Reno, NV 89501
> www.ipblox.com
>
> (775) 299-4236 Business
> (866) 675-4630 Toll-free
> (707) 780-1951 Fax
>
>
> ------------------------------------------------------------------
> 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 technical documents are available at:
> http://www.si-list.net
>
> List archives are viewable at:
> //www.freelists.org/archives/si-list
>
> 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 technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
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 technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
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 technical documents are available at:
http://www.si-list.net
List archives are viewable at:
//www.freelists.org/archives/si-list
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
