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

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.

Reply to
michel.talon
Loading thread data ...

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

Reply to
Brian Drummond

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

Reply to
michel.talon

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.

Reply to
Symon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.