Unroutable design - ERROR:Route:472

[mapedd]

Hello again.

I'm trying to Implement my design for Spartan-6 (xc6slx150t--3fgg900). It's my first big design that uses a lot of device-specific parts like PLL's ,MCB, Block RAMs, IODELAYS, BUFG's and so on. I really don't know how i can resolve this problem. I'm looking for a place to start ...

I read ug382 with the clocking resources for Spartan 6 but it's a bit to heavy for a beginner ...

My design consists of two parts:

1. Memory Controller Block with DDR3 memory connected to Bank 1. It uses it's own PLL to clock itself, i'm feeding input clock to that module from LVDS clock connected to GCLK24 and GCLK25, through IBUFGDS to CLKIN if the MCB_PLL. UCF for DDR chip is taken from that generated by CoreGen. If only this module is in the project it implements without errors/

2. Deserializers connected to bottom part of the device (see attached UCF ,pins A0_DA0_N-A3_FCLK_P (lines 65 - 185) . Data lines are read though IBUFDS then IODELAY2 then IDDR. This part is clocked by 4 clock generated by the PLL_ADV instance.

PLL_ADV have it's input connected to pins GCLK2/GCLK3 (A0_DCLK_P/A0_DCLK_N), through IBUFGDS. Feedback of the PLL_ADV is through BUFG_FB. It outputs 4 clocks: clk_par, clk_ser, clk_ser_del, clk_ser_2x with programmable parameters.

Those 4 clocks are clocking whole logic of the design including user - interface of the MCB.

With this configuration i'm there is an error in the MAP process:

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found
   that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
   IOB component <A0_DCLK_P> is placed at site <AC16>. The corresponding BUFG
   component
   <data_buffer_inst/data_standarizer/data_rx_inst/pll_dyn_top_int/BUFG_IN> is
   placed at site <BUFGMUX_X2Y2>. There is only a select set of IOBs that can
   use the fast path to the Clocker buffer, and they are not being used. You may
   want to analyze why this problem exists and correct it. If this sub optimal
   condition is acceptable for this design, you may use the
   CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a
   WARNING and allow your design to continue. However, the use of this override
   is highly discouraged as it may lead to very poor timing results. It is
   recommended that this error condition be corrected in the design. A list of
   all the COMP.PINs used in this clock placement rule is listed below. These
   examples can be used directly in the .ucf file to override this clock rule.
   < NET "A0_DCLK_P" CLOCK_DEDICATED_ROUTE = FALSE; >

 and when i put this rule from last line of the error i'm getting Error with the number in the topic of this post.

One of ideas is to connect outputs of the PLL_ADV clocking the deserializers to BUFGs, does it make any sense?

Does anyone have idea how i can start to debug this. Or where can i find information about using clocking resources in the Xilinx FPGAs ....

Thanks for any help

p.s. You can download my Synthesis report in the PDF format HERE, and Image of Spartan Clock Pin Layout from UG382 HERE

[austin]

m,

Have you viewed the results in FPGA_Editor?  In that you should be able to see exactly what is wrong, and if the pins are available (IO pins), you could move the clock input to where it should be.

You might also try to depricate the error to a warning.  Although discouraged, if the clock is already wirede to those pins, then you really may have no other  choice.

[mapedd]

Yes i tried it, but to be honest i can only see where compilator placed my logic and which primitives it used, but i don't know how to spot wrong things and how to fix them in FPGA Editor.

Should i first read some in-depth manuals of the FPGA Editor?

As i was saying, first time real-world implementation ...

[austin]

m,

Do you have your pins assigned already?  (Layout of board is done, wiring is fixed)

If so, you may have no choice:  depricate the error to a warning, and then see what is needed to fix any other problems (dleay vclocks, use alternate phases, etc.).

If you have not made the board, look at a better place to put the clock input.

And yes, learn to use FPGA_Editor:  it can be very useful in understanding what is happening.  There are u-tube videos on FPGA_Editor -- it isn't all that painful or difficult to use.

[mapedd]

Layout is almost done, but fortunately there are couple of clocks on the board  i can use, and there are three identical  DDR3 chips connected to FPGA device, so my options are quite flexible.

My problem is exactly this quote: "If you have not made the board, look at a better place to put the clock input." 

How can I find better clock input? I don't wanna try blindly different optons, but just know which clock should I pick and why

And thanks, I will certainly look for those YouTube videos for FPGA Editor:)

