domain crossing and clock synchronisation for a high frequency timer

Hi,

After all the clock generation stories, now comes the time
of time counting. So I want to implement a high-frequency
(<=100MHz ?) counter/timer that gets incremented by an auxiliary
input, and the problem comes from the clock domain crossing :
the low-frequency "acquire" signal must latch the counter
in another register but problems are likely to occur there.

I have figured a "latch enable" logic that is synchronised
with the incoming signal, plus a simple R/S toggle for handshaking
but I presume that there are far better solutions.
Can anybody hint me ?

yg
-- 
http://ygdes.com / http://yasep.org

On Wed, 02 Dec 2009 17:33:55 +0100
whygee <yg@yg.yg> wrote:

> Hi,
> 
> After all the clock generation stories, now comes the time
> of time counting. So I want to implement a high-frequency
> (<=100MHz ?) counter/timer that gets incremented by an auxiliary
> input, and the problem comes from the clock domain crossing :
> the low-frequency "acquire" signal must latch the counter
> in another register but problems are likely to occur there.
> 
> I have figured a "latch enable" logic that is synchronised
> with the incoming signal, plus a simple R/S toggle for handshaking
> but I presume that there are far better solutions.
> Can anybody hint me ?
> 
> yg

One of the best high-frequency counters I've done in an FPGA was a
ripple counter.  Unlike a synchronous counter, a ripple counter only
has a single point of entry that you need to gate, and so is safe for
any asynchronous input signal up to hundreds of MHz.

I wrapped a synchronous state machine around it that:
  1) clock enables the first flip-flop in the counter
  2) waits 1 second
  3) deasserts the clock enable
  4) waits 10 us for the ripple counter to settle out
  5) registers the now static outputs back into the clocked domain
  6) goto 1

The only problem is that you don't know for certain how long it will
take the ripple counter to settle out, but if you're willing to go way,
way overboard on that dead time then everything works like a dream.


-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Hi !

Rob Gaddi wrote:
> One of the best high-frequency counters I've done in an FPGA was a
> ripple counter.  Unlike a synchronous counter, a ripple counter only
> has a single point of entry that you need to gate, and so is safe for
> any asynchronous input signal up to hundreds of MHz.

My analog input seems to accept up to 65MHz which is
well within the reach of the spare A3P250 that I have around
(at 65MHz I can do a 32-bit adder and I only need a 27-bit counter).
The analog front-end will attenuate before the A3P misses a pulse.

> I wrapped a synchronous state machine around it that:
>   1) clock enables the first flip-flop in the counter
>   2) waits 1 second
>   3) deasserts the clock enable
>   4) waits 10 us for the ripple counter to settle out
>   5) registers the now static outputs back into the clocked domain
>   6) goto 1

hmmmm nice idea !

However this is going to waste 1/2 of the synchro pulses that I can get.
If I have a stable 1Hz signal from a cheap GPS, I'll have a
measurement only every 2 seconds. But abandonning the requirement
of a second buffered register is a simple and easy
way to avoid any glitch, sure !

> The only problem is that you don't know for certain how long it will
> take the ripple counter to settle out,
Oh, I could know (at least the max time with static timing reports),
and the display/treatment latency would be hiding it anyway.

> but if you're willing to go way,
> way overboard on that dead time then everything works like a dream.
No doubt about this :-)

Or if it's a 1Hz clock, assuming a perfect 50% duty cycle,
I can average during 1/2s and gate the input clock with the 1Hz directly.
But I would't bet much on this, with rise/fall time inequality...

thanks for the idea,
yg
-- 
http://ygdes.com / http://yasep.org

whygee <yg@yg.yg> wrote:
 
> Rob Gaddi wrote:
>> One of the best high-frequency counters I've done in an FPGA was a
>> ripple counter.  Unlike a synchronous counter, a ripple counter only
>> has a single point of entry that you need to gate, and so is safe for
>> any asynchronous input signal up to hundreds of MHz.
(snip)
 
