POST A COMMENT

12 Comments

Back to Article

  • emboss - Thursday, May 29, 2008 - link

    Firstly, drift is quite different from jitter. Drift is a long-term (many cycle) change in the frequency, whereas jitter is cycle-to-cycle. In the frequency domain, drift is a change in the average, whereas jitter (called phase noise in this context) is spectral impurities.

    Also, clock skew is a complete different issue again. Clock skew is used to correct propagation time differences, usually due to unmatched trace lengths (though can also be used to solve setup time problems on heavily loaded buses).

    Finally, you're barking up the wrong tree with regards to the source of problems. Even the cheapest, nastiest, crystal you can get has insanely low intrinsic jitter. After all, it's essentially just a filter. The main source of jitter comes from the PLL. In a PC, the PLLs (including all the feedback loops) are entirely contained within an IC. There's not much a designer can do to improve the quality of the output besides simply using a better spec (and more expensive) chip. External (from the chip) power noise is a potential issue, but unless you're really trying to eliminate that last 1/10th of a cent SMT capacitor you run into limitations of the chip rather than anything you can fix.

    Not to mention there's at least one more PLL between the motherboard frequency synthesizer and memory that the designer has no control over.

    As an aside, thermal drift of a crystal actually makes things "better" from a stability point of view. At room temperature, most cheap crystals have a negative temperature coefficient - they'll slow down as the temperature increases. In any case, the variation over a realistic range is less than a few hundred ppm for even the cheapest crystals, so you're looking at a tiny fraction of a percent.
    Reply
  • Rajinder Gill - Thursday, May 29, 2008 - link

    'though there is more to overall quality than PPM alone - again we need to look towards device jitter to determine the real value of the device in question.'

    Both the oscillator and power supply to the PLL play a part in the level of jitter at the output of the PLL. Anything downstream from there is still subject to any inadequacy from the PLL chip as such. Trace length matching plays a huge role, but any imposed jitter from the PLL will still effect the level of DQS skew required one way or the other. Most of this will be covered in an upcoming article.

    regards
    Raja
    Reply
  • emboss - Thursday, May 29, 2008 - link

    [quote]Both the oscillator and power supply to the PLL play a part in the level of jitter at the output of the PLL.[/quote]

    While technically correct, you missed my point. In a system like that used on motherboards, where you have a fundamental mode driven crystal connected more or less directly to a clock synthesizer chip, essentially all of the phase noise comes from the implementation inside the chip itself. Unless you have severe routing constraints, the only thing you can do to improve jitter is to use a different clock synthesizer. Assuming that the designer didn't just do something silly like forgetting decoupling caps.

    In some cases, like NVidia chipsets, you can't even select the chip. You just drop a crystal down next to the northbridge and hope NV have done a good job.

    [quote]Anything downstream from there is still subject to any inadequacy from the PLL chip as such.[/quote]

    Absolutely. My point here was more that no matter how hard the motherboard designer works, nearly all of the source of jitter is outside their control: inside the frequency synthesizer or inside the northbridge.

    [quote]Trace length matching plays a huge role, but any imposed jitter from the PLL will still effect the level of DQS skew required one way or the other.[/quote]

    In the nicest possible way, I'd suggest talking a bit more with who you're getting this information from. Clock skew and jitter are quite different things. The amount of jitter has no effect on the amount of skew required, nor can you use skew to correct problems caused by excessive jitter. The only way the two interact is that jitter will reduce the range of skew that will work.

    DQS skew is needed to compensate for bus loading. Most of the time the chipset (automatic) deskewing works correctly, in which case the average DQS edge is positioned in the midde of the valid range. However, if the motherboard designer uses a non-standard layout for the lines and doesn't compensate for this in the BIOS, the chipset deskewing will not function ideally. Under sufficient bus load and with a high enough frequency, the automatically determined deskewing could end up outside the valid range.
    Reply
  • kjboughton - Thursday, May 29, 2008 - link

    We'd like to add that while the concepts of skew and jitter are quite different, when it comes to developing the cleanest possible signaling environment understanding how each interacts with the other can play a vital role in achieving this end. And while we believe we understand what you are getting at, we must completely reject the idea that clock skew and jitter have nothing to do with each other.

    For instance, you mentioned that DQS skew is needed to compensate for bus loading and that “most of the time” the chipset handles calibrating differential line timing automatically. True, except that when it comes to pushing a motherboard and/or memory system to its absolute limits we’re no longer playing in the realm of “most of the time.” Which I’m sure you already know.

    You bring up a good point though, and it’s absolutely spot-on. You said that “the only way the two interact is that jitter will reduce the range of skew that will work.” Our response: precisely. And anyone who understands and acknowledges this truth surely also understands the reasoning behind it. You can take this for what it is, or accept it for no reason other than the fact that the quality of the signaling eye becomes better (bigger), either way, the idea that less jitter means more margin is pretty undisputable. Not only have we experienced this first-hand by setting new Micron DDR3 clocking records, but we’ve also seen it in our ability to more widely vary individual memory channel skew settings without driving the system to instability. As you would probably expect, this additional margin can then be exploited, allowing complete system stability at never before seen memory speeds with comparatively low memory voltages.

    It’s obvious from your comments that you’re not the average reader. Well, we’re not average writers so we just please ask that you give us a chance to share our findings. All in due time… :)
    Reply
  • Toferman - Thursday, May 29, 2008 - link

    Indeed... great article, Thanks guys :) Reply
  • Rajinder Gill - Thursday, May 29, 2008 - link

    'DQS skew is needed to compensate for bus loading. Most of the time the chipset (automatic) deskewing works correctly, in which case the average DQS edge is positioned in the midde of the valid range. However, if the motherboard designer uses a non-standard layout for the lines and doesn't compensate for this in the BIOS, the chipset deskewing will not function ideally. Under sufficient bus load and with a high enough frequency, the automatically determined deskewing could end up outside the valid range.'

    Hi,
    We have more data on the effects of the modifications we made, it just has not been put out in this short blog. You are absolutely correct. The changes we made affected the tolerance of the board to bigger offsets than realized before the modifications. And also allowed a previous CAS 8 maximum of 2050Mhz to be extended out to 2160MHz fully stable.

    regards
    Raja


    Reply
  • emboss - Thursday, May 29, 2008 - link

    Hmm, sounds interesting. I'm curious now as to what changes you made :)

    Also, I'm sorry if I came across as a little aggressive in my previous posts. As someone who does electronic design, the marketing departments of motherboard manufacturers in particular really get on my nerves. They constantly misuse terminology and sometimes even flat-out lie to tech websites. The whole "digital PWM" and multi-rail PSUs are excellent examples of this.

    Most tech reporters are not EEs, they don't know about or understand eye diagrams or Thevenin termination, nor should they need to. They have to assume that the marketroids are explaining things correctly. This wouldn't be a problem, except that the companies take advantage of this trust and abuse it massively to promote their products. The websites then publish this, which makes it Right, and leads to confusion all round.

    With the misunderstanding in the blog post between jitter and skew it looked a lot like yet another one of these cases. I could just see reviews in the future criticizing another motherboard because it didn't use a "low jitter crystal".

    I hope the article doesn't disappoint.
    Reply
  • Rajinder Gill - Thursday, May 29, 2008 - link

    hi emboss,

    That's fine man. contact me on my email address directly if you wish to chat further.

    rajinder.gill@anandtech.com

    You are more than welcome, interesting discussion and some excellent insights from you.

    best regards
    Raja

    Reply
  • hydeprogrammer - Thursday, May 29, 2008 - link

    Does this mean I will finally get to see a guide that shows how to overclock a system using 8GB of RAM? I would like to see whether this is possible to do with certain chipsets, such as the p35, the x38, and the x48. If this is indeed possible, what are the basic requirements (chipset, power supply, etc) Or is this just not doable with DDR2 (i.e. required voltages are way too high?) I currently own 8GB of GSkill DDR2-8000, and it'd be great to see my memory modules compared in benchies to other modules as well as DDR3 modules. I currently own an MSI P35 Platinum. Reply
  • hydeprogrammer - Thursday, May 29, 2008 - link

    Read DDR2-8000 as DDR2-1000 :) Reply
  • MikeyJ79 - Thursday, May 29, 2008 - link

    I still own an old system (used infrequently) which uses an Intel AL440LX motherboard. The only way to overclock the system is to somehow manipulate the PLL; in my case, it is via software, namely softFSB. Sometimes I have noticed that the Windows clock would gradually fall out of sync when heavy loads were applied to the system for any great length of time. I have since assumed that this problem, albeit minor, was related to my overclocking (a no-brainer). Can anyone offer any additional insights into this phenomenon?

    BTW, as a result, my old Celeron 533 can run happily at 613 MHz (almost 640, which itself is limited by the PLL). (Oh joy!) :D
    Reply
  • george12 - Friday, January 09, 2009 - link

    http://www.blueunplugged.com/c.aspx?c=58151">http://www.blueunplugged.com/c.aspx?c=58151
    http://www.blueunplugged.com/c.aspx?c=53853">http://www.blueunplugged.com/c.aspx?c=53853
    http://www.blueunplugged.com/p.aspx?p=119250">http://www.blueunplugged.com/p.aspx?p=119250
    http://www.blueunplugged.com/p.aspx?p=122588">http://www.blueunplugged.com/p.aspx?p=122588
    http://www.blueunplugged.com/c.aspx?c=47031">http://www.blueunplugged.com/c.aspx?c=47031
    Reply

Log in

Don't have an account? Sign up now