p.s. supressing this error is cousing design to be unrouteable, as stated in my first post

[llewis]

Based on your description here it does not seem to exactly match what you have implemented.

PLL_ADV have it's input connected to pins GCLK2/GCLK3 (A0_DCLK_P/A0_DCLK_N), through IBUFGDS.
Feedback of the PLL_ADV is through BUFG_FB.
It outputs 4 clocks: clk_par, clk_ser, clk_ser_del, clk_ser_2x with programmable parameters.

All comments below are specific to Spartan-6
The error message complains that PIN AC19 (GCLK3) cannot connect to BUFG_X2Y2. This is correct.
There are dedicated direct connections from each GCLK PAD to each BUFG when no BUFIO2 is used.
This path is designed and optimized to be the fastest path and to do this there is a one to one connection between the PAD and the BUFG. Most designs do not use the direct connection but will connect a GCLK PAD through a BUFIO2 to any BUFG in the same Top or Bottom half of the device that the GCLK PAD is located. If you wanted to connect differential GCLK3/GCLK2 directly to a BUFG then you would need to assign it to BUFG_X2Y9. 

Based on your comments and the net name I do not think this is what you want to do. 

It appears that you want to bring the Clock into the device and connect directly to a PLL, in this case in the bottom of the device also.  The tools will route the clock through a BUFIO2 to the PLL and the Feedback Clock will route through a BUFG to a BUFIO2_FB placed adjacent to the associated BUFIO2.
This will provide you with a clock that is correctly routed and will use the correct feedback to correctly remove the clock insertion delay.

I am basing these comments on the error message and your descrption of what you are attempting.
If you cannot use the PLL in the bottom of the device then you would need to reconsider your GCLK placement.

[mapedd]

Thanks for helping

 It appears that you want to bring the Clock into the device and connect directly to a PLL, in this case in the bottom of the device also. The tools will route the clock through a BUFIO2 to the PLL and the Feedback Clock will route through a BUFG to a BUFIO2_FB placed adjacent to the associated BUFIO2. This will provide you with a clock that is correctly routed and will use the correct feedback to correctly remove the clock insertion delay.

I have 16 LVDS DDR data channels connected to bottom of the device and 1 LVDS clock that i want to use to deserialize data. To do that i'm connecting it to PLL to generate bit and word clocks.

Problem is that during implementation, compiler chooses PLL on the other side of the device. I'm not LOCing any of the primitives i'm using besides MCB part which LOCed itself without my help.

On the image below you can see screenshot from the FPGA editor. Red spots at the bottom are my RX channel with Data and Clock ports.

On the left is B3 clock which is a master logic clock that's used to start design, and clock the MCB PLL, which is connected to right edge of the device.

This red dot at the top is PLL_ADV instance with was choosen by tools during compilation, it's quite far from the place it's needed since it's primarly used to deserialize incoming data from the bottom.

Maybe i should force placement of the PLL_ADV to somewhere in the bottom half of the  device?

If this is a good idea which one should i pick?

I don't want to use BUFIO2 because in near future i will need 32 LVDS input channels that will span to more than one BUFIO region...

I can upload *ncd file if it would help ...

[llewis]

From a picture I have laying around it just shows a DCM but this will also apply to the PLL. 

If you coded the PAD (IBUF) to connect directly to the PLL then the PLL to connect to a BUFG and finally the BUFG to the PLL Feedback, this circuit should be implemented automatically. 

The BUFIO2 is used so the input will match the delay of the BUFIO2FB in the feedback path.  You will not be using the BUFIO2 to directly capture the data, just to correctly implement the PLL so that it will remove the clock insertion delay.

[mapedd]

Thanks for helping.

I understood that i should insert a BUFIO2 local clock buffer to ease routiing between PAD and PLL, so i've done something like this:

