UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer mflmfl
Observer
9,725 Views
Registered: ‎06-10-2011

False Timing Paths using FIFO to cross clock domains

Jump to solution

Using FIFO generator to allow data to cross from 1 clock domain to another.

Write Width is 64 and Read Width is 32. Independent clocks using block RAM radio button is checked.

When Implementing there's a timing path deep inside, the detail of which reveals both clocks are used to determine it.

How to suppress such paths?

0 Kudos
1 Solution

Accepted Solutions
Observer mflmfl
Observer
12,440 Views
Registered: ‎06-10-2011

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

Sure, to recap:

I've got a FIFO in my design that has two disparate clocks, they have no relationship to eachother and I don't want TRCE to time across the domains.

 

The Xilinx tools create a relationship between a clock on a pin and a clock that may have been generated from that clock by a DCM etc., and will therefore attempt to time paths that cross domains. In general this may be a good idea, but it's just  not when it comes to FIFOs with separate read and write ports where the whole point of using a FIFO in this way is to decouple clock domains in a nice way. So I'd call this a workaround, in this case I decouple the clocks in the ucf file with a  Timing Ignore (TIG)

 

Example:

Net "FrameClk" TNM_NET = "FRAME_CLK";
Net "Sout_clk" TNM_NET = "SOUT_CLK";
TIMESPEC "TS_XDOMAINS_WRTORD" = FROM "SOUT_CLK" TO "FRAME_CLK" TIG;
TIMESPEC "TS_XDOMAINS_RDTOWR" = FROM "FRAME_CLK" TO "SOUT_CLK" TIG;

 

Note the TIG in both directions, otherwise you'll be left with HOLD problems (or setup problems depending on which one you leave out). In the example FrameClk and Sout_clk are the clock names at my top level.

View solution in original post

0 Kudos
8 Replies
Professor
Professor
9,712 Views
Registered: ‎08-14-2007

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

The best way is to create FROM : TO style constraints between the clock domains.  Have a look at this

thread:

 

http://forums.xilinx.com/t5/Virtex-Family-FPGAs/Virtex-5-metastability-protection/m-p/196834#M12512

 

The "DATAPATHONLY" part of the constraint prevents hold time errors in the cross-clock-domain paths.

 

-- Gabor

-- Gabor
0 Kudos
Observer mflmfl
Observer
9,701 Views
Registered: ‎06-10-2011

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

These are independent domains defined in the IP itself. The paths are deep within the FIFO.

What I'm looking for is a way to say the write clock and the read clock are not associated. If I have to apply false timing paths to IP that I don't know much about I'd say this is badly broken. As an example here's a timing path:

 

From:

U_filter/U_fifo64_32_filter/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc_0

To:

U_filter/U_fifo64_32_filter/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc_asreg_0

 

Now everything there past the 2nd level (U_fifo64_32_filter) is not my stuff - is created by coregen. Attempting to even *find* all these paths is onerous.

 

So again the question is - how do I tell coregen FIFO generator not to time out across the write and read clock domains?

0 Kudos
Professor
Professor
9,696 Views
Registered: ‎08-14-2007

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

I don't know what you mean by "These are independent domains defined in the IP itself."

 

The clock domains are defined by the global clock nets.  If your FIFO has two clocks, presumably

you drive them from two clock nets.  If the two clocks are related (come from the same DCM

or PLL or are otherwise traceable back to the same clock input pin), then the timing analyzer

will try to meet setup and hold times between these clocks unless you tell it not to.  Even if

the clock domains are not related, the timing analyzer will check hold time for paths crossing

the clock domains.  This latter behavior is peculiar, but can be shut off with the DATAPATHONLY

constraints.

 

You don't need to trace the paths inside the FIFO.  The FROM : TO constraints are applied to

the clocks that you provide the FIFO.  My assumption was that other than the FIFO, you don't

have any cross-clock-domain paths on the same two clocks that require the timing analyzer

to check setup and hold timing, so making the constraint apply golbally to all paths going from

one clock to the other would make sense.  In the example from the other thread, the two

clocks named "sys_clk" and "clk_125" might correspond to the write and read clocks provided

