difficult to build counter, some help please : (

schrieb im Newsbeitrag news: snipped-for-privacy@l41g2000cwc.googlegroups.com...

Clock gating is not neccessary. A clean way would be to use a 2*5,37 Mhz Clock and divide by two or 6. This can be done easyly and also clock switching is easy (glitch free), since you can register the output. If you have just a 5.37 MHz clock, you need to MUX between the clock itself and a divided by 3 Version. Be carefull, clock MUXes can inhibit glitches if done improperly. But there are glitch free clock muxes. Peter had a small article about this in Xcell years ago.

Regards Falk

It all depends whether you want to switch dynamically, i.e. maintaining the count value, or if this is a way of distinguishing between two different modes of operation, with the count reset in-between. In the latter case, you can just mux the clock. In the former case you have to be far more careful to avoid unintended glitches (extra clocks) while switching. I have a 2-flip-flop glitch-free multiplexer that I can send you if you need it. Peter Alfke snipped-for-privacy@xilinx.com

Hello, first thanks for the hints. I just coded the article "xl24- trouble-free switching between clocks".. First this is still clock gating, but with glitches removed. XST still sees it as being combinational. I think this would fit my application, where I made a 14-bit counter work in one case, clocked by 5.37mhz, and in the other case at 1.79mhz.

What happens when I put the attribute clock_source in the vhdl code? is it just to remove the warning from xst, or will it, by some sort of magic, route the output from the "clock selector" block, to the clock routing in my FPGA?

And to the question of Peter, I need to be able to switch between clocks arbitrarily, while the counter still holds the count, and hence incrementing at the new rate.

Thanks so much for the hints! Jac

schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

If this is for a counter inside the FPGA, DONT use clock gating. Use a CE (clock enable) instead. Because a CE input is a clean synchronous design, where the counter can interact with the other logic without any trouble. If you do clock gating, the counter is not driven by the global clock net (in opposite to the rest of the logic) and so interaction is going to be troublesome (skew, hold time problems). Do clock gating only when there is REALLY no other way. Ususally there is a clean synchronous (single clock) solution.

It will just remove the warning, the basic problem will persit.

So even more a argument for CE instead of gating. Go for it.

Regards Falk

Well, ell. CE is not such a good solution when the two clocks are unrelated or have an uncertain phase relationship. The worst one could do is to feed an asynchronous CE into a long counter. First synchronizing the CE to the faster clock domain, before using it, is better. It is hard to make a definitive suggestion when the real design is unknown... What does the counter output do, how many clock domains are involved, etc? Peter Alfke

Another solution, on admittedly sparse information, could be to have two counters, and then mux the outputs ? Seems any system to MUX clocks will need special care to avoid extra clocks, or dangerously narrow clocks. Because the speed is relatively slow, you could preface the MUX with a faster clocked state engine, that conditions both clocks, and extracts genuine edges. These edges becomes the CE to the main counter.

-jg

I do not want to sound obnoxious, but "my" clock multiplexer is safe. It does not create a glitch nor a runt pulse, provided metastability settles within one half period. And that is practically guaranteed: at the quoted clock rates, MTBF is many billion times longer than the expected life of the universe... And as I wrote before, no matter how you design with two clocks of unknown phase relationship, you have to deal with metastability, and everything becomes probabilistic... Peter Alfke

Hello, some feedback about the counter we discussed sometime back. I did test my counter with the clock selector circuit from Peter. It works in rtl simulation and hence, I went directly to FPGA testing, with a chipscope core to give me feedback on the actual implementation. It actually failed, as I was thinking, in hardware.

It sound reasonable to say that in order for this circuit to be actually usable, we either need to put constrains on the clock netlists, or to manually route the clock selector circuit so that it minimizes the delay to the counters it is driving, or, as I did, to use a bufg component so as to use the FPGA chip's clock plane.

cheers Jacques

Peter Alfke wrote:

at

schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

Hmm, bad.

As far as I remeber it was a counter which should run at 5.something MHz or

1/3 of this. I just cant believe that this is a real design challenge? Whats the point? Just use a BUFG for clock distribution and create a CE (clock enable) which is either always HIGH or HIGH every 3rd clock cycle. Works right out of the box.

Regards Falk

And what if I have limited resources available to me. It will be fairly straight forward to use bufg, but currently, im using 4/4 of them on my old virtex chip.

cheers Jacques

schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

You can also use local routing. Give the constaint

NET my_poor_clock uselowskewlines;

in the ucf.

If you dont have too much logic on that net (say a two dozens of FlipFlops), the P&R can use secondary routing ressources to route the clock. The result will be reliable, the only difference is that the clock delay is usually longer then on a bufg.

Regards Falk