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: 
Highlighted
Observer hakanaydin
Observer
10,963 Views
Registered: ‎04-02-2009

Spartan-6: IBUFGDS to PLL and to fabric logic causes "impossible timing" error

Here is a very simple HDL module:

 

module top ( input clk_p, input clk_n, input din, output test );

IBUFGDS #(.DIFF_TERM ("TRUE"))  u_ibufg_sys_clk ( .I(clk_p), .IB(clk_n), .O(clk_buf) );
pll pll_inst(.CLK_IN1(clk_buf), .CLK_OUT1(clk156Mhz), .RESET(1'b0), .LOCKED(LOCKED));

wire [15:0] dout;	 
duaclkfifo fifoinst (
  .rst(1'b0),       
  .wr_clk(clk_buf), 
  .rd_clk(clk156Mhz), 
  .din({15'h0, din}), 
  .wr_en(1'b1),
  .rd_en(1'b1), 
  .dout(dout[15:0]));
assign test = ^dout[15:0];	 
endmodule

 and its associated UCF for a Spartan-6 LX45 in the FGG484 package:

NET  "clk_p"  IOSTANDARD = LVDS_25 ;
NET  "clk_n"  IOSTANDARD = LVDS_25 ;
NET  "clk_n"  LOC = "Y12" ;
NET  "clk_p"  LOC = "W12" ;
NET "clk_buf" TNM_NET = "SYS_CLK";
TIMESPEC "TS_SYS_CLK" = PERIOD "SYS_CLK"  10  ns HIGH 50 %;
NET "test"  LOC =     W9     | IOSTANDARD =     LVCMOS33;
NET "din"  LOC =     V9     | IOSTANDARD =     LVCMOS33;

 When we try to implement this, during map, we get:

WARNING:Pack:1653 - At least one timing constraint is impossible to meet because component delays alone exceed the constraint. A timing constraint summary below shows the failing constraints (preceded with an Asterisk (*)). Please use the Timing Analyzer (GUI) or TRCE (command line) with the Mapped NCD and PCF files to identify which constraints and paths are failing because of the component delays alone. If the failing path(s) is mapped to Xilinx components as expected, consider relaxing the constraint. If it is not mapped to  components as expected, re-evaluate your HDL and how synthesis is optimizing the path. To allow the tools to bypass this error, set the    environment variable XIL_TIMING_ALLOW_IMPOSSIBLE to 1.

 an example violation from the post-map timing report:

 Slack (setup path):     -1.064ns (requirement - (data path - clock path skew + uncertainty)) 
   Source:               fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_pntr_gc_0 (FF) 
   Destination:          fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[1].wr_stg_inst/Q_0 (FF) 
   Requirement:          0.400ns 
   Data Path Delay:      1.110ns (Levels of Logic = 0)(Component delays alone exceeds constraint) 
   Clock Path Skew:      0.000ns 
   Source Clock:         clk156Mhz rising at 89.600ns 
   Destination Clock:    clk_buf_BUFG rising at 90.000ns 
   Clock Uncertainty:    0.354ns 
  
   Clock Uncertainty:          0.354ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE 
     Total System Jitter (TSJ):  0.070ns 
     Discrete Jitter (DJ):       0.244ns 
     Phase Error (PE):           0.226ns 
  
   Maximum Data Path at Slow Process Corner: fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_pntr_gc_0 to fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[1].wr_stg_inst/Q_0 
     Location             Delay type         Delay(ns)  Physical Resource 
                                                        Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     SLICE_X15Y50.AMUX    Tshcko                0.518   fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_q<0><3> 
                                                        fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_pntr_gc_0 
     SLICE_X16Y50.AX      net (fanout=1)     e  0.478   fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_q<0><0> 
     SLICE_X16Y50.CLK     Tdick                 0.114   fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/rd_q<1><3> 
                                                        fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/gsync_stage[1].wr_stg_inst/Q_0 
     -------------------------------------------------  --------------------------- 
     Total                                      1.110ns (0.632ns logic, 0.478ns route) 
                                                        (56.9% logic, 43.1% route) 

 

As you can see, it is finding a path from clk156Mhz (rising at 89.600ns) to clk_buf_BUFG (rising at 90.000ns) So timing is obviously failing for 0.4ns of timing margin.

However, the FIFO is a dual-clock native FIFO, and the read/write ports have no relation to each other. We can not see why the tool is finding timing paths from one clock domain to the other.

Can you help us identify what is the problem here?

Thanks

0 Kudos
9 Replies
Historian
Historian
10,957 Views
Registered: ‎02-25-2008

Re: Spartan-6: IBUFDS to PLL and to fabric logic causes "impossible timing" error

Yikes, your post got moved while I was composing a reply!

 

Anyways: Spartan-6 clock routing can be weird and is not well documented.

 

Try the following. Instead of putting a BUFG on the input clock and routing it to both the PLL and to "other logic," try routing it to the PLL only. Then configure the PLL to generate, in addition to your 156 MHz clock, a clock which is a replicate of the input clock. The PLL feedback should be configured to look at the replicated clock.

 

Neat trick: save a BUFG by putting the input clock onto a BUFIO2, with the divider bypassed and the doubler disabled, and take the BUFIO2 output from its DIVCLK output into the PLL CLKIN port. Obviously the two PLL outputs will need a BUFG.

----------------------------Yes, I do this for a living.
0 Kudos
Observer hakanaydin
Observer
10,953 Views
Registered: ‎04-02-2009

Re: Spartan-6: IBUFDS to PLL and to fabric logic causes "impossible timing" error

bassman69:

 

Thanks for the very quick response. Sorry, I thought this forum is more appropriate, so I moved it here :-)

 

The project that I posted here is a subset of a "real" project that we have. In our "real" project, this PLL is the MCB infrastructure PLL. (I made sure this smaller project fails the same way before posting).

 

Your suggestion was the first thing that came to our minds as well, however, in order to maximize DDR3 performance, in the MCB PLL, we set the VCO frequency to 625MHz (100Mhz * mult 25 / div 4). Since VCO frequency is 625Mhz, there is no way we can obtain a 100Mhz clock as a PLL output, since it has only integer dividers. And the PLL primitive does not seem to output a buffered version of the input clock.

 

Any other suggestions?

 

We're on the same boat: I really do not like Spartan-6 clock routing as well. However, I am going to go out on a limb here and say that this is an actual bug in the tool -:) I just can not see why these two clocks are related. Maybe I am violating another constraint, but the mapper is giving me a "not-very-helpful-and-possibly-misleading" error while not telling me what the real problem is.

0 Kudos
Historian
Historian
10,947 Views
Registered: ‎02-25-2008

Re: Spartan-6: IBUFDS to PLL and to fabric logic causes "impossible timing" error

OK, if the two clocks are truly unrelated, perhaps putting a timing-ignore (TIG) constraint on the relevants paths would at least get the tools to shut the hell up?

 

I don't know the size of your FIFO, but if it's "small" it might be built out of LUT RAMS and not BRAMs. With the latter, you don't need to add any special constraints, as the tools "know" that there is no relationship between the two sides of a dual-port memory.

 

But if it's LUT RAM, remember that you write on one clock and there isn't a read clock on which data are actually read out. So you actually must mind the timing relationship. I tend to think that with a dual-ported LUT RAM, the read address actually is decoupled from the write logic and the tools should know that, but there you go.

----------------------------Yes, I do this for a living.
0 Kudos
Observer hakanaydin
Observer
10,942 Views
Registered: ‎04-02-2009

Re: Spartan-6: IBUFDS to PLL and to fabric logic causes "impossible timing" error

bassman59:

 

The FIFO is a BRAM based fifo, with independent clock, so that can not be the problem.

 

Just to try, for the PLL input clock, we used another external clock pin with the same frequency. In that case, the entire implementation process succeeds. Similarly, when we use another external clock pin with the same frequency to feed the FIFO wr clock, everything passes OK.

 

However, this scenario:

 


clk_p                          ------------ PLL --\
------\                       /                   |
       --------IBUFGDS-------/                    |
------/         100 MHz      \                    |
clk_n                         \--------\          |
                                       |          |
                                       |          |
                                 fifo_wr_clk  fifo_rd_clk

 

results in an unexplainable timing error.

0 Kudos
Historian
Historian
10,939 Views
Registered: ‎01-23-2009

Re: Spartan-6: IBUFGDS to PLL and to fabric logic causes "impossible timing" error

This path is clearly a false path. From its name alone this is the path from the read pointer to the synchronizing FFs that clock it on the write clock. The path needs a TIG.

 

In ISE, the core generator generates a UCF file with the TIG constraints in it. You need to look at the file, and import the constraints into you main constraints file - you will need to modify the constraints to include the full hierarchical path to the FIFO (since the UCF doesn't know where the FIFO is located in your hierarchy).

 

Avrum

 

 

0 Kudos
Instructor
Instructor
10,931 Views
Registered: ‎08-14-2007

Re: Spartan-6: IBUFDS to PLL and to fabric logic causes "impossible timing" error

Actually your picture leaves out the buffers, so I've attached one that represents your example.  Note that an IBUFGDS is not a global clock buffer, only an input buffer with special dedicated output routing to other clock resources including PLL DCM and BUFG.  That's why the tools have generated two names for the input clock - one before and one after the automatically inserted BUFG.

 

You can more easily generate timing constraints if you explicitly instantiate the BUFG, allowing you to choose the net names on both sides of the buffer.  As currently named by the tools, your 2 clocks are:

 

clk156Mhz

clk_buf_BUFG

 

And you can constrain cross-domain paths using TNM_NET for each clock to create the two timing groups for the FROM : TO constraints like:

 

net "clk_buf_BUFG" TNM_NET clk_90M ;

net "clk156Mhz" TNM_NET clk_156M ;

TIMESPEC TS_90_156 = FROM "clk90M" TO "clk156M" 10 ns DATAPATHONLY ;

TIMESPEC TS_156_90 = FROM "clk156M" TO "clk90M" 10 ns DATAPATHONLY ;

 

In this example instead of using TIG I geave a fairly generous 10 ns data path allowance and the DATAPATHONLY keyword prevents hold time checks on the cross clock paths.

 

HTH,

Gabor

 

-- Gabor
ClockDiag.png
Observer hakanaydin
Observer
10,924 Views
Registered: ‎04-02-2009

Re: Spartan-6: IBUFGDS to PLL and to fabric logic causes "impossible timing" error

avrumw:

 

My version of ISE (14.1) does not generate any constraint files for the FIFO, I just double-checked. However, your post reminded me to double-check the IP documentation at: http://www.xilinx.com/support/documentation/ip_documentation/fifo_generator/v9_1/fifo_generator_ug175.pdf

 

Page 154 (Page 146 of the PDF), describes how to disable the timing violations for the read and write pointers.
However, the instance names do not match 100%, even though I am using the exact same IP version.According to the documentation, for my case it should be:

 

NET fifoinst/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc<0> TIG;

 ... but that isn't even recognized as a valid object path. At the very least, according to my timing violation output, there's a U0 instance before xst_fifo_generator, so it should look like:

 

NET fifoinst/U0/xst_fifo_generator/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/wr_pntr_gc<0> TIG;

... but that is  also not recognized as a valid constraint. So I generalized the constraints even further as follows, which passes translate (recognized TIG constraints) but I still get the same timing failures:

 

NET "*/grf.rf/gntv_or_sync_fifo.gcx.clkx/*pntr*" TIG;
NET "*/grf.rf/gntv_or_sync_fifo.gcx.clkx/*pntr*" TIG;

 

I have a few questions at this point:

- Why can't I constrain my FIFO signals properly?

- Are these timing constraints supposed to help failures on MAP stage as well? Remember that my failure is not during PAR, rather, it fails at MAP saying that the component delays alone make it impossible to meet timing.

- If this is actually a timing constraint issue, why don't I see these violations with different clock inputs pins of same frequency, but start seeing them when I connect my clock to both the PLL and to fabric logic?

 

Thanks

0 Kudos
Historian
Historian
10,919 Views
Registered: ‎01-23-2009

Re: Spartan-6: IBUFGDS to PLL and to fabric logic causes "impossible timing" error

In general, I dislike NET based TIGs - they are way too easy to get wrong. I definitely do not recommend a NET TIG with wildcards like you tried.

 

I would do two things

1) Submit a webcase due to the discrepency between the documentation and the actual generated core (but don't expect to get an answer soon)

2) Do what Gabor suggested with the FROM:TO constraints between the clock domains.

 

As for the rest of your questions

 

- Are these timing constraints supposed to help failures on MAP stage as well? Remember that my failure is not during PAR, rather, it fails at MAP saying that the component delays alone make it impossible to meet timing.

 

Both MAP and PAR are timing driven, hence need constraints. Map is recognizing (correctly) that these constraints are impossible to meet and is giving up, rather than wasting hours on trying to meet impossible constraints. The root problem is that, in this case, the constraint determined by the tool is incorrect - it needs to be overridden with a TIG or FROM:TO timespec to make it right.

 

- If this is actually a timing constraint issue, why don't I see these violations with different clock inputs pins of same frequency, but start seeing them when I connect my clock to both the PLL and to fabric logic?

 

ISE has the (odd) notion of related clocks and unrelated clocks. When two clocks are specified to the tool with individual PERIOD constraints, the tool views these two clocks as unrelated clocks (unless you use magic incantation to make the tool treat them as related clocks). As such, it assumes all paths between them are false by default.

 

However, when the two clocks come from the same PERIOD constraint (in this case the input and output of the PLL), the tool views these clocks as related, and hence tries to time the paths between them (it assumes they are not false). However, in this case, due to the clock crossing circuits inside the FIFO, the "default" timing relationship is not correct for these paths, and an exception is needed - either the TIG or the FROM:TO (I also prefer the FROM:TO).

 

Avrum

Observer hakanaydin
Observer
10,911 Views
Registered: ‎04-02-2009

Re: Spartan-6: IBUFDS to PLL and to fabric logic causes "impossible timing" error

gszakacs:

 

That worked. For completeness sake, the correct syntax is:

 

NET "clk_buf_BUFG" TNM_NET = clk_100M;
NET "clk156Mhz"    TNM_NET = clk_156M;
TIMESPEC TS_100_156 = FROM "clk_100M" TO "clk_156M" 10 ns DATAPATHONLY;
TIMESPEC TS_156_100 = FROM "clk_156M" TO "clk_100M" 10 ns DATAPATHONLY;

 

I got the following warning from Translate, but then everything seemed to work OK:

 

WARNING:ConstraintSystem - TNM : clk_100M was distributed to a DCM but new TNM
   constraints were not derived. This TNM is used in the following user groups or specifications:
   <TIMESPEC TS_100_156 = FROM "clk_100M" TO "clk_156M" 10 ns DATAPATHONLY;>[test.ucf(13)]
   <TIMESPEC TS_156_100 = FROM "clk_156M" TO "clk_100M" 10 ns DATAPATHONLY;>[test.ucf(14)]

 

I guess I am still curious as to why I don't see these violations with different clock inputs pins of same frequency, but start seeing them when I connect my clock to both the PLL and to fabric logic. But I just noticed avrumw's response above, which addresses that question.

 

0 Kudos