>> I wrapped a synchronous state machine around it that:
>>   1) clock enables the first flip-flop in the counter
>>   2) waits 1 second
>>   3) deasserts the clock enable
>>   4) waits 10 us for the ripple counter to settle out
>>   5) registers the now static outputs back into the clocked domain
>>   6) goto 1
 
> hmmmm nice idea !
 
> However this is going to waste 1/2 of the synchro pulses that I 
> can get.  If I have a stable 1Hz signal from a cheap GPS, I'll have
> a measurement only every 2 seconds. But abandonning the requirement
> of a second buffered register is a simple and easy
> way to avoid any glitch, sure !

(snip)

Implement two of them, each runs on opposite cycles of the 1Hz
input clock.  If you wait 1/2 cycle of the 1Hz clock to settle,
you should be pretty safe against technology changes, too.

-- glen

glen herrmannsfeldt wrote:
> Implement two of them, each runs on opposite cycles of the 1Hz
> input clock.  If you wait 1/2 cycle of the 1Hz clock to settle,
> you should be pretty safe against technology changes, too.

that's what I thought when writing the last message...

however I went to eBay and found a distributor
for cheap and used OnCore receivers with a 1pps pin.
The doc says :

>> Pulse width is approximately 200 ms (=B1 1 ms),
>> i.e. the falling edge occurs approximately 200 ms
>> after the rising edge

so i'm stuck.

But anyway, a 1pps with 2s of delay between measurements
is still acceptable for me, as it's not used often.

> -- glen
yg
--=20
http://ygdes.com / http://yasep.org

On Wed, 02 Dec 2009 19:53:53 +0100
whygee <yg@yg.yg> wrote:

> glen herrmannsfeldt wrote:
> > Implement two of them, each runs on opposite cycles of the 1Hz
> > input clock.  If you wait 1/2 cycle of the 1Hz clock to settle,
> > you should be pretty safe against technology changes, too.
>=20
> that's what I thought when writing the last message...
>=20
> however I went to eBay and found a distributor
> for cheap and used OnCore receivers with a 1pps pin.
> The doc says :
>=20
> >> Pulse width is approximately 200 ms (=B1 1 ms),
> >> i.e. the falling edge occurs approximately 200 ms
> >> after the rising edge
>=20
> so i'm stuck.
>=20
> But anyway, a 1pps with 2s of delay between measurements
> is still acceptable for me, as it's not used often.
>=20
> > -- glen
> yg

Ahh.  You don't need a frequency counter, you need a period counter.
I'm assuming you're trying to use the 1 pps GPS pulse to determine what
frequency your clock is actually running at.  In that case, why not
just synchronize and rising edge detect the 1 pps pulse?

--=20
Rob Gaddi, Highland Technology
Email address is currently out of order

Rob Gaddi wrote:
> Ahh.  You don't need a frequency counter, you need a period counter.
> I'm assuming you're trying to use the 1 pps GPS pulse to determine what
> frequency your clock is actually running at.
right.
So I can adjust the tuning capacitor of the crystal.

>  In that case, why not
> just synchronize and rising edge detect the 1 pps pulse?
my idea was to synchronize the 1pps input (and detect the
rising edge of the pulse) to the crystal. Said another way :
the crystal clocks a free-running shift-register/delay line,
then some logic detects when the first N bits of the shift register
are 0 and the last a 1s. The output of the AND gate toggles
the latch enable of the output frequency register,
for the next cycle (only).

It "should" work but only in theory. Before wasting time on the
FPGA design suite and the proto-board, I want to make sure that
it has no obcious flaw that I missed :-)

yg
-- 
http://ygdes.com / http://yasep.org

On Wed, 02 Dec 2009 22:08:17 +0100
whygee <yg@yg.yg> wrote:

