How to make timing constraint in this case??

[Altera_Forum]

Hi all, 

 I've used a counter to make a clock enable such that I could get a new clock with divided frequency. The waveform is shown as below. Because there must be some clock skews for the counter's clock, it is possible that the second rising edge of the counter's clock arrives late and is not enabled.   I've figured out two ways of constraining. The first is use set_clock_uncertainty from {counter's clock} -to {counter's clock} -setup XXX  The second way is make the clock enable signal a generated clock and make sure they have no setup violations.   Which one is the better way do you think?   ____-----_____-----_____-----_____-----_____-----___counter's clock ____-----------____________________________--------clock's enable

[Altera_Forum]

Could anyone tell me how to put the offset in this case for new clock(when I am trying to constrain the genenerated clock)? 

The duty cycle should be 33.33, and offset and phase are all 0, right?

[Altera_Forum]

I am afraid you are on the wrong path. you don't generate a clock like that. Normally you avoid generating clock from logic gating as you get all sorts of problems. 

 You are supposed to use the enable as enable not as clock. i.e. don't connect it to clock port of registers. Then you don't need to worry about timing as it will be synchronised with clk that generates it from the counter.

[Altera_Forum]

Yes, I am using it as an enable; 

I write the verilog code like this:   always@(posedge oclk or negedge rst) begin if(~rst_n) begin ... end else if(oclk_enable) begin ... ... end else begin ... end   end   Is it the right way? But I think because the oclk has some sort of skew(even if it's generated out of a pll), it is still possible that some branchs of oclk rising edge arrive late and miss the enable.

[Altera_Forum]

That looks right to me. 

You don't have to worry about the clock edge issues and skew. Because clock generates enable (e.g '1' for one period ,will be read as '1' on next clock edge and so on).

[Altera_Forum]

yes, but I still think it is possible that clock arrived very late for some particular registers but the enable's falling edge arrived early than that.  

So the clock rising edge that was supposed to be enabled failed being enabled.

[Altera_Forum]

The enable signal is still a register right, it is possible that the enable is driven to low by a early clock rising edge. And enable signal then is propagated to another register and that register received a late clock rising edge. That caused the late clock rising edge failed to be enabled at that register

[Altera_Forum]

if a clock edge happened to be late then enable generated will be late. because enable is generated locally on register (of counter). So why worry, both would be late and next clock edge will be late and will read the late enable correctly. It is safe and proven for decades.

[Altera_Forum]

Yes, I know what you mean kaz. 

But it sounds to me like you are saying the clock edge are always arriving different registers at the same time.   I am thinking of the case for the path to the counter register, we get an early clock. But for the path to another register which will need to be clock-enalbed, it gets a late clock edge.

[Altera_Forum]

the tool (TimeQuest) will report on any violations. Normally inside fpga clock is taken care of by global lines so don't worry if tool passes timing.