1. <object id="q5s5r"></object>

    2. <code id="q5s5r"><small id="q5s5r"></small></code>
      <code id="q5s5r"></code>

      <nav id="q5s5r"><video id="q5s5r"></video></nav>
      <big id="q5s5r"></big>

      DDR-Length matching

      来源:一博科技 时间:2015-10-27 类别:PCB设计文章
      DDR设计序列文章

      以下文章源自:[SI-LIST] 

      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

       Please help me on how to calculate the length matchingtolerance .

      Thanks,Rajesh

      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

      +/-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

      Since this is a DDR interface, the +/- 10 mils probably refers to the DQ length relative to the DQS.  This means the DQ can be routed 10 mils shorter than the DQS or 10 mils longer.  This seems to be a tight spec, more like what I'd see on a package and not a board.

      John Ellis
      Sr. Staff R&D Engineer


      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.

      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

      Jeff, thanks.  I just ask that people be very careful distinguishing requirements from guidelines and recommendations.  It's a huge waste of a design and verification teams' time if in their product circumstances they have to do something extraordinary to get 4ps of end to end skew when 20ps will do just fine because a well-intentioned guideline is misinterpreted as a performance specification.

      Steve.

      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
      Brian,


      If you are doing a design where you have real estate to spare, I don't disagree with what you have said.
      On the other hand, you asked why I might leave margin on the table.  I would ask you to consider the scenario where you working on a very small board and are cramped for space.  Would you still recommend the extra serpenting if it would cause you to add a pair of (you can't add just one) layers?

      Thanks,
      Aubrey Sparkman


      Hi Aubrey,

      Point well taken. A well optimized design would length match to the point where additional margin is no longer free for the taking. At that point, if margins are adequate for the design objectives you are done. I certainly would not advocate adding layers if the deisgn does not require.

      Brian Moran

      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

      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.

      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, kinger's

      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

      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

      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

      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

      Hi Tom,

      Yeah, that idea has been discussed. There are some constraints which are better defined in terms of ps than in mils. I think we will be pushed into a paradigm change eventually, but I'm not sure what the final solution will be. Up until now length has been a convenient single constraint variable for bounding SI, timing, xtalk, and loss. Assuming you know something about the PCB materials and stackup. However, in order to enable end users to make more fundamental platform level tradeoffs, you need to start defining those constraints individually. I think you will start seeing movement in that direction, but it is a true paradigm change for those writing the guidelines as well as those using the guidelines. I'd like to see us move in that direction as well.

      Brian Moran


      For my two cents, I like more specification of actual parameters and less cookbook.  I see nothing wrong with offering cookbook recipes that define a validated design space for specific applications.  I get real heart burn from those recipes getting treated as specifications.

      Steve.


      上一篇:PCB设计制造之工具列表下一篇:埋容的PCB设计与PI仿真-1

      文章标签

      案例分享 Cadence等长差分层叠设计串扰 串行 DDR | DDR3DFM 电阻电源Fly ByEMC反射高速板材 HDIIPC-D-356APCB设计误区PCB设计技巧 SERDES与CDR S参数 时序射频 拓扑和端接 微带线 信号传输 Allegro 17.2 小工具 阻抗


      线路板生产

      热门文章

      典型案例


      北京赛车软件手机版