Xilinx .002ns timing error

Hello group,

I am getting a strange timing error report with numerous requirements of .002ns with the same source and destination clock, and which inevitably fail.

This clock is from a dcm clkfx, if that matters.

What is going on here? And what is this program doing when it says rising at 29774.000ns? Is it running some sort of mini testbench?

Brad Smallridge brad at aivision dot com

Timing constraint: TS_top_layer_inst_cam2_dcm_inst_cam_dcm_inst_CLK0_BUF = PERIOD TIMEGRP

"top_layer_inst_cam2_dcm_inst_cam_dcm_inst_CLK0_BUF" TSCAM2 HIGH 50%;

1896 items analyzed, 37 timing errors detected. (37 setup errors, 0 hold errors) Minimum period is 44875.000ns.

-------------------------------------------------------------------------------- Slack: -3.588ns (requirement - (data path - clock path skew

  • uncertainty)) Source: top_layer_inst/cam2_iserdes_inst/cam_lval (FF) Destination: top_layer_inst/mid_layer_inst/cam2_col_5 (FF) Requirement: 0.002ns Data Path Delay: 3.530ns (Levels of Logic = 1) Clock Path Skew: 0.000ns Source Clock: top_layer_inst/cam2_clkdiv rising at 29774.998ns Destination Clock: top_layer_inst/cam2_clkdiv rising at 29775.000ns Clock Uncertainty: 0.060ns

Data Path: top_layer_inst/cam2_iserdes_inst/cam_lval to top_layer_inst/mid_layer_inst/cam2_col_5 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- SLICE_X48Y59.YQ Tcko 0.360 top_layer_inst/cam2_iserdes_inst/cam_lval top_layer_inst/cam2_iserdes_inst/cam_lval SLICE_X59Y62.F4 net (fanout=5) 0.914 top_layer_inst/cam2_iserdes_inst/cam_lval SLICE_X59Y62.X Tilo 0.194 top_layer_inst/mid_layer_inst/_n0042 top_layer_inst/mid_layer_inst/_n00421 SLICE_X66Y60.SR net (fanout=6) 0.905 top_layer_inst/mid_layer_inst/_n0042 SLICE_X66Y60.CLK Tsrck 1.157 top_layer_inst/mid_layer_inst/cam2_col top_layer_inst/mid_layer_inst/cam2_col_5 -------------------------------------------------

--------------------------- Total 3.530ns (1.711ns logic,

1.819ns route) (48.5% logic, 51.5% route)
Reply to
Brad Smallridge
Loading thread data ...

It does matter ;) The problem you're seeing maybe related to precision error when ISE computes the period.

Answer #20986 says it's fixed but maybe you've uncovered a place where it's not ...

Sylvain

Reply to
Sylvain Munaut

Humph. You're right. It appears it can't handle 7/2. Is there a work around?

Brad Smallridge brad at aivision dot com

Reply to
Brad Smallridge

How did you specify you period ?

I usually choose to specify it in ps, trying to get a number that leads to an integer number of ps for the FX period. For example, if you had 133 MHz as a constraint, use 7497 ps as a period ... 7497 / 7 * 2 = 2140 ps ...

Reply to
Sylvain Munaut

Brad, the work-around is to specify the period rather than the clock frequency. If there is a DCM involved make sure the period specified is divisible by the DCM input to output ratio too.

Reply to
Ray Andraka

That did it! Thank you, Sylvain.

#TIMESPEC "TSCAM2" = PERIOD "cam2_xclk" 40MHz HIGH 50 %; -- errors TIMESPEC "TSCAM2" = PERIOD "cam2_xclk" 24997ps HIGH 50 %;

Brad Smallridge aivision

Reply to
Brad Smallridge

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.