IBUFG incapable of driving both CLKDLL and BUFG simultaneous

[Tony Dean]

I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.

Yes, I know I could use the CLK0 output through a BUFG instead of my
original clock, but my input clock can change speeds abruptly, which
will cause the CLKDLL to unlock and exhibit undefined behavior until
relocked. This makes me nervous and I'd rather just use my original
input, thank you.

A double mocha to he or she who can disprove my assertion.

-td

 

[Bob]

"Tony Dean" <td@emu.com> wrote in message
news:33aa9b10.0405171520.7798497d@posting.google.com...

I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.

Yes, I know I could use the CLK0 output through a BUFG instead of my
original clock, but my input clock can change speeds abruptly, which
will cause the CLKDLL to unlock and exhibit undefined behavior until
relocked. This makes me nervous and I'd rather just use my original
input, thank you.

A double mocha to he or she who can disprove my assertion.

-td

Tony,

You should be able to do this:

Connect the IBUFG to a BUFG. Connect the DLL input to the output of that
BUFG. Use another BUFG on the DLL's 90deg output.

Bob

 

[Tony Dean]

"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message news:<25eqc.5035$SZ4.1551@newsread2.news.pas.earthlink.net>...

"Tony Dean" <td@emu.com> wrote in message
news:33aa9b10.0405171520.7798497d@posting.google.com...
I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.

Yes, I know I could use the CLK0 output through a BUFG instead of my
original clock, but my input clock can change speeds abruptly, which
will cause the CLKDLL to unlock and exhibit undefined behavior until
relocked. This makes me nervous and I'd rather just use my original
input, thank you.

A double mocha to he or she who can disprove my assertion.

-td

Tony,

You should be able to do this:

Connect the IBUFG to a BUFG. Connect the DLL input to the output of that
BUFG. Use another BUFG on the DLL's 90deg output.

Bob

Hi Bob,
I agree, you should be able to do this. But you can't, or at least I
can't.
I'm getting a Place error on something as trivial as:

input_clk_buf : BUFGP port map (I=>extclk, O=>dll_in_clk);
dll_fb_buf : BUFG port map (I=>dllout_clk0, O=>dll_fb_clk);
dll90_buf : BUFG port map (I => dllout_clk90, O=> clk90);
dll : CLKDLL port map(CLKIN=>dll_in_clk, CLKFB=>dll_fb_clk,
CLK0=>dllout_clk0, CLK90=>dllout_clk90, etc.);

The BUFGP is just a IBUFG+BUFG, like you suggest.
I still get the following Place errors:

ERRORlace:106 - Could not find an automatic placement for the
following
components:
dll90_buf of type GCLK BUFFER is unplaced.
input_clk_buf/BUFG of type GCLK BUFFER is unplaced.
extclk of type GCLK IOB is unplaced.
dll_fb_buf of type GCLK BUFFER is unplaced.
dll of type DLL is unplaced.
ERRORlace:107 - Xilinx requires using locate constraints to preplace
such
connected GCLK/GCLKIO/DLL components.

Is it just me?
-td

 

[Gabor Szakacs]

td@emu.com (Tony Dean) wrote in message news:<33aa9b10.0405171520.7798497d@posting.google.com>...

I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

This seems strange because I just tried this on a Spartan II (not E)
with Foundation Schematics and it does let me connect the IBUFG to both
a DLL and a BUFG. I verified this in the FPGA Editor.

Unfortunately the Foundation tools don't support the Spartan IIE so
I tried the same thing with ISE 6.1i and found that it won't allow the
dual connection for the Spartan II as well as the IIE. That tells me
that the tools are doing this to you, not the part. I suggest opening
a web case with Xilinx

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.

Yes, I know I could use the CLK0 output through a BUFG instead of my
original clock, but my input clock can change speeds abruptly, which
will cause the CLKDLL to unlock and exhibit undefined behavior until
relocked. This makes me nervous and I'd rather just use my original
input, thank you.

A double mocha to he or she who can disprove my assertion.

-td

 

[Marc Guardiani]