Unfortunately i'm still gettings the same error inthe Maping : 

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found
   that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
   IOB component <A0_DCLK_P> is placed at site <AC16>. The corresponding BUFG
   component
   <data_buffer_inst/data_standarizer/data_rx_inst/clk_rx_buff<0>_BUFG> is
   placed at site <BUFGMUX_X2Y1>. There is only a select set of IOBs that can
   use the fast path to the Clocker buffer, and they are not being used. You may
   want to analyze why this problem exists and correct it. If this sub optimal
   condition is acceptable for this design, you may use the
   CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a
   WARNING and allow your design to continue. However, the use of this override
   is highly discouraged as it may lead to very poor timing results. It is
   recommended that this error condition be corrected in the design. A list of
   all the COMP.PINs used in this clock placement rule is listed below. These
   examples can be used directly in the .ucf file to override this clock rule.
   < NET "A0_DCLK_P" CLOCK_DEDICATED_ROUTE = FALSE; >

[llewis]

The issus still is nothing to do with the PLL. Your error message is saying that your GCLK2/3 pad is dircetly driving a BUFG at site X2Y1.  From the circuit you describe, I do not understand why this PAD would be connected directly to the BUFG. Your drawing shows that it is connected to a PLL directly.   This is the error you need to fix.  Is there a BUFG between the PAD and the BUFG?

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock IOB component <A0_DCLK_P> is placed at site <AC16>. The corresponding BUFG
   component <data_buffer_inst/data_standarizer/data_rx_inst/clk_rx_buff<0>_BUFG>

[mapedd]

Thanks!

 This is the error you need to fix.  Is there a BUFG between the PAD and the BUFG?

I didn't instantiate any BUFG between PAD and PLL, because this i what you meant i guess :). 

BUT! After inspecting in the FPGA Editor i found that Compiler inserted A BUFGM to one the pins of the differential clock:

From UG615  about IBUGDS:

Put all I/O components on the top-level of the design to help facilitate hierarchical design methods. Connect the I
port directly to the top-level "master" input port of the design, the IB port to the top-level "slave" input port and
the O port to an MMCM, BUFG or logic in which this input is to source. Some synthesis tools infer the BUFG
automatically if necessary, when connecting an IBUFG to the clock resources of the FPGA. Specify the desired
generic/defparam values in order to configure the proper behavior of the buffer.

I didn't do thing from the first sentence - i instantiated a IBUFG in the module deeper than TOP in my design, and i guess this might be the reason Compiler is inserting a BUFGM in my clock path.

I will move this primite (IBUFGDS) to top and see if it will help

---

 UPDATE

---

I moved IBUFGDS to top level entity, but unfortunaltey it didn't help. I still have the same error:

ERROR:Place:1108 - A clock IOB / BUFGMUX clock component pair have been found
   that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock
   IOB component <A3_DCLK_P> is placed at site <AJ17>. The corresponding BUFG
   component <src_clk_buff_BUFG> is placed at site <BUFGMUX_X2Y2>. There is only
   a select set of IOBs that can use the fast path to the Clocker buffer, and
   they are not being used. You may want to analyze why this problem exists and
   correct it. If this sub optimal condition is acceptable for this design, you
   may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this
   message to a WARNING and allow your design to continue. However, the use of
   this override is highly discouraged as it may lead to very poor timing
   results. It is recommended that this error condition be corrected in the
   design. A list of all the COMP.PINs used in this clock placement rule is
   listed below. These examples can be used directly in the .ucf file to
   override this clock rule.
   < NET "A3_DCLK_P" CLOCK_DEDICATED_ROUTE = FALSE; >

Additionaly I tried using 3 different clocks , i all cases a misterious BUFG is generated

I tried those differential pairs:

NET "A0_DCLK_N" LOC = "AD16"; #IO_L29N_GCLK2_2
NET "A0_DCLK_P" LOC = "AC16"; #IO_L29P_GCLK3_2

NET "A1_DCLK_N" LOC = "AG16"; #IO_L30N_GCLK0_USERCCLK_2
NET "A1_DCLK_P" LOC = "AF16"; #IO_L30P_GCLK1_D13_2

NET "A2_DCLK_N" LOC = "AK16"; #IO_L31N_GCLK30_D15_2
NET "A2_DCLK_P" LOC = "AH16"; #IO_L31P_GCLK31_D14_2

