Dedicated CLK lines in CPLD

[valentin tihomirov]

I divide primaty CLK1 signal from chip input getting CLK2. CLK2 is submitted
to the remaining design. This should consume 2 GCLK (XC9572 CPLD) lines.
However fitter tells me that only 1 of 3 3 GCLK lines used. Design seems to
function properly. ChipViewer does not want to show me chip internals.

 

[tbx135]

I divide primaty CLK1 signal from chip input getting CLK2. CLK2 is
submitted
to the remaining design. This should consume 2 GCLK (XC9572 CPLD) lines.
However fitter tells me that only 1 of 3 3 GCLK lines used. Design seems
to
function properly. ChipViewer does not want to show me chip internals.

If CLK1 is connected to the GCK line and drives the FF used in the divider.
CLK2 is the output of the FF and is sent through-out the device as a product
term clock. This is not a good design practice as routing resources
introduce skew, even in CPLD's. CLK2 needs to be assigned to an internal GCK
resource by instantiating the global clock component.

 

[Karl Olsen]

valentin tihomirov <valentin_NOSPAM_NOWORMS@abelectron.com> wrote:

I divide primaty CLK1 signal from chip input getting CLK2. CLK2 is
submitted to the remaining design. This should consume 2 GCLK (XC9572
CPLD) lines. However fitter tells me that only 1 of 3 3 GCLK lines
used. Design seems to function properly. ChipViewer does not want to
show me chip internals.

You can check the chip internals in the fitter report file (.rpt).

The only way to use the global clock nets is by inputting the clock on a GCK
pin. If using product term clocks, as you do now, consumes too may product
terms, you can output the divided clock on an output pin, and then
externally wire it to another GCK pin. If you aren't short of product
terms, you can just leave it as it is.

It is also possible to output the divided clock on a GCK pin, and then using
the same pin as the divided GCK input, wasting only one pin for this. The
fitter is very keen on "optimizing" this arrangement away, so you need to
tell it using attributes, that you really want the clock signal taken from
the pin (and using the global clock net), and not from the internal signal
that you output on it.

Karl Olsen

 

[valentin tihomirov]

If you aren't short of product
terms, you can just leave it as it is.

But poster above claims it is a bad design practice.

"Two architectors have ususally three opinions."

 

[tbx135]

But poster above claims it is a bad design practice.

Use product term clocks at your own risk. Every time you change the design
and re-fit, your skew and delay can be different. You will be using lots of
signal routing resources if the clock tree is large. All this will just get
worse as the design is enlarged.

Global clocking resources have guaranteed skew times and delays regardless
of how dense the design is packed.

 

[Karl Olsen]

tbx135 <tbx135@msn.com> wrote:

But poster above claims it is a bad design practice.

Use product term clocks at your own risk. Every time you change the
design and re-fit, your skew and delay can be different. You will be
using lots of signal routing resources if the clock tree is large.
All this will just get worse as the design is enlarged.

Global clocking resources have guaranteed skew times and delays
regardless of how dense the design is packed.

Using non-dedicated clock networks on FPGAs is certainly dangerous, and
Xilinx ISE issues a warning when you do. But in CPLDs like XC9500s, routing
should be predicable as it is done through a regular routing matrix, unlike
FPGAs. And ISE gives no warning when using product term clocks. If they
weren't safe to use, it would be a major fault of the fitter not to warn
about them. In my XC9500XL designs using many product term clocks, I
haven't seen any problems with them.

A global clock network, while saving a product term in each macrocell and
giving a faster Tco, isn't very flexible as it can only be driven from the
three physical GLK pins, and not from internally generated signals. So in
many designs, product term clocks are very handy. Since the fitter readily
uses them, it would be a pity if you had to look through the .rpt file for
flipflop equations where the clock wasn't commented by "// GCK".

But all this is circumstantial evidence. Could someone from Xilinx please
comment on whether product term clocks in XC9500 are safe or unsafe?

Karl Olsen