Frequency divisors

In my project, which uses an Altera Cyclone EP1C12, I need to generate a lot of different frequencies, such as f=10Mhz, 1MHz, 2.5MHz, 250kHz, etc. I used counters but quartus' design assistant complains that I'm using gated clocks. Are there better solutions than counters to achieve what I need? Or better ways to implement frequency divisors? Thank you in advance, BQ

Reply to
BQ
Loading thread data ...

"BQ" schrieb im Newsbeitrag news:mkfue.16513$ snipped-for-privacy@twister2.libero.it...

The counters are right, but don't use the outputs as real clocks. Run everything at the highest frequency (I guess 10 MHz) and use clock enables for the slower parts of the logic. Keeps things easy and safe.

Regards Falk

Reply to
Falk Brunner

The problem is when you start using the counter bits as clocks. If your clock is simply one of the counter's bits, this is not really a gated clock, there is no problem in terms of that there is no ambiguity of metastability.

Honestly I really hate this thing in Quartus as many other warnings, which are far from reality.

Try using the same highest clock and counter bits as "clock enable"s. If you designing a UART-like application, this is the way to go.

Vladislav

Reply to
Vladislav Muravin

Let's look at the basics: If you have an incoming clock (say 10 MHz in your case) and you want to derive any clock from it, these derived clocks will inevitably be delayed from the original clock, even when you are smart and avoid ripple counters and clock gating. Also, the distribution of your many clocks might use local (instead of global) routing. Whatever you do, you end up with a sloppy clock structure, which invites hold-time problems when the different clock domains have to interact. (If they don't, you really have no problem.)

Dumb clock gating can create glitches, mixing non-synchronous clocks can create metastability problem, but even the most careful clock selection scheme is dangerous.

Clock Enable avoids all these problems (except the metastability). That's why we all favor CE (except for its higher power consumption). Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Let's look at the basics: If you have an incoming clock (say 10 MHz in your case) and you want to derive any clock from it, these derived clocks will inevitably be delayed from the original clock, even when you are smart and avoid ripple counters and clock gating. Also, the distribution of your many clocks might use local (instead of global) routing. Whatever you do, you end up with a sloppy clock structure, which invites hold-time problems when the different clock domains have to interact. (If they don't, you really have no problem.)

Dumb clock gating can create glitches, mixing non-synchronous clocks can create metastability problem, but even the most careful clock selection scheme is dangerous.

Clock Enable avoids all these problems (except the metastability). That's why we all favor CE (except for its higher power consumption). Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

In HDL you can do something like this:

module clock_generator(input clk, input resetN, output reg CE_out); parameter clk_divisor = 1; reg [3:0] cnt; always @ (posedge clk or negedge resetN) begin if (~resetN) begin cnt

Reply to
ddrinkard

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.