difference between net skew in the clock report and clock skew in trce log

Jan 30, 2008 3 Replies

Hi all,



I've something strange in my design... I think there is something I don't understand..



I've a clock distributed on a global clock network, It seems to be ok.. In the "Clock report" from the ISE PAR, I can read a "net skew" of



0.276ns and a max delay of 1.779ns (I'm using a virtex5 XC5VLX50). But when I use trce to look for timing violations, I found hold violations With a "data path delay" of 2.476, and my "max delay" for the clock ( 1.779ns ), it should work.. But trce reports a "positive clock path skew" equal to 6.898ns.. that's why I've some timing violations...

My question is, how can I've a "positive clock path skew" greater than the "max delay" from the clock report ? Is it a consequence of the clock fanout (374 ) ? Is it because my clock is used in different clock regions ?



Thanks for your answers,



Best Regards, Michel.


Is the clock multiplied or divided in a DCM? I have been somewhat confused by (e.g) 3.4 ns skews relative to a 2x clock output, being reported as a 6.8ns skew relative to the original clock...

- Brian

skew

First, thanks, but the clock is divided using a counter ( because frequency is too low for using DCM). The original source clock is 48MHz, and after counter, I obtain a 2MHz clock which is distributed accross the global clock network

Michel

Hi Michel, Don't do that. Use the 48MHz clock for clocking everything. Generate a clock enable signal that is high for one clock cycle out of 24. Use the clock enable for the FFs which you want to clock at 2MHz. HTH., Syms.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required