Clock Enable to Clock Constraint

--- Quote Start ---

I have a design with clock enables going to almost all the flops in the design.

I am worried that the clock enable may arrive late causing timing issues.

How do I constrain the clock enable to detect this violation in quartus?

I can't come up with the sdc syntax.

On a related note, should i also set max fanout constraint to prevent this so that the source

gets duplicated.

--- Quote End ---

Either you or the tool can do replication. You can also set your max fanout to update default value. But I will worry about all these things when the tool fails to meet timing or the design does not work. We depend on these tools and make our living on them and the guys behind them have pre - done much of the work for us to be automated.

If however you do run into fanout trouble then your thinking is right. This is more likely with reset signal than with clock enable.

--- Quote Start ---

Either you or the tool can do replication. You can also set your max fanout to update default value. But I will worry about all these things when the tool fails to meet timing or the design does not work. We depend on these tools and make our living on them and the guys behind them have pre - done much of the work for us to be automated.

If however you do run into fanout trouble then your thinking is right. This is more likely with reset signal than with clock enable.

--- Quote End ---

hello @kaz, yes design doesn't work and i see no timing violations. hence i was trying to add a constraint on the enable to make sure enable reaches the flop on time.

So how do i write a constraint on the enable of a flop in SDC. thanks for your help.

--- Quote Start ---

hello @kaz, yes design doesn't work and i see no timing violations. hence i was trying to add a constraint on the enable to make sure enable reaches the flop on time.

So how do i write a constraint on the enable of a flop in SDC. thanks for your help.

--- Quote End ---

To me, the fact that you passed timing excludes clock enable fanout.

But if you want peace of mind then you can either replicate your enable by hand or add maxfan constraint

To replicate you just produce as many clockenables as you wish i.e. at the point you generate clockenable then similarly generate clockenable2,clockenable3 etc on same logic without latency from clockenable itself.

maxfan attribute can be added to an signal at declaration:

ATTRIBUTE maxfan of clockenable : SIGNAL is 100;

--- Quote Start ---

To me, the fact that you passed timing excludes clock enable fanout.

But if you want peace of mind then you can either replicate your enable by hand or add maxfan constraint

To replicate you just produce as many clockenables as you wish i.e. at the point you generate clockenable then similarly generate clockenable2,clockenable3 etc on same logic without latency from clockenable itself.

maxfan attribute can be added to an signal at declaration:

ATTRIBUTE maxfan of clockenable : SIGNAL is 100;

--- Quote End ---

hi @kaz, appreciate the response! Don't I still need a constraint in SDC that says clock enable signal arrives before the next active edge of the clock? OR are you saying

timequest is smart enough to figure that out (wow!) Basically I have a gigantic FSM clocked by the same clock, the output of this FSM is providing the enables to all

my other flops (roughly 70% of the design flops). So If there is a routing delay on clock enable that can cause a violation, I want timequest to flag this with a negative slack.

so this really is my fundamental question: Will timequest flag clockenable propagation delays automagically without an explicit constraint (something like set_max_delay -from <clock-enable-source> -to <what?> period_of_active_clock)

--- Quote Start ---

Once you constrain the clock signals (create_clock or create_generated_clock), TimeQuest will automatically analyze any paths between registers, including the clock enables. No point in adding set_max_delay constraints.Sometimes, you can/need to add multi-cycle constrains to _relax_ the analysis.

--- Quote End ---

Indeed the tool should check all paths between registers.

clock enable path will all be checked provided either it is generated internally on the clock or if it input pin then you must use set_input_delay correctly. If it is asynchronous then you are in trouble and will need to synchronise it and manage the resulting latency.

We should first give the tool a go and if it fails to meet timing then we got so many options to interfere but this is a job not for beginners really because in their case it is more likely that their design is the cause of trouble and it will be better to identify the issues than to beat the tool's head.