NET "A3_DCLK_N" LOC = "AK17"; #IO_L32N_GCLK28_2
NET "A3_DCLK_P" LOC = "AJ17"; #IO_L32P_GCLK29_2

 What's interesing, this IBUFG is inserted only in the Positive node of the diff clock...

[llewis]

1) IBUFGDS should only use the Master side (P-Side) of the clock to connect to internal clocks.  If the designer is extremely advanced then there is the possibility to use an IBUFGDS_DIFF_OUT where bot the P-Side and N-Side inputs can be used but this is only for very advanced users and in most cases would be a waste of a BUFG since has probramable clock inverters in al of the components.

2) Using an IBUFG or IBUFGDS is basically a legacy component that, in architectures prior to Virtex-4, instructed the software to place this pin on a Dedicated Clock PAD.  It has no real meaning anymore to the tools, though may be useful to you as a designer to quickly recognize that this pad is a clock.  Some synthesis tools see this and will incorrectly automatically infer a BUFG.  Consder implementing the code without the IBUFGDS and just use an IBUFDS.

3) To avoid the tools infering a clock buffer where you do not what one, set the property in BUFFER_TYPE=NONE in your HDL.  This will prevent the synthesis tools from inserting unwanted BUFGs

[mapedd]

thanks!

i switched my IBUFG's and IBUFGDS's to IBUF's and IBUFDS's, and now trying top set BUFFER_TYPE to NONE.

Should it be done in the VHDL code or in the UCF file?

---

EDIT

---

Hi, following your advice , i added attribute to my clock signal in the top module (after IBUFDS) :

  attribute BUFFER_TYPE : string;
  attribute BUFFER_TYPE of clk_i_se : signal is "NONE";

additionaly i, following this Support Answer 42228 i changed "read_cores" XST option to be OFF.

Thanks to those action, compiler is not unserting BUFG instansec anymore.

But unfortunately another problem arised:

ERROR:Route:472 - 
   This design is unrouteable.
   To evaluate the problem please use fpga_editor.
Routing Conflict 1: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X25Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X25Y1 
    Conflict detected on wire: PINFEED1(111018,-312014)

Routing Conflict 2: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X25Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X25Y3 
    Conflict detected on wire: PINFEED1(111018,-308814)

Routing Conflict 3: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X26Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X26Y1 
    Conflict detected on wire: PINFEED1(115170,-312014)

Routing Conflict 4: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X26Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X26Y3 
    Conflict detected on wire: PINFEED1(115170,-308814)

Routing Conflict 5: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X27Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X27Y1 
    Conflict detected on wire: PINFEED1(123474,-312014)

Routing Conflict 6: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X27Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X27Y3 
    Conflict detected on wire: PINFEED1(123474,-308814)

Routing Conflict 7: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X28Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X28Y1 
    Conflict detected on wire: PINFEED1(127626,-312014)

Routing Conflict 8: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X29Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X29Y1 
    Conflict detected on wire: PINFEED1(135930,-312014)

Routing Conflict 9: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X29Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X29Y3 
    Conflict detected on wire: PINFEED1(135930,-308814)

Routing Conflict 10: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X30Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X30Y1 
    Conflict detected on wire: PINFEED1(140082,-312014)

Routing Conflict 11: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X30Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X30Y3 
    Conflict detected on wire: PINFEED1(140082,-308814)

Routing Conflict 12: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X31Y1 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X31Y1 
    Conflict detected on wire: PINFEED1(151842,-312014)

Routing Conflict 13: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X31Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X31Y3 
    Conflict detected on wire: PINFEED1(151842,-308814)

Routing Conflict 14: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X32Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X32Y3 
    Conflict detected on wire: PINFEED1(155994,-308814)

Routing Conflict 15: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X33Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X33Y3 
    Conflict detected on wire: PINFEED1(167754,-308814)

Routing Conflict 16: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X34Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X34Y3 
    Conflict detected on wire: PINFEED1(171906,-308814)

Does anyone have an idea what can cause this error?

Thanks for help!

[llewis]

