Cyclone II PLL Skew?

[Altera_Forum]

Hello, 

 How can i determine the max clock skew on an output pin on my Cyclone II? I would like to know if clock skew could be significant enough to warrant being part of the SDC constraints for a source-synchronous interface?   Also, I'm not using dedicated clock output for the clock (oversight in the board layout). How can i determine the max skew for a PLL clock output on a regular device I/O pin?  Thanks, /John.

[Altera_Forum]

As long as you have properly constrained the pin to be the clock for the source-synchronous interface, Quartus will take the skew into account. There is a free video tutorial on Altera's website about constraining source-synchronous interfaces. You should follow the guidelines indicated there. 

 Jake

[Altera_Forum]

Thanks Jake.

[Altera_Forum]

--- Quote Start ---  Also, I'm not using dedicated clock output for the clock (oversight in the board layout). How can i determine the max skew for a PLL clock output on a regular device I/O pin?  --- Quote End ---     It is generally better to drive a source synchronous output clock on a regular I/O pin using the same output-register setup as the output data than it is to drive the clock with a dedicated PLL output. Typically the clock is driven with DDIO registers in the I/O cell (can be as simple as tying one register input to a hard-wired high and the other to a hard-wired low unless you want to be able to stop the clock). For the least clock-to-data skew, the data is also driven by DDIO registers even if the data is single data rate (in that case connect the internal data signal to the inputs of both DDIO registers).  For HardCopy II, the clock output should be driven by a dedicated PLL output. For a Stratix II design that might go to HardCopy II, the clock can be driven by a dedicated PLL output that has DDIO registers available so that the FPGA drives the clock with the registers and the HardCopy device drives the clock with the PLL output directly with the same board layout for both devices.  Jitter will probably be less using the dedicated PLL output. I think I've seen a device handbook where the jitter was specified separately for a dedicated clock output and a regular I/O, and it was higher for the regular I/O. This is probably the case for Cyclone II.

[Altera_Forum]

Thanks Brad. I guess the jitter and skew is whatever it is at this point. I just wanted to find out how much it potentially is so i can take it into consideration in my SDC I/O constraints. Right now i'm ignoring it. 

 /John.

[Altera_Forum]

You can account for the jitter with set_clock_uncertainty if the Cyclone II handbook has a separate spec for output jitter when using an I/O pin. If it's not in the handbook, you'd have to guess how much clock uncertainty to add. I was probably looking at Cyclone III when I saw a separate spec in a handbook. If the Cyclone II handbook doesn't have the separate jitter specs, you could use the difference in jitters in the Cyclone III handbook for a rough guess for the Cyclone II difference. In Cyclone II, the guard bands in the timing model might be enough to cover the jitter for a dedicated clock output with no set_clock_uncertainty, but don't assume the guard bands cover the additional jitter for an I/O output. 

 As Jake said, Quartus accounts for the skew automatically, but you do have control over how much the skew is. Driving a clock output from a PLL to an I/O pin directly probably has more skew relative to the data outputs than you would have if you drove both clock and data outputs with I/O cell registers configured the same way. The PLL output would clock the I/O cell DDIO registers that have their data inputs hard wired to high and low. You use the same PLL output for data and clock registers if you don't need a phase shift and a separate PLL output for the clock registers if you do need a phase shift.

[Altera_Forum]

Thanks Brad.