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.
submitted
to
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.
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
But poster above claims it is a bad design practice.
"Two architectors have ususally three opinions."
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.