Re: Newbie questions: Can I do this PLL all digitally in a FPGA? 8Khz clock locked on a 100hz pulse

On Jun 13, 10:18 am, Jonathan Bromley <jonathan.brom...@xxxxxxxxxxxxx>
wrote:
On Wed, 13 Jun 2007 13:27:39 -0000,

ZR1TECH <ZR1T...@xxxxxxxxx> wrote:
Can I do this all in a FPGA?

I would like to sync to an incoming pulse (its actually going to be a
register write) that I will receive at approx 100hz, and generate a
8Khz output clock.

Yes, definitely. Getting *really* good results may be quite
tricky, though.



This will be a recovered sync from a master device, but the devices
are SW based so there will be a fair amount of jitter (~+/- 500us) ..
but this jitter is expected to be bounded
and stable (not slipping in time) over a long period.

Is it possible to use a local 50Mhz oscillator and create and up/down
counter based on the 100hz signal, then slightly adjust the 8Khz clock
rate based on this?

For sure. The interesting question is, what are you
really trying to achieve? Are you trying to ensure that yuo
get as nearly as possible 80 output pulses between each
pair of 100Hz register writes? Or are you trying to get
an essentially constant frequency that is, over very long
periods, locked to the long-term average of the 100Hz?

What I'm getting at is that anything that responds promptly
to changes in the 100Hz input will obviously cause jitter
on the 100 Hz to propagate to the output. Likewise,
anything that smooths the 8kHz output so that it has
minimal jitter, and its frequency changes slowly and
smoothly, will of course fail to respond to rapid
changes in the 100Hz signal's behaviour. You need to
know something about the statistics of the reference
signal, and the desired behaviour of the output.

Having said all that, the frequencies you describe are
so slow that you have LOTS of time to do any calculations
that might be needed; so you can do quite sophisticated
filtering with a small amount of hardware (or even with
software in an embedded CPU of some kind).

I did something loosely similar when I wanted to know the
exact position of a rotating flywheel, but could see only
a single index pulse per revolution. In that case I was
able to make use of the known physics of the rotating
object, and the known behaviour of the index pulse
sensor, to make things work better. Some interesting
juggling was necessary to get the thing into lock
quickly at startup time - it's often a good idea to
have two operating modes, "acquiring lock" and
"holding lock". And then you have to be VERY careful
about what happens as you transition from one mode
to the other. By the way: that example was recovering
a roughly 5kHz pulse train from a roughly 30Hz signal,
and I did it all in a little PIC microcontroller! And
no, you can't have the code; it was so long ago that
I have certainly lost it all!
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@xxxxxxxxxxxxxxxxx://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Hi Jonathan,

Thanks much for the info!

I am in fact trying to get an 8K clock locked to the long-term average
of the 100Hz..


The system has one timed master (M) this master generates sync packets
to another system at a rate of 100hz, when the slave (S) recovers
these packets the hardware is updated via a register write to the
FPGA.
Jitter is introduced via SW trasmit (though very little), network
(most of the jitter, as well as a possible packet loss every so
often), as well as the SW receiver.. this jitter will be bounded, but
its there :)

so a clock based on the master that does not slip significantly over
time (wander is ok.. just no long term slipping) is what I am
after.... Lock time can be in the order of minutes, and quick changes
are not what I am looking for..

Im just starting on it so I obviously have alot more homework to do :)

thanks much! any info or advice is greatly appreciated!

-Bill

.

Relevant Pages

  • Re: [PATCH 1/2] Add a common struct clk
    ... In the current i.MX implementation we have a global lock which ... protects the clock enable counter and also the register accesses in the ... to protect the register accesses. ... With common struct clk we would have to call ...
    (Linux-Kernel)
  • Re: [PATCH 1/2] Add a common struct clk
    ... In the current i.MX implementation we have a global lock which ... protects the clock enable counter and also the register accesses in the ... to protect the register accesses. ... With common struct clk we would have to call ...
    (Linux-Kernel)
  • Re: VAX floating-point instruction timing?
    ... Not all clock ticks are the same. ... There were stretched clock cycles on at least one VAX box; there was a VAX with two different lengths for its clock cycle, depending on what is going on in the i-stream. ... Yeah, I know, they weren't completely compatible with each other but they all implemented the architecture modulo various subsets and the inevitable bug that would creep in. ... I intend to use register renaming in such a way that 1) every register modification goes to a new physical register and 2) there are sufficiently many more physical than architected registers that all the original register values are kept untouched by even the worst case autoupdating instruction. ...
    (comp.sys.dec)
  • Re: FFT of a jittery clock signal
    ... I'm trying to learn more about jitter effects on the spectrum of a clock ... You can look up the spectrum of either version in a signal processing book, if you get a basic enough book. ... Now consider an additive signal to that sine wave that's 90 degrees out of phase, and is modulated by a noise signal with whatever pdf and spectral properties you want. ...
    (comp.dsp)
  • Re: Cross Clock Domain Control
    ... I add a 2nd "metastable rejection" register after the 1st input ... feeding the functional logic in the target clock domain. ... think I will still add in the metastability registers for good design ...
    (comp.lang.vhdl)