> Rob Gaddi wrote:
> > Ahh.  You don't need a frequency counter, you need a period counter.
> > I'm assuming you're trying to use the 1 pps GPS pulse to determine
> > what frequency your clock is actually running at.
> right.
> So I can adjust the tuning capacitor of the crystal.
> 
> >  In that case, why not
> > just synchronize and rising edge detect the 1 pps pulse?
> my idea was to synchronize the 1pps input (and detect the
> rising edge of the pulse) to the crystal. Said another way :
> the crystal clocks a free-running shift-register/delay line,
> then some logic detects when the first N bits of the shift register
> are 0 and the last a 1s. The output of the AND gate toggles
> the latch enable of the output frequency register,
> for the next cycle (only).
> 
> It "should" work but only in theory. Before wasting time on the
> FPGA design suite and the proto-board, I want to make sure that
> it has no obcious flaw that I missed :-)
> 
> yg

Yes and no.  Basically, you're trying to design a frequency-locked
loop. That mostly works, except that you're going to have problems with
your frequency walking around.  If you measure 1s with a 60 MHz clock,
you'll get 60,000,000.  But you could be off by up to 16 ppb before
you'll see enough perturbation to be consistantly getting results that
are above or below this.  That's a deadband where you've got no loop
gain, and so you're likely to wind up bouncing back and forth around in
it.

The usual way to solve this problem is to make a phase-locked loop
instead, which can give you a lot more resolution on signals that are
ever so slightly out of phase.  There are a few tricks for this in an
FPGA; one of the cuter ones is described in Xilinx XAPP250, where they
hard code an internal delay line and use that to try to center up the
rising edges of the crystal clock and the external signal.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

Rob Gaddi wrote:
> On Wed, 02 Dec 2009 22:08:17 +0100 whygee <yg@yg.yg> wrote
>> It "should" work but only in theory. Before wasting time on the
>> FPGA design suite and the proto-board, I want to make sure that
>> it has no obvious flaw that I missed :-)
> 
> Yes and no.  Basically, you're trying to design a frequency-locked loop.
Yes and no :-)

The 1PPS signal is only a (planned) laboratory device,
used when adjusting the cristal's leg capacitors.
So the "loop" is loosely "closed" by a human operator (me)
in order to get an appropriate frequency.
I still want something very compact, as power-efficient
as possible, and as cheap as reasonable, so putting a GPS
receiver (even a "stamp-sized" one) in every board is not reasonable ;-)

> That mostly works, except that you're going to have problems with
> your frequency walking around.
there are good ways to prevent this, look at
http://jmfriedt.free.fr/lm_msp430.pdf
OK I know it's french, but you'll understand
the pictures, the code and the PI (without D)
regulation functions. Oh, and there seems
to be a mistake in fig.4 with the varicap.

But I did not intend to do something so complex...
At first I just wanted to make sure that my oscillators
would not be too much out of frequency :-)

> The usual way to solve this problem is to make a phase-locked loop
> instead, which can give you a lot more resolution on signals that are
> ever so slightly out of phase.  There are a few tricks for this in an
> FPGA; one of the cuter ones is described in Xilinx XAPP250, where they
> hard code an internal delay line and use that to try to center up the
> rising edges of the crystal clock and the external signal.
I'll have a look, who knows what else i'll learn ? :-)

regards,
yg
-- 
http://ygdes.com / http://yasep.org

I can't understand your answer given below. why did you opt for an
asynchronous
counter and how will you be able to set all the delays [1s, 10us]
whith a
synthesizer? actually what all the number stand for?

Cheers
>
> One of the best high-frequency counters I've done in an FPGA was a
> ripple counter. =A0Unlike a synchronous counter, a ripple counter only
> has a single point of entry that you need to gate, and so is safe for
> any asynchronous input signal up to hundreds of MHz.
>
> I wrapped a synchronous state machine around it that:
> =A0 1) clock enables the first flip-flop in the counter
> =A0 2) waits 1 second
> =A0 3) deasserts the clock enable
> =A0 4) waits 10 us for the ripple counter to settle out
> =A0 5) registers the now static outputs back into the clocked domain
> =A0 6) goto 1
>
> The only problem is that you don't know for certain how long it will
> take the ripple counter to settle out, but if you're willing to go way,
> way overboard on that dead time then everything works like a dream.
>
> --
> Rob Gaddi, Highland Technology
> Email address is currently out of order- Hide quoted text -
>
> - Show quoted text -