clock recovery and pll with frequency multiplier

Hello,

I´m going to design a system where a digital signal is transmitted over a wired connection.
the frequency of the signal should be as small as possible to save power.

on the receiver side there will be a digital system that has to be clocked with 4MHz because it has to generate a specified timing sequence with the smalest time interval beeing 250ns.
the system will be integrated sometime.

so my question. how big can the multiplying factor of a pll with frequency multiplier be? i think this is what will limit the lowes possible transmission rate of my signal.

regards zitty...

Seems the answer may relate to how much jitter you can tolerate when creating the 4MHz clock.
The problem is that you would be providing a relatively infrequent "correction" into the PLL, and the PLL's oscillator can drift in between these events, due to e.g. external P/S noise or other internal PLL effects.
And if you are using one-bit serial data as a clock (embedded clock), then the issue is even worse because there may not be a data transition (PLL correction) at every slot.
(and you'd likely also need a PLL with a PD specially designed to use such a reference clock)
In the extreme, too much oscillator drift could lead to loss of PLL lock.

If you are using an FPGA, you may additionally be limited by PLL multiplier ranges (e.g. max 32 for some Xilinx parts).
And, these FPGAs also have minimum output freq limits (e.g. 5MHz, due to oscillator range limits), which means you'd need an output divide-by-2 thus further aggravating the impact of the limited multiplier value.

I've seen a PLL for an Intellibus rcvr with a multiplier of 4096, but it was a very tough design due to the output jitter goal.
(i.e. as I recall, the Intellibus protocol provides a low-freq master sync-clock, which is used to clock & synchronize all higher-freq peripherals like ADCs & DACs)

However, in the end, I'd also wonder if you even need a PLL, depending on system-level synchronization requirements (which you did not mention).
Why not a local 4MHz crystal, and then you can simply oversample the data stream, since it is so much slower?
All symbol-recovery would then be done using logic to identify the position of the transition/edge sample, then pick the centered sample for its data level, and so on.
(and there are ways to also add filtering to such a symbol-synchronizer in the presence of noise)

thanks for your answer...

the system should be realized in a way that it can be integrated on chip.
so although i like the idea with the oversampling i´m not sure how it could be realized.
a crystal cannot be used. maybe i can transmit a synchronyzing sequence with fast transitions to synchronize a pll and transmitt the data much slower to geth the effect of oversampling there but saving power during the actual transmission

First, I should mention that my oversampling description is basically what a UART does (the "Receiver" section of WikiPedia's "UART" page gives a decent intro on this).

Anyway, it's hard to comment better on this without knowing more, e.g. whether or not the endpoints must still run @ 4MHz in-between communication periods (maybe not based on your response), and the 4MHz endpoint clock accuracy (both absolute and relative to each other), not to mention other things (cost & power!).
But I'm not saying I want to know more ;-)

Your preamble comment brings to mind a DLL solution, since that could be designed to "slap into lock" in a minimum of edges, but would then free-run and get into drift issues between communication periods.
(a PLL could drift too far, making the preamble be quite long to re-acquire lock, depending on the delay between communication periods and the "tuning" of the PLL)
(plus, typical PLL macros might not handle a loss-of-reference-clock situation where it suppresses the PD until the clock reappears - might need to be a custom PLL)

I reluctantly mention that if your 4MHz reqs were very loose, maybe a RC-oscillator could be used but would need some form of per-lot calibration, and the analog design could be tough per V & T variation/drift rejection.
(I've seen this done, but the process allowed for on-chip poly-fuses or maybe was EEPROM)

I also worked on a design where the endpoint had an RC-oscillator that ran at a large-ish multiple of the desired freq, and then a central controller would "calibrate" counters on all endpoints using an accurately timed transmit sequence; the resulting counter-values would then be divided (by the same amount in all endpoints) and used to modulo-count accurate intervals (i.e. output-clock edges) that are a fraction of that calibration interval.
Each endpoint thus can generate accurate intervals (both absolute and relative to each other), even though each has an RC-oscillator running at a different freq.
If this calibration always occurs shortly before the output freq is needed, then oscillator drift can be negligible.
However, for that design, the minimum output interval was much, much longer (milliseconds!) than that of a 4MHz clock, so I doubt this approach makes any sense (you'd need to run your oscillator at too high of a multiple of 4MHz).

Hope some of this helps and not just distracts ... good luck!