Changing the buffer type from IBUFG to IBUF can sometimes help prevent some synthesis tools from inserting unwanted BUFGs but it is not always required.  Using an IBUFG is useful so that you can see which PADs are being used as clock pads.  Since you set the BUFFER_TYPE = NONE, that is sufficient to prevent any tool from inserting unwanted BUFGs so keeping the IBUFG is now safe.  Yes you should do this in the HDL because the Synthesis tool is likely not reading your UCF. 

Now for your latest error.  The following statement is for Spartan-6 only.  There some clocking topologies in S6 when using the IODELAY that REQUIRE the BUFG to be placed in one of the TOP half BUFGs.  If you have the BUFG placed in one of the bottom BUFGs then you may see an error similar to the ones that you posted.  Without seeing the desgin I cannot be sure this is the issue but I suspect that it is.   I was a little concerned that something like this might happen.  In your orriginal post you were having issues with a BUFG being placed in the top half of the device when your clock was coming in the bottom.  Something was pulling the BUFG to the top and this new issue might be showing what it is. 

In attempt to debug this, and to see if my assumption is correct, use a floof planning tool to isolate the BUFG that is causing this issue then, in your UCF, locate this to a BUFG in the top half of the device. 

I expect this might cause another error but it will help you find out if this is the issue.   If this does cause an error, probably something like this PAD cannot possibly route to the BUFG, then it is likely the PAD is not in a location then can connect to a top half BUFG.  If that happens post the error again and I might be able to suggest something else.

[mapedd]

" use floor planning tool to isolate the BUFG that is causing this issue "

Is there any 'algorithm' i can use to find this particular BUFG? 

For example in this routing conflict: 

Routing Conflict 16: 
	Net:data_buffer_inst/data_standarizer/clk_ser_del_o on pin IOCLK1 on location IODELAY_X34Y3 
	Net:data_buffer_inst/clk_ser on pin CLK1 on location ILOGIC_X34Y3 

Maybe i should check in the datasheet which BUFG should be IODELAY_X34Y3 connected to?

---

EDIT

I tried looking for it this way:

After Map process i've opened FPGA Editor and searched for clk_ser and clk_ser_del which seems to be be causing all routing conflicts, the BUFG they are connected to is :

comp "data_buffer_inst/data_standarizer/data_rx_inst/pll_dyn_top_int/BUFG_CLK1",  site "BUFGMUX_X2Y2",  type = BUFG  (RPM grid X169Y390)

This is how it looks like in the FPGA Editor:

Weird thing is, this BUFG_X2Y2 seems to be already placed in the top half of the device (according to UG382) 

[llewis]

Now your problem is getting a bit more complex and much more difficult to analyze without seeing the design.  There is a rule where only 2 clocks can route into the ILOGIC,OLOGIC but when IODELAY2 is used a 3rd clock can sometimes be used. Now the issue gets complicated because the ILOGIC and OLOGIC will need to be using BUFIO2_2CLK, which uses 2 clocks and then the 3rd clock can be a top BUFG.  Now if your are trying to capture data in this ILOGIC/OLOGIC using all global clocks then you will likely be running into the issue you see. 

Sometimes the tools do not allow you to use the 2 BUFIO2_2CLKs plus the 3rd BUFG but will generate an ERROR instructing you to set CLOCK_DEDICATED_ROUTE=FALSE for the clock that will not route. If this is the case and you set CDR to FALSE and the design routes then it will likely be acceptable. If this does route then you should load the desgin in FPGA_EDITOR and verify that the clock routed using dedicated resources.  This can be done be selecting the clock net and pressing the ATTRIBUTE tab an the viewin pin delays in the list window.  If the skew on all of the loads is less around a few Pico Seconds or less then you are using the global clock tree and this is a legal design.

For almost all cases when using CLOCK_DEDICATED_ROUTE=FALSE it should be used just to help you debug a clock routing issue but there are a few legal cases that you can set it.  For this reason you should always load your design and verify that setting the CDR constraint provides a valid clock route or you can use the routed NCD to attempt to understand why the tools feel there is an issue with clock.

[mapedd]

Maybe i should send you a link to source of my project or post it here? Or maybe there's a rule that Xilinx employee can't see clients projects :)

[llewis]

if you can zip and post your NCD file I will take a quick look at it.  Posting the NCD is more an issue of your design security.

