Clock Extraction from Bi-Phase Data

3 MHz is slow. Just build a FSM that parses the data stream. Say with a 10x or 16x clock.

Experiment a bit with some graph paper if you haven't done it before. It will be obvious when you see it.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

This works for pure data extraction, but no good for audio apps where you need to produce a jitter-free clock for an output stream locked to the input rate.

to produce a

Jitter from the clock recovery process doesn't necessarily imply excessive jitter in the output stream.

There are ways of removing or reducing said jitter, however pretty much all of them involve a low noise oscillator of some sort.

BTW, Please avoid using the term "jitter-free" because such a thing is not possible.

Regards, Allan

So, out of curiosity, how would you do it if the BiPhase clock was around

80MHz ? (ideally Spartan 2 based)

Dave

Posted Via Nuthinbutnews.Com Premium Usenet Newsgroup Services

---------------------------------------------------------- ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **

----------------------------------------------------------

I don't have any great answers.

How clean is your input signal? How many samples per bit do you need to get a reasonable result?

You can push the FSM technology a factor of two or maybe 4 by having a front end that goes x times as fast and feeding multiple bits into the FSM on each clock tick.

The general idea is similar to processing several bits per clock in a CRC. Same basic algorithm but much more logic to implement it.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

to produce a

Actually, this will work pretty well. Since no clock is "jitter-free" there is a tolerance. The FSM clock needs to be fast enough to be within the tolerance. The result will be data and a clock that is aligned with the incoming signal within the tolerance.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

to produce a

Thanks.

How much jitter can an audio system tolerate?

Is it reasonable to use digital clock synthesis techniques? If so, how fast a clock do I have to start with?

Is the answer different for phone quality vs hi-fi systems?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hi KVP,

I am working on something similar. You cannot use the 48MSPs to recover your clock in the DLL because the sync patterns have a bi-phase violation. The lowest clock you can recover is 64 / 4 * 48kHz = 768kHz. This is too slow for that fast DLL. One solution I thought about was switching the DLL input to its output while sync. But what is on transmission errors? Your DLL will go out of control. My intention is using a 32.768MHz VCXO and a FIFO. The VCXO is FLLed to the recovered input. So you use the AES syncs to FLL to your clock.

See also the thread "VCXO emulation" in this NG.

Regards Thomas

consider to use a external AES/EBU receiver, like Crystal CS8413/14.

Using techniques like clock-shifting-DLL etc.. in a FPGA for an AES/EBU receiver is not a good idea: The clock for the audio samples must be very accurate. You will get bad THD & SN-ratio.

WD