Run the input clock to to clock pins. On one, use the CLKDLL. On the
other, use the IBUFG. (You didn't say you needed that other clock pin
for something else .

Tony Dean wrote:

I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.

Yes, I know I could use the CLK0 output through a BUFG instead of my
original clock, but my input clock can change speeds abruptly, which
will cause the CLKDLL to unlock and exhibit undefined behavior until
relocked. This makes me nervous and I'd rather just use my original
input, thank you.

A double mocha to he or she who can disprove my assertion.

-td

 

[Ray Andraka]

You may have to put LOC constraints on the BUFGs and CLKDLLs. The automatic placer doesn't do so hot a job figuring out
which BUFGs should be next to which CLKDLLs. The usual result is that error message.


--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759

 

[GSM User]

There is a bug in ISE 6.x. You should manually LOC the IBUFG, BUFGs,
and DLL. LOC the BUFGP on the same side as input clock and LOC DLL, FB
BUFG and CLK90 BUFG on the opposite side. Good luck.

Marc Guardiani <marc@guardiani.com> wrote in message news:<Wmyqc.38565$vz5.34463@nwrdny01.gnilink.net>...

Run the input clock to to clock pins. On one, use the CLKDLL. On the
other, use the IBUFG. (You didn't say you needed that other clock pin
for something else .

Tony Dean wrote:

I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.

Yes, I know I could use the CLK0 output through a BUFG instead of my
original clock, but my input clock can change speeds abruptly, which
will cause the CLKDLL to unlock and exhibit undefined behavior until
relocked. This makes me nervous and I'd rather just use my original
input, thank you.

A double mocha to he or she who can disprove my assertion.

-td

 

[Tony Dean]

gsm1900user@yahoo.com (GSM User) wrote:

There is a bug in ISE 6.x. You should manually LOC the IBUFG, BUFGs,
and DLL. LOC the BUFGP on the same side as input clock and LOC DLL, FB
BUFG and CLK90 BUFG on the opposite side. Good luck.

Ray Andraka, P.E. wrote:
You may have to put LOC constraints on the BUFGs and CLKDLLs. The automatic placer doesn't do so hot a job figuring out
which BUFGs should be next to which CLKDLLs. The usual result is that

error message.

Marc Guardiani <marc@guardiani.com> wrote:
Run the input clock to to clock pins. On one, use the CLKDLL. On the
other, use the IBUFG. (You didn't say you needed that other clock pin
for something else .

Tony Dean wrote:

I want my master input clock, which is on a dedicated pin, to clock
most of my logic through a BUFG. I also want it to drive a CLKDLL so I
can use the CLK90 output.

After much head-banging I assert the following:
On a Spartan IIE, an IBUFG output cannot be routed to both a CLKDLL
input AND a BUFG input simultaneously.

Synplicity will synthesize this setup beautifully, but the Xilinx
Placer won't accept it.


A double mocha to he or she who can disprove my assertion.

-td

Problem solved! While Marc Guardiani deserves Honorable Mention for
his workaround, "GSM User" and Ray Andraka have the correct answer and
are entitled to the double mocha. I had discovered the same fix
shortly before and am pleased to have my findings confirmed. The clue
was in the hitherto-ignored error message:
ERRORlace:107 - Xilinx requires using locate constraints to preplace
such connected GCLK/GCLKIO/DLL components.
What this actually means apparently, is that Xilinx requires using
locate constraints to preplace such connected GCLK/GCLKIO/DLL
components.
Details for this can be found in the bowels of the Xilinx
documentation at:
http://toolbox.xilinx.com/docsan/xilinx6/books/data/docs/cgd/cgd0128_81.html#wp240140

I'll forward this little tip on to the Xilinx FAE whom I opened a
WebCase with, who apparently is not aware of this detail.

Mochas are payable in person at any cafe here in Santa Cruz. In the
event that transportation costs to and from Santa Cruz exceed the cost
of a double mocha ($3), please supply PayPal address to which said
amount can be promptly remitted.

Thanks to all,
-td