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