clock gating

I'm not quite sure what you mean:

The output is clock_gated. According to the report, it is assigned on a global clock network which is ok for a clock.

Still I get the design rule violation.

Where can I check for the clock gate ?

Thanks

Peter

--- Quote Start ---

I'm not quite sure what you mean:

The output is clock_gated. According to the report, it is assigned on a global clock network which is ok for a clock.

Still I get the design rule violation.

Where can I check for the clock gate ?

Thanks

Peter

--- Quote End ---

Hi Peter,

I tried to setup a small project with your clock gating, unfortunately I don't get your warning. Can you look into the project and maybe modify it, so that the warning occurs ?

Thanks for the sample project. It works and does not show the warning.

I think the warning is caused by something else in the project.

I reviewed my digital design and like to ask the experts here for there input/remarks.

The following scenario:

An internal state machines creates a couple of signals to trigger events in other modules. So far I used this signals as clocks in the other modules and in the main data path. This was working fine. However, this generated clock is not synchronized with the original clock driving the state machine.

My questions:

1.) Can someone suggest good background literature and best practice regarding this?

2.) I took the approach to gate the main clock with the signals generated by the state machine. This should keep the clock synchronized. But now I run into trouble during the timing analysis. Quartus recognized that the gated clock is derived from the main clock and issues setup/hold violations with respect to the main clock. I think the multi cycle statement could solve this, as there is some time between the input into the data path and the actual usage of its output; both are triggered by gated clocks with a fixed number of main clock cycles between them. How does the multi-cycle statement work?

Can is be automatically attached to node driven by a specific gated clock?

I think something like: From clock_cycle1 to clock_cycle2 are always 5 cycles of the main clock.

3.) Are there other methods to do this more efficiently and properly?

Thanks

Peter

--- Quote Start ---

Thanks for the sample project. It works and does not show the warning.

I think the warning is caused by something else in the project.

I reviewed my digital design and like to ask the experts here for there input/remarks.

The following scenario:

An internal state machines creates a couple of signals to trigger events in other modules. So far I used this signals as clocks in the other modules and in the main data path. This was working fine. However, this generated clock is not synchronized with the original clock driving the state machine.

My questions:

1.) Can someone suggest good background literature and best practice regarding this?

2.) I took the approach to gate the main clock with the signals generated by the state machine. This should keep the clock synchronized. But now I run into trouble during the timing analysis. Quartus recognized that the gated clock is derived from the main clock and issues setup/hold violations with respect to the main clock. I think the multi cycle statement could solve this, as there is some time between the input into the data path and the actual usage of its output; both are triggered by gated clocks with a fixed number of main clock cycles between them. How does the multi-cycle statement work?

Can is be automatically attached to node driven by a specific gated clock?

I think something like: From clock_cycle1 to clock_cycle2 are always 5 cycles of the main clock.

3.) Are there other methods to do this more efficiently and properly?

Thanks

Peter

--- Quote End ---

How many trigger events do you have ? A better way is to use this signals as enable signals for the FF instead as a clock. Maybe you can try the "gated" clock conversion in Quartus 8.1.

--- Quote Start ---

How many trigger events do you have ? A better way is to use this signals as enable signals for the FF instead as a clock. Maybe you can try the "gated" clock conversion in Quartus 8.1.

--- Quote End ---

About 5 trigger signals. Good idea I tried it and it works perfectly. There is one more thing;

I think I got the idea of the multicycle statement now, but I think it is quite difficult to use in practice.

Please correct me, if I'm wrong but so far it is only possible to define this statement between registers. Is there a way to apply the statement to all registers driven by certain gated/enabled clocks?

This would ease the use significantly.

Thanks

Peter

--- Quote Start ---

About 5 trigger signals. Good idea I tried it and it works perfectly. There is one more thing;

I think I got the idea of the multicycle statement now, but I think it is quite difficult to use in practice.

Please correct me, if I'm wrong but so far it is only possible to define this statement between registers. Is there a way to apply the statement to all registers driven by certain gated/enabled clocks?

This would ease the use significantly.

Thanks

Peter

--- Quote End ---

Hi Peter,

which timing Analyzer do you use ?

--- Quote Start ---

Hi Peter,

which timing Analyzer do you use ?

--- Quote End ---

TimeQuest Timing Analyser

--- Quote Start ---

TimeQuest Timing Analyser

--- Quote End ---

# The following multicycle applies to all paths ending at registers clocked by clk

set_multicycle_path -to [get_clocks clk] 2

I found this in the QuartusII Handbook (Chapter TimeQuest Timing Analyzer). There a

lot more API's. :)

For Gated clocks you can specify generated_clocks based on the edges of the masterclock.

1 is first rising edge

2 is first falling edge

3 is second rising edge

4 is second falling edge

5 is third rising edge

......

1 3 5 defines a clock with half of period of the master clock.

--- Quote Start ---

A better way is to use this signals as enable signals for the FF instead as a clock.

--- Quote End ---

Avoid using gated clocks. A better solution is clock enables as pletz suggested. For more information about the things to consider with gated clocks, see http://www.alteraforum.com/forum/showthread.php?t=2388.