TIG on Xilinx Asynch FIFO?

I am having a hard time getting ISE/XST to ignore clock skew between two clock domains from an asychronous FIFO generated from CoreGen. Why is the tool not ignoring this automatically? Here is the error after Map:

================================================================================ Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB HIGH 50%;

1681 items analyzed, 26 timing errors detected. (26 setup errors, 0 hold errors) Minimum period is 3892.500ns.

-------------------------------------------------------------------------------- Slack: -1.036ns (requirement - (data path - clock path skew + uncertainty)) Source: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF) Destination: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF) Requirement: 0.002ns Data Path Delay: 1.038ns (Levels of Logic = 0) Clock Path Skew: 0.000ns Source Clock: fx_clk rising at 9607.498ns Destination Clock: CLK_OSC rising at 9607.500ns Clock Uncertainty: 0.000ns Timing Improvement Wizard Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tcko 0.568 fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 net (fanout=1) e 0.100 fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp Tdick 0.370 fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 ---------------------------- --------------------------- Total 1.038ns (0.938ns logic, 0.100ns route) (90.4% logic, 9.6% route)

I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns clock on the read port. I have a TIG setup as follows:

NET "CLK1_FB" TNM_NET = "CLK1_FB"; TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %; PIN "U0_DCM.CLK0" TNM = "DCM_CLK0"; PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX"; TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX" TIG; #Asynch FIFO clock domains

CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any ideas? I'm lost....

Thx,

-Brandon

Reply to
Brandon Jasionowski
Loading thread data ...

This is an issue with ISE that tries to be too smart about related clocks, i.e. clocks derived from the same source. I'm guessing that your two clocks are related via a DCM?

You can add a FROM TO style of timespec calling out the two clocks and give it a sufficiently large value that these cross-clock paths are essentially ignored.

something like (in the .ucf file): NET "fx_clk" TNM="FastFlops"; NET "CLK_OSC" TNM="SlowFlops"; TIMESPEC "TS_fastslow"=FROM "SlowFlops" TO "FastFlops" 15 ns;

Brand> I am having a hard time getting ISE/XST to ignore clock skew between

================================================================================

--------------------------------------------------------------------------------

Reply to
Gabor

Be careful with timespec like this, you may include a lot of paths that are important to you. I was never successful in fixing this problem and Xilinx was no help either.

================================================================================

--------------------------------------------------------------------------------

Reply to
Terry Brown

Correct. I'm using the CLK0 and CLKFX outputs from the same DCM. The prior is writing, the latter is reading from the asynch FIFO.

Oh well, this is a pa> This is an issue with ISE that tries to be too smart about related

================================================================================

--------------------------------------------------------------------------------

Reply to
Brandon Jasionowski

Brandon,

In addition to the From-To suggested by Gabor, you can also use the DATAPATHONLY keyword to keep the clock phase differences (which could vary from build to build depending upon your design) out of the calculation. Check out the Constraints Guide:

formatting link
for more information.

Best regards, Ryan Laity Xil> Correct. I'm using the CLK0 and CLKFX outputs from the same DCM. The

================================================================================

--------------------------------------------------------------------------------

Reply to
Ryan Laity

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.