[SI-LIST] Re: DDR-Length matching
- From: "Cheng, Chris" <chris.cheng@xxxxxx>
- To: "Kinger.cai@xxxxxxxxx" <kinger.cai@xxxxxxxxx>, steve weir <weirsi@xxxxxxxxxx>
- Date: Tue, 3 May 2011 04:36:22 +0000
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
Other related posts:
