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
Adventurer
Adventurer
14,010 Views
Registered: ‎12-21-2011

Unroutable design - ERROR:Route:472

Jump to solution

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

 

 

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
13,573 Views
Registered: ‎06-20-2008

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

Someone else will need to chime in if they see an issu with your configuration.  My comments are based on place and routing. Though the error is saying that you have set the DELAY_SRC to ODATIN or IO (likely IO after reading both messages).  Maybe you should set it specificaylly to IDATAIN and see if that works around the confusion. I do not see where you have set it in your HDL.

 

This error says you have delay_src to be IO.

 

ERROR:PhysDesignRules:1765 - Issue with pin connections and/or configuration on block:

<data_buffer_inst/data_standarizer/data_rx_inst/gen_ser2par[8].inst_ser2par/inst_delay>:<IODELAY2_IODELAY2>.  For DELAY_SRC IO programming the T input pin of IODELAY2 must be connected. 

 

 

The next error then basically is saying the same thing.

 

ERROR:PhysDesignRules:1768 - Issue with pin connections and/or configuration on block:

<data_buffer_inst/data_standarizer/data_rx_inst/gen_ser2par[8].inst_ser2par/inst_delay>:<IODELAY2_IODELAY2>.  For DELAY_SRC programming ODATAIN or IO the ODATAIN input pin of IODELAY2 must be connected.

 

View solution in original post

37 Replies
Scholar austin
Scholar
13,964 Views
Registered: ‎02-27-2008

m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Adventurer
Adventurer
13,960 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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 ...

0 Kudos
Scholar austin
Scholar
13,953 Views
Registered: ‎02-27-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Adventurer
Adventurer
13,951 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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

0 Kudos
Xilinx Employee
Xilinx Employee
13,941 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

 

0 Kudos
Adventurer
Adventurer
13,912 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

 

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 ...

 

Snap 2012-11-28 at 14.55.18.png

0 Kudos
Xilinx Employee
Xilinx Employee
13,905 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

 

 

dcm_deskew.jpg

0 Kudos
Adventurer
Adventurer
13,892 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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:

 

Photo 28.11.2012 17 06 48.jpg

 

 

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; >

 

0 Kudos
Xilinx Employee
Xilinx Employee
13,885 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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>

0 Kudos
Adventurer
Adventurer
9,750 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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:

 

bifgmux.png

 

 

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...

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
9,724 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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

 

0 Kudos
Adventurer
Adventurer
9,697 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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!

 

 

0 Kudos
Xilinx Employee
Xilinx Employee
9,681 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

 

 

0 Kudos
Adventurer
Adventurer
9,667 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

" 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:

 

 

Snap 2012-12-05 at 13.37.40.png

 

 

 

 

Snap 2012-12-05 at 13.37.56.png

 

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

0 Kudos
Xilinx Employee
Xilinx Employee
9,653 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

Adventurer
Adventurer
9,648 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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 :)

0 Kudos
Xilinx Employee
Xilinx Employee
9,644 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

0 Kudos
Adventurer
Adventurer
9,641 Views
Registered: ‎12-21-2011

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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

0 Kudos
Xilinx Employee
Xilinx Employee
9,637 Views
Registered: ‎06-20-2008

Re: m,Re: Unroutable design - ERROR:Route:472

Jump to solution

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.

 

0 Kudos
Adventurer
Adventurer
9,702 Views
Registered: ‎12-21-2011

Here is the source, top level file is the m_k40_top   Tha...

Jump to solution

Here is the source, top level file is the m_k40_top

 

Thanks, it's really nice of you:)

0 Kudos
Xilinx Employee
Xilinx Employee
9,694 Views
Registered: ‎06-20-2008

Re: Here is the source, top level file is the m_k40_top Tha...

Jump to solution

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.

Adventurer
Adventurer
9,678 Views
Registered: ‎12-21-2011

Re: Here is the source, top level file is the m_k40_top Tha...

Jump to solution

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

 

Photo 07.12.2012 12 00 14.jpg

 

 

 

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?

0 Kudos
Xilinx Employee
Xilinx Employee
9,664 Views
Registered: ‎06-20-2008

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

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.

 

 

0 Kudos
Adventurer
Adventurer
9,662 Views
Registered: ‎12-21-2011

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

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

0 Kudos
Xilinx Employee
Xilinx Employee
9,652 Views
Registered: ‎06-20-2008

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

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.

 

 

0 Kudos
Adventurer
Adventurer
9,626 Views
Registered: ‎12-21-2011

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

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:

 

Photo 11.12.2012 13 42 05.jpg

 

 

Link to full scale image

0 Kudos
Xilinx Employee
Xilinx Employee
9,619 Views
Registered: ‎06-20-2008

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

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.

 

Adventurer
Adventurer
9,615 Views
Registered: ‎12-21-2011

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution
i can invert clk from BUFG just like logic with the code or i need something fancier?
0 Kudos
Xilinx Employee
Xilinx Employee
9,612 Views
Registered: ‎06-20-2008

Re: Here is the source, top level file is the m_k40_top That...

Jump to solution

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)

0 Kudos