cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
9,965 Views
Registered: ‎03-21-2011

How to constrain BUFGCTRL to top half of chip?

Design is a Virtex5 using ISE12.1.  I have a critical clock on the north of the chip and a debug clock on the south of the chip (can route slower if needed) that go into a BUFGMUX.  Knowing that not all pins can reach all clock elements I added in the UCF a

NET "DebugClk" CLOCK_DEDICATED_ROUTE = FALSE;

Or else there is no valid placement.  However, when I do this the tools still place the BUFGCTRL in the Debug side of the chip and errors out!  Despite there being a valid choice to put it elsewhere!  I get the dreaded:

 

ERROR:Place:592 - A clock IOB / BUFGCTRL clock component pair have been found that are not placed at an optimal clock IOB / BUFGCTRL site pair. The clock IOB component <CritClk> is placed at site <D15>. And the corresponding BUFG component <ClkMux/BUFGCTRL> is placed at site <BUFGCTRL_X0Y8>.....

 

So apparently the tool can't figgure out that it needs to use a northern element.  A hard coded LOC constraint

INST "ClkMux/BUFGCTRL" LOC = BUFGCTRL_X0Y31;

 does work, but this seems heavy handed.  I should be able to let it use any element above Y16.

 

But when I try

INST “ClkMux/BUFGCTRL” AREA_GROUP=AG_CM;

AREA_GROUP “AG_CM” RANGE= BUFGCTRL_X0Y16:BUFGCTRL_X0Y31;

 in my UCF I get the same exact error message as above!  What is wrong with my area constrait that it gets ignored by the tools which still try to use site X0Y8 anyway????  Can not find any translate/map messages that indicate anything is wrong with the area constraint syntax either.

0 Kudos
9 Replies
Highlighted
Scholar
Scholar
9,962 Views
Registered: ‎07-01-2008

I don't think that range constraints are supported on BUFGCTRLs. I suggest that you run with the specific constraint that you have already found that works. There must be something complicated in your clock structure that the clock placer can't find a legal solution to an unconstrained design.

0 Kudos
Highlighted
Participant
Participant
9,956 Views
Registered: ‎03-21-2011

http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_1/cgd.pdf page 69 third line of the table claims BUFGCTRL_XnYn is supported for virtex4,5,6. (also page 71 of the 13.3 manual, which has a bit more clear explinations IMO.)

 

Would using a CLOCKREGION_X#Y#:CLOCKREGION_X#Y# range work better or as a work-arround?  Does a BUFGCTRL even exist within a clock region?  Also, the guide just says "varies by device" but I can't find any listings of clock regions for various V5 devices.

 

(Clocking for the design is just a high speed CritClk and a non-critical DebugClk into a BUFGMUX, with the debug marked as able to use non clock routing.  DebugClk also drives a separate BUFG, but that goes to different, unrelated logic and isn't causing problems.)

 

0 Kudos
Highlighted
Scholar
Scholar
9,941 Views
Registered: ‎07-01-2008

There are a lot of site types included in that table that I know aren't supported for range constraints. All of the I/O sites types won't work. STARTUP is included and there's only one per device.

0 Kudos
Highlighted
Scholar
Scholar
9,937 Views
Registered: ‎07-01-2008

If you write the constraint as a list of sites (comma seperated) instead of a range, it should work.

0 Kudos
Highlighted
Participant
Participant
9,910 Views
Registered: ‎03-21-2011

A list of BUFGCTRL sites gets rejected by ISE v12.1 mapper as not a valid range. It will accept without complaint a range of BUFGCTRL, a range of clock regions (X0Y3:X1Y4), and it will accept a list of clock regions too. But anything that gets accepted without a syntax or "not a valid range" errors gets ignored and errors out when mapper tries to use a bottom-half BUFGCTRL. Sticking with the manual LOC constraint at X0Y31. Not so many clocks in the design that there isn't tons of freedom for the mapper/placer to do optimal things with the remaining 31sites. Thanks.
0 Kudos
Highlighted
9,851 Views
Registered: ‎07-07-2010

hi can i constraint the bufgctrl?

 

i am constraining as follows is this correct?

 

INST "DCM_ADV_INST/CLK0_BUFG_INST"   LOC = BUFGCTRL_X0Y18;


 

 

0 Kudos
Highlighted
9,844 Views
Registered: ‎07-07-2010

i got the constraint

 

thanks

0 Kudos
Highlighted
Scholar
Scholar
9,833 Views
Registered: ‎07-01-2008

A BUFGCTRL list constraint does in fact work. I have tested the following syntax and confirmed the result:

 

INST "IBUFGDS_0_cb" LOC = BUFGCTRL_X0Y24, BUFGCTRL_X0Y25, BUFGCTRL_X0Y26, BUFGCTRL_X0Y27, BUFGCTRL_X0Y28, BUFGCTRL_X0Y29, BUFGCTRL_X0Y30, BUFGCTRL_X0Y31;

0 Kudos
Highlighted
Scholar
Scholar
3,646 Views
Registered: ‎06-23-2014

FYI this post helped me.

 

By the way, WHERE PLEASE can I find a doc telling where in the Virtex-5 all these resources are located?  I searched but couldn't find it.

 

I'm using ISE 14.7 and a Virtex-5.  In the past, I had placed a GT component in a PCIe configuration.  That all built fine for both PCIe stack down and PCIe stack up configurations of my project.  I then did bunch more development in the PCIe stack down configuration.  When I returned to the PCIE stack up configuration, I started getting an error that the GT component was in the top half while the BUFGCTRL was in the bottom half.

 

I added a line comparable to 

"INST "IBUFGDS_0_cb" LOC = BUFGCTRL_X0Y24, BUFGCTRL_X0Y25, BUFGCTRL_X0Y26, BUFGCTRL_X0Y27, BUFGCTRL_X0Y28, BUFGCTRL_X0Y29, BUFGCTRL_X0Y30, BUFGCTRL_X0Y31

and the build worked.

 

Fortunately, the example seems to have included a bunch of top half locations.  Great for me.  I still don't know where doc is, however, to have found that if the example were not already perfect for me.

0 Kudos