What exactly is cpu skew

Originally Posted by mikeyakame

Well let me try and explain it easiest I can.

You have clock signals for each device on the bus, ie CPU, MCH, DRAM, GPU, SMBUS, CMOS, etc.

All the clock signals are driven from the Host Bus BCLK (base clock) and such it is used as a reference point.

Hardware such as CPU, Northbridge, Southbridge, etc all reference Host BCLK to drive their own internal clock signals. They sample certain reference points and values to best ascertain when they need to drive their own clock waves, and when they need to initiate both address and data strobes to communicate across the Host Bus. It's all about timing.

Now as the electrical traces between say CPU and Northbridge are a reasonable length, the data sent from Northbridge to CPU for example won't arrive instantaneously, it will arrive fractions of a nanosecond after it was sent which is picoseconds or PS. Now Intel gives out electrical design specs, and vendors are meant to follow them.

Within specification of the design we might know that minimum transit time will be 150ps when sending any data from MCH(NB) to CPU, so we compensate for the transit time by driving the CPU clock signal 150ps after the Host Bus BCLK voltage crossing point.

This is called skewing clocks. It's just using known data and making compensation adjustments to make sure that critical specs are within tolerance, and that commuincations between external devices on the common bus flow without incidence or get lost in transit.

The default skews are fine within AGTL+ FSB spec. Problem is AGTL+ (advanced gunning transceiver logic) has a design limitation of 400mhz BCLK (400mhz fsb) and past this it is impossible to keep within original spec and guarantee 100% reliable operation. The faster a clock frequency becomes, the smaller clock periods become. Now there is still minimum tolerances that have to be met, whether running 200Mhz FSB or 600Mhz FSB, and this is the kicker...the most critical tolerance called "Period Stability" which is basically the farthest apart two succesive clock signals are allowed to be before the system will hard lock. So whether you run 200 or 600, the Period Stability value, <= 150PS, still comes to play.

To give you an idea.

533Mhz FSB has a clock period of 1.86ns (1860ps)

466Mhz FSB has a clock period of 2.14ns (2140ps)

400Mhz FSB has a clock period of 2.5ns (2500ps)

333Mhz FSB has a clock period of 3.0ns (3000ps)

As clock period gets smaller with FSB frequency increase, the critical stability values don't change and become extremely problematic. You are trying to meet criteria designed around having two times as much time between successive clocks, with successive clocks being driven at double the speed. We've got alot less room for error or instability, so much so that even slight variations will crash or destabilize our system at least with default clock skews designed to be effective upto 400Mhz FSB, not taking into account vendor board design flaws, mass manufacturing variances, and so on.

So this brings me to where the money is

Intel realised this problem and of course secretly had a means of making post-manufacturing compensation through NB registers. So What are CPU and NB Clock Skew values you ask...

They are simply delay values that can be wound in on top of the skew values in the design. As we raise voltages and frequencies we get whats called Clock Jitter, it gets worse the farther you go beyond the electrical design limits of your particular board, also if your PSU can't keep up, and many other reasons. Clock jitter results in unstable clock signals, It could be as little as 50ps jitter, which means that when the clock signal is driven there is a 50ps max deviation from one driven clock wave to a successive clock wave or even between one driven many clock periods apart. It's just inconstent deviation, that's why its a huge problem. It may never deviate to the point it begins to destabilize things except once every 20 minutes or 2 hours. It may deviate farther than normal occasionally and this phenomenon if the system is idle probably won't be noticed, but if its under heavy load it may show up as a glitch, a pause, a brief hang, a random BSOD, or worst usually is a full hard system lock.

Now what the NB and CPU Clock Skew settings in bios are, is a means to manually compensate through "trial and error" for the most part since none of us own high priced Logic Analyzers to calculate these values with maths! by farther delaying when a clock is driven at the NB or CPU or even DRAM (we advance dram clocks sometimes depending on memory sticks to compensate for very short MCH read delay turnarounds and to obtain data validity), we can take into account the deviations from clock jitter and more importantly timing resolution (which is probably 50ps or so on the MCH, its too coarse for extremely high fsb but we can compensate with a combination of GTL References, Vtt, Vnb, Vcc, Clock Skews and other things) by eye and feel and response. It's no science it's a black art.

It takes time to get used to your particular hardware, and pay attention to the small details...how long it takes to POST, miniscule delays between BIOS POST codes on the LCD Poster, changes in OS response, even setup options being sluggish to select. There are so many things you can pick up on that believe it or not happen because of clock jitter and deviations. There will be FSB frequencies where you can have the bios and system tuned to respond amazingly fast, and others where no matter how hard you try the system is hit and miss. When this happens just go up or down a few mhz on FSB and try again, you might find a frequency that works better for your settings. Like I said up or down doesn't matter, BCLK drives FSB and its too high of a reference clock frequency so even going +-1mhz sometimes can completely destabilize settings you worked on for days to get right. Keep that in mind.

