Programmable watchdog in FPGA

The lpm_counter was configured as aload, therefore, the clk_en wasn't fed directly into any register..therefore it doesn't show up on the global signal list...funny thing is that if I don't use this clk_en, but using it directly as a divided down clock to fed to this lmp_counter. I have timing issues (setup time/removal time violations)...now it's not used as a clock anymore (rather, it is used as a clock_en) and I am trouble free?

--- Quote Start ---

It is normal for a timing simulation to have glitches on signals if any combinational logic is involved. (I would not expect a glitch on a signal that is driven directly by a register.) As long as the signal is used only synchronously (as is the case for a clock enable) and there are no setup or hold violations, the glitches don't matter.

Are you saying that the clock enable signal is listed correctly as a clock enable in the "Control Signals" table but just not listed as a global? If you are saying it was not listed at all, then did you look only for the name you expected? The name might be different from what you expect. If you are using HDL, you need to code in a style that enables synthesis to recognize the signal in the HDL that you intended to be a clock enable. The Quartus handbook has a chapter on coding guidelines that shows the correct way to code the registers that use the clock enable. If you are saying the signal was identified by the Fitter as a clock enable but just wasn't listed as global when you expected it to be global, then there might be a problem with your "Global Signal" assignment if that's what you are using (verify that the Assignment Editor doesn't have a question mark by the signal name). In TimeQuest you can do something like "report_timing -setup -from [get_registers <name_of_register_driving_clock_enable>]" to see the clock enable paths. For one of these, look at the data arrival path. If you are using global routing, there will be a clock control block in the path.

--- Quote End ---