Xilinx Synthesis Attribute usage

My thought: if you need a BUFG for internal logic, instantiate it. You can find the BUFG primitive in the libraries guide.

Yeah that would be pretty easy to do, and I considered that. In fact this synthesis attribute is not that important, but I'd like to know how to implement it, so that the tools pick up the directive.

-J

Did you look at other verilog examples? I'm far from a verilog expert, but to me the above statement looks like you are using the counter outputs as a clock.

Maybe this page will help you a bit further:

Yes I am using the counter outputs as a clock, and cnt[23] will be fed into the clk input of the flop thats going to be synthesized. Based on the example of xilinx synthesis constraints I either put the synthesis attribute as a verilog comment, or in a xilinx constraints file.

I don't think using a bit from a counter is a bad thing to do for a clock and that is what I want to do (provided if I make sure the tools know its going to be a clock) in digital logic, but again its not so much the point that I am using the counter msb as a clock, then how do I get the xilinx tools to pick up my synthesis constraints.

I could instantiate a BUFG primitive aswas mentioned but, I'd like to learn why my synthesis attribute is being ignored, or not picked up by the synthesis tool.

-J

further:

The answer should be somewhere in the log files. However, the number of BUFG elements is limited (because they drive low skew global clock nets). You can use the counter outputs as a local clock without the BUFG.

It is a good idea to also specify the period of the local clocks as well so the routing tools can do a proper placement.

further:

BUFGs are not the only limited clocking resource: most devices are further divided into clocking regions and some devices provide as little as two regional clock trees.

Depending on how much logic depends on the modified clock, local distribution using hex/long lines can be sufficient but may require some careful constraining to avoid race conditions and all manners of weird issues.

When in doubt, synthesis logs are indeed the first thing everybody should look into to determine what went according to plan, what needs improvement and what messed up.