Originally Posted by mikeyakame

I havent found I needed to use any NB Skew except when I was playing around 1N command rate at DDR2-1066, 100ps NB, 200ps CPU made the most difference.

Otherwise CPU 100ps NB Normal should be pretty safe.

CPU being farther from the MCH/NB means it is more prone to clock drive deviation. FSB is driven right off BCLK so unless clock jitter directly created as a result of NB Voltage there shouldn't be much need to skew the NB clock unless it's for the purpose of aligning all the clocks with the IOH if its deskewed too much

There are 4 important Clock domains to consider.

CPU Clock, MCH clock, DRAM clock, IOH clock.

IOH (SB) has a few land pins which reference/sample directly from the CPU, so corrections to IOH Clock Drive skew are possibly made based on CPU Clock Drive skewing. I don't know for sure, but being so far away on the board it would make sense to reference the farthest Clock Domain to help out with strobe timing.

Host FSB BCLK is driven from the Analog PLL Clock Generator. This is located right below the Northbridge chip.

CPU Clock Drive is referenced from Host FSB BCLK.

MCH(NB) Clock Drive is referenced from Host FSB BCLK.

IOH Clock Drive is referenced from both Host FSB BCLK and CPU Clock.

DRAM Clock Drive is referenced from MCH Clock from what I can tell, since MCH is DRAM Controller and MCH is responsible for Read Delay timing during Cross Clocking Procedure.

Read Delay is the necessary turnaround between MCH request DRAM READ on one differential clock falling edge (ie low clock#), then a CPU requested FSB READ on the following differential clock falling edge (ie high clock). This is a procedure that has no direct handshaking between either end, rather relies on MCH reading data from DRAM, burst reading it onto the FSB host bus, then the CPU doing a blind read exactly half a clock period later whether data is there or not.





FSB BCLK sampling is done closest to NB, so NB Clock Skew will be the most resistant to deviation, and so far it seems from the responses of a few guys who are using same as me, CPU 100ps/NB 0s that this is very true. If I delay NB 100ps without delaying CPU 100ps more, and advancing DRAM CLK skew by 100-150ps, then I will get near instant BSOD's and pretty unstable operation even to then.

If your board needs it then thats ok, but unless you are using over 500mhz FSB and even more theres a good chance you probably should be safe with Normal NB Clock Skew.

100ps is a lot so unless the clock jitter is causing a deviation of more than half that amount (50ps), then don't worry. 100ps at 500mhz fsb is 1/20 clock period. It's quite a big amount and if its too much you'll end up more than likely corrupting CMOS or system files.

First thing I did was try different NB Clock Skew values on my board, and any more than 100ps and every time it resulted in no more CMOS data Had to redo all settings each POST, because they would completely vanish. NB Clock Skew is dangerous so believe me when I say if you don't need to change it then don't. It's only if you are pushing some heavy Vnb that it will show some serious benefits vs the risk of too much delay skew.

8GB Ram , 1.51-1.55v+ Vnb or Command Rate 1N + High DDR freq are the only cases I can think of which may need extra NB Clock Skew.

Edit:

Let me add one final concept to this post.

If you are highly experienced with fine tuning the bios settings and have a good understanding of the AGTL+ FSB design concept and how the CPU<->MCH<->DRAM procedure works at a low level, and you don't mind nuking a few OS installs in the process, then the following might interest you

With the precise balance of CPU Clock Skew, NB Clock Skew, PL phase pull-ins, GTL Refs, DRAM CTL Ref, DRAM secondary/tertiary timings and Vnb you can further tighten Performance Level beyond the point that is unpostable

Thats the key to tightening PL beyond the physical divider limit you reach in most conditions. Ie if PL=7 is limit for 12:10 divider at 500FSB, then PL=6 and even tighter is possible if you can balance the whole system on a pin, ie the timing of all strobes from end to end is near PERFECTION! :up:

it's possible without a multi channel oscilloscope / logic analyzer, though you'd need a lot of patience,a good spare week or two to get it right, and a good OS ghost image to restore everytime you nuke it from being slightly wrong. :up: :up:

Originally Posted by SpcCdr

Damn, I must be slipping tonight- (second thread I got beat to the exact same info I was off retrieving!
:swearing:
Curses and zounds!!!
Though, I don't mind so much getting PWN'd by the infomaster himself!
Hi E!
Cheers

*Note to self* *must combine XS and OCN Bookmark folders for quicker postage LOL*