differential Manchester decoder and FIFO

[p]

I need to make a bi-phase / differential Manchester decoder (max.
frequency of recovered clock about 10MHz) and asynchronous FIFO 1 bit *
~100...~1000.
How can I do this and what is best suitable to do it ?

Thanks in advance.

 

[p]

Simple async Manchester decoder:

Make a transition detector (delay and XOR) and use it to fire a
non-retriggerable one-shot on every data transition. Make the one-shot duration
3/4 of the bit time. It will soon settle down to firing on just the center-cell
transition. Use the one-shot output to clock the data.

Thank you, but recovered frequncy is any in range ~1..~10MHz. Circuit
must be able to decode without any changes with this condition.

 

[Martin Riddle]

Thank you, but recovered frequncy is any in range ~1..~10MHz. Circuit
must be able to decode without any changes with this condition.

FPGA
Look at the HD-6409, I've used this in another life.
<http://www.intersil.com/content/dam/Intersil/documents/tb46/tb463.pdf>
You'll have to do a auto baud measurement on the sync data, the 6409
has a pre-amble to sync the data clock.
There is no whay to sync with out missing the first bits.

Cheers

 

[rickman]

Thank you, but recovered frequncy is any in range ~1..~10MHz. Circuit
must be able to decode without any changes with this condition.

That could be tough. I did a design similar to this in an FPGA. It
received a simple bit stream and had to sync to the transitions. But it
had a timing setting to establish the base frequency approximately.

This design used a locked loop to adjust the NCO to the bit rate. Since
the base frequency was set by the user the search mode is not overly
aggressive. In your case you might need to use a rather aggressive
search mode to set the base frequency very quickly, or even do a
frequency measurement for a direct setting.

Do you have a spec on the data stream format you will need to sync to?
As others have indicated, there should be a preamble which would be a
stream of bits which produce a single transition in the Manchester
encoded stream. Knowing the length of this preamble will give you an
idea of how quickly your circuit will need to adapt to the data
frequency and lock up to the data stream.

 

[p]

Thanks for respone.

FPGA

I've never done anything with FPGA (and CPLD). I was thinking about Lattice.
I don't know whether this is a good choice. I don't know what to choose
(design software and device).

Look at the HD-6409, I've used this in another life.
<http://www.intersil.com/content/dam/Intersil/documents/tb46/tb463.pdf>
You'll have to do a auto baud measurement on the sync data, the 6409
has a pre-amble to sync the data clock.

Very interesting, but max. data rate = 1Mbit/s.

There is no whay to sync with out missing the first bits.

Missing the first bits (even ~1000) is no problem.

 

[Martin Riddle]

Thanks for respone.


I've never done anything with FPGA (and CPLD). I was thinking about Lattice.
I don't know whether this is a good choice. I don't know what to choose
(design software and device).


Very interesting, but max. data rate = 1Mbit/s.


Missing the first bits (even ~1000) is no problem.

There is another M en/decoder that runs at 10mhz. HD-15????

Cheers

 

[[email protected]]

https://www.google.com/patents/WO19...a=X&ei=edlAUp_aB4-64AOlhoCgDA&ved=0CDYQ6AEwAA

 

[rickman]

Yep, It's good. Got myself confused there momentarily. It works.

...Jim Thompson

I didn't analyze your circuit entirely, but the XOR gates with the shift
register seem to be a LFSR or something similar used to produce a pseudo
random sequence. No?

So how does your circuit work if the data stream is *not* pseudo random?
That is, how does the data pattern affect the voltage? Looks to me
like this circuit detects the rate of transitions rather than the rate
of the clock which is what is needed. I think it is very sensitive to
the data pattern and will not produce a constant voltage if the data
pattern is varied while the clock rate remains constant. Try your
simulation with an all 1's data pattern and an all 0's data pattern and
see if the average voltage is the same. I think it will be 2:1.

On the other hand an all digital approach can be made to work.

If the OP needs some help with the problem I am available.

 

[p]

There is another M en/decoder that runs at 10mhz. HD-15????

I found HD-15530 and HD-15531, both under 10Mbit.

 

[p]

That could be tough. I did a design similar to this in an FPGA. It

received a simple bit stream and had to sync to the transitions. But it
had a timing setting to establish the base frequency approximately.

This design used a locked loop to adjust the NCO to the bit rate. Since
the base frequency was set by the user the search mode is not overly
aggressive. In your case you might need to use a rather aggressive
search mode to set the base frequency very quickly, or even do a
frequency measurement for a direct setting.

