difficult to build counter, some help please : (

Hello ppl, I have a problem!

I need to build a counter that should be clocked depending on mode_pin

if mode_pin=0 it should be by cpu_clk (1.79MHZ)
if mode_pin=1 it should be by ppu_clk (5.37MHZ)

the way im thinking now is by gating the clock, and oring them. But is
there a more subtle way of achieving this?

Thanks
Jac

<jaxato@gmail.com> schrieb im Newsbeitrag
news:1108927608.785215.81110@l41g2000cwc.googlegroups.com...
> Hello ppl, I have a problem!
>
> I need to build a counter that should be clocked depending on mode_pin
>
> if mode_pin=0 it should be by cpu_clk (1.79MHZ)
> if mode_pin=1 it should be by ppu_clk (5.37MHZ)
>
> the way im thinking now is by gating the clock, and oring them. But is
> there a more subtle way of achieving this?

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
peter@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

<jaxato@gmail.com> schrieb im Newsbeitrag
news:1108934387.311998.7590@g14g2000cwa.googlegroups.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.

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.

> 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?

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

> 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.

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

Peter Alfke wrote:
> 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:
> 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

<jaxato@gmail.com> schrieb im Newsbeitrag
news:1109614802.159759.97770@f14g2000cwb.googlegroups.com...

> It actually failed, as I was thinking, in hardware.

Hmm, bad.


> 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.

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