[mapedd]

It's my Master Thesis, so it's basically open source, i can send you a link to ziped sources.

I've attached ncd file zipped

[llewis]

Loading the design in FPGA EDITOR and selecting the problem clock net and then AutoRouting creates a net with a legal route. This tells me that the BUFG is placed correctly but there is contention for the routing resources at the IODELAY2.  Now I need to dig in a bit deeper and iind out what caused the contention which prevents this clock net from routing when all other nets are routed.

[mapedd]

Here is the source, top level file is the m_k40_top

Thanks, it's really nice of you:)

[llewis]

You are using the BUFG sourced net "data_buffer_inst/clk_ser" to drive the following 3 pins

IODELAY_X27Y1.CLK, IODELAY_X27Y1.IOCLK0 and ILOGIC_X27Y1.CLK1

Then you are using BUFG sourced net "data_buffer_inst/data_standarizer/clk_ser_del_o" to drive the following 2 pins IODELAY_X27Y1.IOCLK1, ILOGIC_X27Y1.CLK0

The problem is the combination of these 2 Global Clocks driving the combination of clocks on the IODELAY2/ILOGIC pair has used one more routing resource than is available. Generally IOCLKs would be sourced from the IOCLK buffers, such as the BUFIO2, BUFIO2_2CLK or BUFPLL. Using these resources then you would be keeping these 2 clocks on expected resources and would be easily routed. Since you are using a delayed and non delayed version, these count as 2 seperate clock resources. Now, if you used the IOCLK buffer, you could use 1 BUFG placed in a TOP half BUFG to get the 3rd clock to the IODELAY.CLK pin.

I don't spend a lot of time on implementation, just routing, so if you can try to organize the clocks in a similar manner to what I described then I can make comments on the routability of the circuit. As a test you could implement your test circuit on 1 ILOGIC/IODELAY and they quickly try several different topologies to see which will route. Please review the UG to understand the trade offs between using a BUFIO2_2CLK (for DDR) or BUFPLL for a 2X SDR implementation. Based on the clock names it seems you are attempting to 2 clock signals, with different delays, and capture a DDR data stream. This would likely be best achieved using the BUFIO2_2CLK though it will be a bit challenging in S6.

[mapedd]

I tried to follow your hints, and i come up with the clock configuration as in the image:

I buffered two fast serial clock outputs (normal and 180 degrees shifted for DDR signal)  from the PLL (output 0 and 1) through BUFFPLL to IODELAYs inputs IOCLK0 and IOCLK1,

Third slower parallel clock from PLL (output 2) goes through BUFG to CLK input of the IODELAYs

Routing conflicts dissappeared, new error showed up :

ERROR:Place:1286 - Placer has detected a BUFIO2 component <
   data_buffer_inst/data_standarizer/data_rx_inst/pll_dyn_top_int/BUFIO2_inst >
   driving component <
   data_buffer_inst/data_standarizer/data_rx_inst/pll_dyn_top_int/PLL_ADV_inst >
   (on pin < CLKIN1 >) which is not associated with an IOB component. Automatic
   clock placement of components not associated with an IOB is not supported. If
   the load component is an IODELAY, the user can LOC the IODELAY and BUFIO2 to
   the same half-bank and re-run placer.

Link to source

Is this the error you expected?

[llewis]

With this picture I am getting a better idea of what you are doing. 

Capturing DDR data with the BUFIO2 or BUFPLL is OK but using these clock components you would be much better off using the SERDES.   

With the BUFPLL you really do need to use the SERDES. You would use the PLL to create a 2X clock then you would connect just the 1 clock to the input of the ISERDES and capture the SDR data at a 2X clock rate, essentially DDR.  Also to use this with the PLL the output of the BUFPLL would need to be in the feedback path so you would remove the correct clock insertion delay. Now use your slower divided down BUFG clock domain to transfer this into the fabric.

The BUFIO2_2CLK would be needed if you wanted to create 2 separate clocks, one for rising edge data and one for the falling edge data.  This could theoretically be used with the DDR FFs in the IO but now you would have to build some sort of carefully timed circuit to transfer the data from the IO DDR FFs into the fabric.  Using the ISERDES here would also be a good idea.

