Project on Basys2 not compiled

[Valentin]

I try use DCM in Basys2 board. But when I compile project I have an error:

ERROR:Place:962 - A DCM / BUFGCTRL clock component pair have been found that are not placed at an optimal DCM / BUFGCTRL
   site pair. The DCM component <DCM0> is locked to site <DCM_X0Y1> and the corresponding BUFGCTRL component
   <BufgceClk80P180/BUFGMUX> is locked to site <BUFGMUX_X2Y1>. This will not allow the usage of the fast path between
   the DCM and the Clock buffer. 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.
   < PIN "DCM0.CLK2X180" CLOCK_DEDICATED_ROUTE = FALSE; >

Please help me to solve this error.

UncompiledBasys2UserDemo.zip

[hamster]

Hi!

I don't have ISE installed at the moment but have looked at the code....

I see you have the clocks buffered with BUFG - great stuff!

The most likely problem is this:

JA1 <= ClkOut80;
JA2 <= ClkOut80P180; 
 

It trys to take the signals from the clocking network and send them through the data output, which are designed to generic take data signals from the FPGA fabric. 

There is an easy solution to this - use a DDR output buffer to output a '0' through the first half of the cycle and a '1' through the second half (or the other way around for the P180 signal):

JA1_out_ddr: ODDR2
         generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") 
         port map (C0 => ClkOut80,  C1 => ClkOut80P180, CE => '1', R => '0', S => '0',
                   D0 => '0', D1 => '1', Q => JA1);

JA2_out_ddr: ODDR2
         generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") 
         port map (C0 => ClkOut80P180,  C1 => ClkOut80, CE => '1', R => '0', S => '0',
                   D0 => '0', D1 => '1', Q => JA2);

or if you want to avoid using the P180 clock (to save resources):

JA1_out_ddr: ODDR2
         generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") 
         port map (C0 => ClkOut80,  C1 => not ClkOut80, CE => '1', R => '0', S => '0',
                   D0 => '0', D1 => '1', Q => JA1);

JA2_out_ddr: ODDR2
         generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") 
         port map (C0 => not ClkOut80,  C1 => ClkOut80, CE => '1', R => '0', S => '0',
                   D0 => '0', D1 => '1', Q => JA2);

(Or you can swap D0 => '1', D1 => '0' for the second DDR, keeping C0 => ClkOut80, C1 => not ClkOut80)

Like I said, I don't have ISE in so can't test at the moment, so this might have some silly errors in it

You can avoid the "COMPONENT" declarations for primitives by using the library, which can avoid some errors...

library UNISIM;
use UNISIM.VComponents.all;

[Valentin]

Is it possible to solve problem without using ODDR and use BUFG?

[D@n]

Very possibly.  But, as an outsider, I'm not certain what your problem exactly is.

Are you trying to create two clockworthy outputs?  Then you'll want to use the BUFG and the ODDR.

Are you trying instead to produce two logic outputs?  Then you can get rid of the ODDR.

As for the BUFG, in general you want to place any clock coming into your design into a BUFG.  The BUFG places this clock onto a global clock network that has low latency throughout your design.  This is a good thing.  You will have better clock performance using the low-latency global clock network than you will have using a logic network.  This also works for just about any wire that has a large fanout--you can do better placing it on a global clock network.  The problem, of course is that there are only so many.  Hence I've seen these used for clocks, for chip enables, and for reset lines in practice but that's about it.

The biggest problem that I have with BUFG's is that they aren't standard VHDL or Verilog.  They are a vendor specific function that then becomes specific to the Vendor (Xilinx) that offers them, making it difficult to place your design onto another FPGA--such as Altera.  For this reason, I try to separate any BUFG, BUFH, etc. components from the rest of my design, placing them into my top level design file only.

Dan

[hamster]

8 hours ago, Valentin said:

Is it possible to solve problem without using ODDR and use BUFG?

Yes, you need to set  CLOCK_DEDICATED_ROUTE = FALSE in your constraints file, which allows the tools to run clock signals over the connections that usually transfer data signals.

[Valentin]

On 27.10.2016 at 10:54 PM, hamster said:

Yes, you need to set  CLOCK_DEDICATED_ROUTE = FALSE in your constraints file, which allows the tools to run clock signals over the connections that usually transfer data signals.

It works. Also may use bufg instead bugce.

[Valentin]

Please explain how software get link between DCM and corresponding BUFGCTRL.

ERROR:Place:962 - A DCM / BUFGCTRL clock component pair have been found that are not placed at an optimal DCM / BUFGCTRL
   site pair. The DCM component <DCM0> is locked to site <DCM_X0Y1> and the corresponding BUFGCTRL component
   <BufgceClk80P180/BUFGMUX> is locked to site <BUFGMUX_X2Y1>.

Wherefrom software take that element locked to site <BUFGMUX_X2Y1>? Why not, for example, <BUFGMUX_X1Y1> or <BUFGMUX_X0Y1>?

 

Do I understand correctly that I can export clock from DCM to only GCLK or *HCLK pins?

[jpeyron]

Hi Valentin,

I found a thread that deals with the error: place 962 here and gives a couple of different options for solutions and as for why locked to BUFGMUX_X2Y1 I believe it has to do with the quadrant clock line as described on pg 58 here. Hope this helps!

cheers,

Jon