Reconstructing Clock for Serial Signal

Recovering a clock from an intermittent stream of pulses is a non-trivial design exercise. I generally try to center the edge of the clock on the pulses, then the clock edge can be used to capture the presence/absence of the pulse in a flip-flop. A hybrid digital/analog circuit demonstrates the concept more clearly:

^{simulate this circuit – Schematic created using CircuitLab}

The general idea is to use a pair of gates to generate a "pump up" pulse and a "pump down" pulse for every input pulse. As long as these two pulses are the same length (the clock edge occurred exactly in the middle of the input pulse), there will be no net change of the VCO frequency. But if the pulse comes a little early with respect to the clock (which means the clock is slow), the "pump up" pulse will be wider than the "pump down" pulse, increasing the VCO control voltage. The opposite occurs if the input pulse is late, decreasing the control voltage. The VCO should be configured so that the range of frequencies that it can produce over the range of the control voltage matches the the expected range of data rates.

Since you're working with an FPGA, a very similar thing can be done purely in the digital domain. We'll assume you have a high-speed clock (e.g., 10 - 50 MHz) available. We replace the charge pump with a binary up/down counter, replace the VCO with a DDS, and instead of relying on analog pulse widths, we sample the phase of the DDS at the rising and falling edges of the input pulses.

In the following diagram, all of the "dangling" clock inputs are connected to the FPGA's high-speed internal clock. Any pins with [] at the ends of their names represent multi-wire buses.

^{simulate this circuit}

The asynchronous RZ input is passed through a 2-stage synchronizer and then an edge detector. Registers U3 and U4 capture the upper phase bits of the DDS (U2) on the rising and falling edges of the RZ pulse, respectively. If we treat the phase value as a signed binary number, the rising edge will capture a negative value, while the falling edge will capture a positive number. We add these two numbers together, and if we're perfectly in sync, they'll cancel and the result will be zero. However if the clock is late, the negative number will be greater and the sum will be negative. We therefore just take the sign bit at the output of the adder (U5), and use gates to either increment or decrement the value in our counter (U1) to speed up or slow down the clock. Note that you'll want to configure this counter so that it only covers the frequency range of interest. In other words, it'll have both a minimum value and a maximum value that it won't count beyond.

The "carry out" from the DDS is a one-clock-wide (system clock) pulse that occurs at the rate of the RZ data, aligned to the centers of the bits.

If the clock can vary, and you need to recover it, you should definitely build a clock recovery circuit.

With the RZ signal that can be quite easy since as you say the clock is present in the signal all the time. If you are receiving all ones you actually are receiving the clock signal... But when a zero is received you are receiving the negated clock. First of all I suggest an edge detector, that is a cirtuit that outputs a pulse each time the input signal changes polarity. A trivial example is an high pass filter, that is a series capacitor with a resistor to ground. Your pulses still are of mixed polarity, but you can just use a full wave rectifier so that you get a positive pulse each time your signal makes a transition. Now that's nearly a clock, you just need to divide it by two with a couple of flip flops and you are done.

To detect all the edges you can also use a XOR gate: one input to the RZ signal, the other to the same signal delayed "a bit". When and only when the inputs are different, that happens when you are having a transition, the output will be high. You still need to divide by two.

I know I haven't proposed a practical solution but I hope my inputs can help you.

Given the frequencies you're looking at, I would suggest trying to solve the problem in the digital domain. If there's some "nice" way to identify two pulses that are supposed to be some number of time slots apart (e.g. the inter-frame gap is supposed to be longer than any gap within a frame, and the time from the start of one frame to the start of the next is always supposed to be exactly twenty time slots) then if you sample your incoming data with a clock that's at least twice as fast as the data rate, you should be able to figure out where the frame boundaries are. From that, you should be able to figure out the location of individual time slots within a frame.

A major advantage of moving this sort of thing to the digital domain is that data can be analyzed retrospectively. For example, if each frame is twenty time slots, the first and sixteenth always have pulses, and there's no gap of four or more time slots without a pulse, then you could use hardware to record every 15us whether there was a pulse or not, watch for a time without pulses that's long enough to be an inter-frame gap, and keep track of the last such time that's been observed. When an inter-frame gap (other than the first) is observed, latch the number of clocks between it and the previous one, and then grab data from suitably-spaced spots in the buffer.

It might be possible to use a microcontroller to do much of the analysis; 50khz is a little fast, but perhaps workable if the controller has some hardware assistance for capturing the data or doesn't have to do anything else. A microcontroller's odds of success could be especially good if e.g. there are always nine pulses per frame (if hardware stores a byte per pulse with its approximate length, then if the current gap and the one nine previous are longer than any of the intervening ones, then the intervening eight probably form a data frame, and the clock rate should be 1/20 of their sum). Selection of the best approach would require a bit more knowledge of what the incoming data stream represents, what parts of it are fixed or variable, how clean or jittery it's apt to be, etc.