Extreme Serialize/Deserialize challenge

[Kill Bill]

Here is the challenge:
Serialize 32 bits of data clocked at 125MHz, send it over a single fiber,
then deserialize the 32 bits and the clock.

Can it be done?

Bill

 

[Mike]

On Sat, 24 Apr 2004 00:00:05 -0500, Kill Bill wrote:

Here is the challenge:
Serialize 32 bits of data clocked at 125MHz, send it over a single fiber,
then deserialize the 32 bits and the clock.

Can it be done?

Bill

You're joking, right?

You're talking about a serial data rate of 4Gb/s - easily achievable in
modern CMOS processes. The Journal of Solid-State Circuits has many
articles along these lines.

-- Mike --

 

[Don Taylor]

Kill Bill <dontbother@spam.net> writes:

Here is the challenge:
Serialize 32 bits of data clocked at 125MHz, send it over a single fiber,
then deserialize the 32 bits and the clock.

Can it be done?

Fibre Channel is at 4 gigabits/second now and that does what you are
describing. The modules to handle the physical layer of serialize/
deserialize are commodity products and save lots of grief compared
to trying to roll this yourself, at least the first couple of times.

www.fibrechannel.org

I don't make money from doing this, not any more.

 

[Allan Herriman]

On Sat, 24 Apr 2004 00:00:05 -0500, Kill Bill <dontbother@spam.net>
wrote:

Here is the challenge:
Serialize 32 bits of data clocked at 125MHz, send it over a single fiber,
then deserialize the 32 bits and the clock.

Can it be done?

That's hardly extreme, considering that last century it was possible
to buy devices that worked more than twice as fast.

However, you should consider that "single fiber" implies that you need
CDR (clock & data recovery) at the receive end.

You need to ensure that there is
(1) DC balance on the fibre (an equal number of 1s and 0s) to avoid
upsetting the AGC in the receiver, and
(2) a minimum transition density (a maximum run of 1s or 0s without a
change) to allow reliable clock recovery.

There are simple codes such as 4B5B or 8B10B that are commonly used
for this task (e.g. in Ethernet). They replace a group of 4 (or 8)
bits with another group of 5 (or 10) bits that meets the above
requirements. This increases the bit rate (to 5Gb/s in this case).

Scrambling is an alternative way of achieving the DC balance and
transition density requirements. This works by XORing the data stream
with a pseudo random sequence. The same pseudo random sequence is
XORed with the data at the receiver to get the original data back.
Synchronising the two pseudo random sequences can be interesting (but
is a solved problem).
Scrambling has the advantage (over something like 4B5B coding) that
there is no increase in bit rate. It has the disadvantage that it
only reduces the probability of excessive run lengths, however you can
usually make the probability of failure acceptibly low by choosing the
sequence appropriately. (SONET works this way.)

You should consider using standard bit rates, to ensure that the parts
you need are readily available.
Another poster suggested 4Gbps Fibre Channel (which actually runs
4.25Gbps on the fibre). It is probably the best approach for you.

For some extreme masochism, you could go up to 10Gb/s, as parts are
readily available at those rates, e.g.

9.95328 Gbps (SONET/SDH)
10.3125 Gbps (Ethernet)
10.51875 (Fibre Channel)
10.709 Gbps (G.709)

If you use Ethernet, the simplest solution (in terms of parts count)
is probably to use an FPGA with a XAUI interface (which is actually 4
x 3.125Gbps interfaces in parallel). That way the FPGA can connect
directly to the optics. The FPGA can also perform the conversion
between your 32bit bus and Ethernet frames.
Look at the Xilinx Virtex2 Pro series of FPGAs. Altera will have
somthing similar.

For lower cost, you could try XFP optics, but this involves running
10Gb/s signals across the board and I don't recommend that for
beginners.

Regards,
Allan.

 

[Bill Sloman]

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<6d1p80pd0lsdmd41qr3977qcifbovtf4qr@4ax.com>...

On Sat, 24 Apr 2004 00:00:05 -0500, Kill Bill <dontbother@spam.net
wrote:

Here is the challenge:
Serialize 32 bits of data clocked at 125MHz, send it over a single fiber,
then deserialize the 32 bits and the clock.

Can it be done?

That's hardly extreme, considering that last century it was possible
to buy devices that worked more than twice as fast.

However, you should consider that "single fiber" implies that you need
CDR (clock & data recovery) at the receive end.

You need to ensure that there is
(1) DC balance on the fibre (an equal number of 1s and 0s) to avoid
upsetting the AGC in the receiver, and
(2) a minimum transition density (a maximum run of 1s or 0s without a
change) to allow reliable clock recovery.

There are simple codes such as 4B5B or 8B10B that are commonly used
for this task (e.g. in Ethernet). They replace a group of 4 (or 8)
bits with another group of 5 (or 10) bits that meets the above
requirements. This increases the bit rate (to 5Gb/s in this case).

Scrambling is an alternative way of achieving the DC balance and
transition density requirements. This works by XORing the data stream
with a pseudo random sequence. The same pseudo random sequence is
XORed with the data at the receiver to get the original data back.
Synchronising the two pseudo random sequences can be interesting (but
is a solved problem).
Scrambling has the advantage (over something like 4B5B coding) that
there is no increase in bit rate. It has the disadvantage that it
only reduces the probability of excessive run lengths, however you can
usually make the probability of failure acceptibly low by choosing the
sequence appropriately. (SONET works this way.)

You missed out bit-stuffing, as used in LAPD in X25 and similar
packet-switching protocols, where any sequence of more than five one
or zero's is "stuffed" with an extra zero or one, which is then
removed at the receiver.

Uses slightly less extra bandwidth than 4B5 and 8B10, but less
predictably, so only useful in store and foward systems.

A sequence of six ones or zeros is the packet boundary, which is
discarded by the receiver. The system can obviously be corrupted if
noise flips the wrong bit during transmission - most such errors are
detected by checking a 16 or 32 bit CRC (cyclic redundancy check)
sequence added to the end of the packet at transmission, and lost
packets (there is a sequence number in the header) are corrected by
retransmission. Sounds hairy, but it works - this posting will
certainly have gone through just this process repeatedly before you
got to read it.

-------
Bill Sloman, Nijmegen

------
Bill Sloman, Nijmegen

 

[Allan Herriman]

On 26 Apr 2004 02:57:50 -0700, bill.sloman@ieee.org (Bill Sloman)
wrote:

Hi Bill,

[snip]

You missed out bit-stuffing, as used in LAPD in X25 and similar
packet-switching protocols, where any sequence of more than five one
or zero's is "stuffed" with an extra zero or one, which is then
removed at the receiver.

That was a deliberate omission.
LAPD / X25 / HDLC ultimately refer back to ISO 3309, which defines
both bit and byte stuffed systems. In no case does it guarantee a
maximum run length of zeros (the bit stuffed version only stuffs runs
of ones), nor does it provide DC balance.

HDLC wasn't designed for optical transmission; the stuffing is merely
to stop user data from being mistaken for framing indicators, escape
codes or abort sequences.
It is a common misconception that the stuffing is meant to help clock
recovery.
Systems that use HDLC over fibre always have a scrambler, AFAIK. E.g.
RFC2615.

As you noted, the bandwidth increase isn't predictable, so it isn't
useful to the OP.

Regards,
Allan.