Do you have a spec on the data stream format you will need to sync to?
S/PDIF.

As others have indicated, there should be a preamble which would be a
stream of bits which produce a single transition in the Manchester
encoded stream. Knowing the length of this preamble will give you an
idea of how quickly your circuit will need to adapt to the data
frequency and lock up to the data stream.

Lost of first bits is no problem.

 

[p]

https://www.google.com/patents/WO19...a=X&ei=edlAUp_aB4-64AOlhoCgDA&ved=0CDYQ6AEwAA

Thanks, but I don't know why there is a lack of images.

 

[[email protected]]

Yes , I am the author of that patent , and the concept came from an analog implementation that is similar to your description.

Bob

 

[rickman]

Lost of first bits is no problem.

So what is the problem exactly? Do you not know where to begin? The
patent shows one way of doing it. There are other ways of cooking the
goose. Do you understand the separate functions that are needed? Clock
rate detection, bit synchronization, data extraction?

 

[Robert Baer]

** snipped so aioe will accept **

Good questions. A quick tutorial would be most helpful to the OP...
I'd sure like to see it myself.

...Jim Thompson

Reminds me of when, 30+ years ago, i designed a serial data coding
system that would allow variable data rate, totally self-clocking.
I think it was as good or better than MFM.
The idea of that was ability to achieve constant bit density on a
hard drive.

 

[[email protected]]

S/PDIF.

The maximum supported data rate for SPDIF is about 6 Mbit/s, so from
where did you get that 10 MHz requirement ? So even if you have two
transitions (half cycles) within a single bit time, the frequency is
still 6 MHz.

In SPDIF, the serial bit clock (after dividing down) is typically
used for driving the DAC, which requires a jitter free timing. After
initially sensing the bit rate from a large range, you need a narrow
bandwidth PLL to maintain the rate as constant as possible.

 

[rickman]

** snipped so aioe will accept **


Reminds me of when, 30+ years ago, i designed a serial data coding
system that would allow variable data rate, totally self-clocking.
I think it was as good or better than MFM.
The idea of that was ability to achieve constant bit density on a hard
drive.

Why variable data rate, or do you mean "slightly" variable? The OP's
requirement is for the clock rate to vary over 1 MHz to 10 MHz. That's
a bit of a stretch.

 

[rickman]

The maximum supported data rate for SPDIF is about 6 Mbit/s, so from
where did you get that 10 MHz requirement ? So even if you have two
transitions (half cycles) within a single bit time, the frequency is
still 6 MHz.

In SPDIF, the serial bit clock (after dividing down) is typically
used for driving the DAC, which requires a jitter free timing. After
initially sensing the bit rate from a large range, you need a narrow
bandwidth PLL to maintain the rate as constant as possible.

Yes, as I read more of this thread I realize this is almost exactly what
I implemented in an FPGA a few years ago as part of a design still in
production. At one end is a data link and an ADC which samples a time
code signal. The data link has no clock, but rather an approximate rate
is set by the software and the hardware slave to the data transitions.
The CODEC is slaved to the data rate. The aggregate data bundle (fixed
number of data bits and the CODEC sample) is shipped over an IP network
where at the other end another copy of this unit receives the data and
reconstitutes both the data stream and the time code signal in
synchrony. This requires syncing up to the average data rate of the IP
packets and clocking the CODEC in lock step with clocking the data.
IIRC, the loop lock was actually regulated by the amount of data in the
FIFO. The FIFO delay had to match the delay of the sigma-delta CODEC.

The receiver half of this should be *very* much like what the OP wants
to do.

 

[Robert Baer]

Why variable data rate, or do you mean "slightly" variable? The OP's
requirement is for the clock rate to vary over 1 MHz to 10 MHz. That's a
bit of a stretch.

I did not mean or imply or say anything about "slightly variable".
The scheme was equally robust from data rates of millihertz to gigahertz.
And i think a number of the intelligent individuals on this NG could
dream up such a scheme.

 

[p]

The maximum supported data rate for SPDIF is about 6 Mbit/s, so from

where did you get that 10 MHz requirement ?

Forgive me.

 

[p]

Try this link to the issued patent...

<http://free.patentfetcher.com/Patent-Fetcher.php?submit=Fetch&PN=5889820>

A digital implementation similar in concept to my analog posting.

...Jim Thompson

Thank you. I'll try to figure it out.