The circuits briefly described above are the general intent of capturing high speed data in Spartan-6.  I have not used these in several years so my description may not be exact but is close.

Now I think we get back to your original circuit.  If you want to use the DDR FFs then you would be using the BUFGs, just not in the configuration that you originally used.  You would use the 3 BUFGs but you have to be careful to keep the clocks lined up correctly.  In you original design you had one clock connected to IOCLOCK0 and the same clock connected to IOCLOCK1 or some similar combination of this.  This confused the tools and created the unroutable clock situation.  If you want to use DDR FFs and use BUFGs just be sure to create 1 clock for all of the IOCLOCK0s and 1 CLOCK for all of the IOCLOCK1s and then the 3rd clock. I belive used for the IODELAY clock, must be a BUFG placed in the top half of the device.  This will satisfy the routing rules of no more than 3 clocks in an IOI tile.  As soon as you put the same BUFG net on an IOCLOCK0 and an IOCLOCK1 you would over the limit.

I think the best performing circuit would be the BUFIO2_2CLK with SERDES or the BUFPLL (2X rate) with SERDES but if you want to use the 2 clocks with the IDDR FFs and the IODELAY then you have to be very careful with clock pin selection.

[mapedd]

I've made decision not to use IOSERDES2 due to fact i want to have oportunity to change all parameters of the circuit in the runtime, without recompilation of the circuit:

1. word length (8,10,12,14, or 16 bits)
2. MSB first or LSB first,
3. deserialize on/off
4. invert incoming data on/off

i wrote my own serdes , which works perfectly in simulation:D

[llewis]

So I think you orrigianl circuit might have worked with BUFGs if you had connected them the way that you drew in your picture.  You have PLL output 0  going to IODELAY2.CLK0 and IDDR.CLK0 then PLL output 1 going to IDELAY2CLK1 and IDDR.CLK1. 

This should route but it is not how your original design was implemented.  Maybe just go back to the original design and take special care to keep the clocks lined up this way and I think you will be OK.  Using 3 BUFG nets in the same IO is very difficult and you have to make sure it is connected in exactly the way I described

Just as an FYI.  In your drawing you have BUFPLLs connected to fabric logic.  The BUFIO2s and BUFPLLs are IO only clocks and will not clock anything other than IOs.  Maybe that was what the error was trying to indicate.

[mapedd]

Thanks again.

From what i understood : 

If i don't wan't to use primitive IOSERDES2 to deserialize incoming data i can't use BUFIO2 or BUFIO2_PLL to clock IODELAY2 or IDDR2, i cant only use global clocking network using BUFG's

I have to route one of the 3 clocks i need to power IODELAY through top half of the device, to do that i need set LOC attribute to this BUFG to any of the BUFG's locaated in the top half.

Is that correct?

I drew a schematic how i'm gonna connect all clocks:

Link to full scale image

[llewis]

The quickest way to find out what combination of clocks will work is to load FPGA Edtior, add 3 BUFGs and then connect them to the IODELAY and ILOGIC.  I just tried a few combinations and found that the 3 BUFGs do not work either.  The intent for these circuits was to be used with the BUFIO2 or BUFPLL so most advanced clocking combinations will require the use of them.  

I did find that you can connect 1 BUFG to the CLK0 and CLK1 then use local inversion at the ILOGIC to get the inverted phase of the clock and then use the 2nd clock to clock the IODELAY.  Your circuit shows that you are using clock and clock180 out of the PLL so using clk and inverting it at the CLK1 pin will effectively give you the same result. 

If you want to use a BUFIO2 and an IDDR it is possible but you would have to build a circuit that would transfer the data from the fast BUFIO2 domain to the slower BUFG domain.  If you could have used the ISERDES then this would have taken care of the domain change for you.

[mapedd]

i can invert clk from BUFG just like logic with the code or i need something fancier?

[llewis]

For Spartan 6 just invert the net attached to the CLK1 pin.  It would be different in the Virtex devices but this will work in Spartan6.

IDDR2 (.Q0(D1P) , .Q1(D1N) , .C0(BUFG_CLK1) , .C1(~BUFG_CLK1)