to the FIFO.

 

-- Gabor

-- Gabor
Observer mflmfl
Observer
9,689 Views
Registered: ‎06-10-2011

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

My wording was poor.

 

You're correct, these 2 clocks are related as one is from an input clock and another is generated from that using a DCM.

 

I don't see how stretching the data path time will correct setup problems which is what I've got. I think in the link you gave they were having hold time problems and certainly loosening the period for the datapath will fix that. At least that's my understanding of the poorly named DATAPATHONLY keywork.

 

I think what I'd like to do is something like:

NET "U_filter/U_fifo64_32/wr_clk" TNM_NET = "FIFO_WR_CLK";
NET "U_filter/U_fifo64_32/rd_clk" TNM_NET = "FIFO_RD_CLK";
TIMESPEC "TS_XDOMAINS" = FROM "FIFO_WR_CLK" TO "FIFO_RD_CLK" TIG;

 

A timing ignore between these 2 clock domains. The syntax is eluding me however, getting a referred group or timespec is undefined message. If you have any idea how to do this pls clue me in. Thx

0 Kudos
Professor
Professor
9,686 Views
Registered: ‎08-14-2007

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

You need to trace the clock nets back to the highest level of the hierarchy in which they are defined.

The hierarchical net names of ports get replaced by the name of the net to which they are port-mapped.

The resulting netlist after synthesis therefore probably does not contain nets with the names you've

used.  You need to realize that the timing analyzer is working on a flattened design net-list.  A clock

net is likely to appear at the top level of the hierarchy, and its name there is the one to use

for TNM_NET.  If you look at the failing paths in the timing report, you should see the names of

the clock nets as the timing analyzer sees them.

 

If you always treat these clocks as unrelated, then a TIG constraint is probably OK.  I have noticed

that the TIG constraint will remove setup errors, but not hold errors.  That's why I recommended

the FROM : TO constraint with DATAPATHONLY.

 

The name "DATAPATHONLY" is looking at this from the perspective of timing analysis.  It says to

only check the actual data path delay and don't count the clock path delays.  It's the clock path

delay skew that generally results in the hold errors.  This may become more clear when you

look at the static timing reports and see how the data and clock paths are analyzed.

 

-- Gabor

-- Gabor
0 Kudos
Highlighted
Observer mflmfl
Observer
9,684 Views
Registered: ‎06-10-2011

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

OK, that cleared it up, things are timing out now after fixing the ucf. Thanks for your detailed answers.

0 Kudos
Professor
Professor
9,682 Views
Registered: ‎08-14-2007

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

That's good to hear.  Would you mind posting the constraints that worked for

you?  I saw that already since this thread started another person has posted

on the same issue.

 

-- Gabor

-- Gabor
0 Kudos
Observer mflmfl
Observer
12,441 Views
Registered: ‎06-10-2011

Re: False Timing Paths using FIFO to cross clock domains

Jump to solution

Sure, to recap:

I've got a FIFO in my design that has two disparate clocks, they have no relationship to eachother and I don't want TRCE to time across the domains.

 

The Xilinx tools create a relationship between a clock on a pin and a clock that may have been generated from that clock by a DCM etc., and will therefore attempt to time paths that cross domains. In general this may be a good idea, but it's just  not when it comes to FIFOs with separate read and write ports where the whole point of using a FIFO in this way is to decouple clock domains in a nice way. So I'd call this a workaround, in this case I decouple the clocks in the ucf file with a  Timing Ignore (TIG)

 

Example:

Net "FrameClk" TNM_NET = "FRAME_CLK";
Net "Sout_clk" TNM_NET = "SOUT_CLK";
TIMESPEC "TS_XDOMAINS_WRTORD" = FROM "SOUT_CLK" TO "FRAME_CLK" TIG;
TIMESPEC "TS_XDOMAINS_RDTOWR" = FROM "FRAME_CLK" TO "SOUT_CLK" TIG;

 

Note the TIG in both directions, otherwise you'll be left with HOLD problems (or setup problems depending on which one you leave out). In the example FrameClk and Sout_clk are the clock names at my top level.

View solution in original post

0 Kudos