Serial Transmission w/o 8B/10B encoding

The clock recovery circuitry requires that there be a minimum number of received edges per unit time. Otherwise, the recovered clock edges will drift with respect to the data stream.

If you don't use some type of encoding (e.g. 8B/10B), or you don't insure that your raw data ALWAYS provides this minimum edge density requirement, then the clock/data recovery circuitry will not work.

Bob

Perhaps a scrambler/descrambler using LFSR's would help alleviate any edge density or DC bias problems by randomizing the data a bit? I'm not sure if it would guarantee correct reception, but it may help.

You don't say why you need a "pure" signal (no coding). I could assume that you are trying to eliminate the overhead of coding (with 8b10b you only get an effective data bandwidth of 80%).

You didn't say whether or not you MUST have a DC-balanced signal. Are your transmitters AC-coupled to the receivers? If yes, the you must have a DC-balanced signal and coding IS required.

You also don't mention your clocking requirements. Do you have a common (distributed) reference clock, or are the reference clocks independant?

Typical clock recovery circuits assume plesio-synchronous operation. This means the the reference clocks can be independent but must be within +/- XYZ PPM (parts-per-million) of each other. For a receiver to track the transmitter the receiver must recover the clock (and data) from the transmitted bit stream. At high speeds this is done using PLLs. For the PLLs to perform well they require frequent edges in the transmitted bit stream.

Without a coded bit-stream you can't have DC-balance and you can't gaurantee frequent edges for the PLL. So if you really can't have a coded bit-stream then you must have a distributed (common) reference clock and you cannot use AC-coupling.

If you are trying to minimize the overhead of coding look at other coding methods like 64b/66b codes. These are more efficient but still have the benefits of DC-balanced tranmission and frequent clock edges.

Note that another benefit of 8b10b is the ability to align your symbols. How are you going to know the boundaries of a byte, a packet, etc., without a coded stream and use of non-data symbols (control symbols)? If you have independent reference clocks how are you going to avoid underrun and overrun of the reciever withouth control symbols (i.e. insertion and removal of idle characters)? Do you need any form of closed-loop flow control, error signalling, etc.? If yes, how are you going to do this without control symbols?

TC

Thanks...we also noticed a new problem When we run our implementation on FPGA, there is loss of data on the non-active part of the signal. Its set to be 20180bits, but the number of bits received is less than that. The loss of data is not consistent either. But this doesn't appear in simulation in Modelsim. One reason could be the fact that the DC Balance is not there. But does it affect the data recovery from serial to parallel? Another option is use an external modulator chip on the receiver signal to achieve DC balance and the use the new modulated signal on MGT and decode it inside the FPGA.

Our setup: MGT Speed - 2 Gpbs FPGA - Xilinx Virtex II Pro Board - Xilinx XUP Virtex(tm)-II Pro Development System Software - ISE 9.1i

(snip, someone wrote)

It does if you are doing clock recovery on the incoming bits. If the clock is off, it will miscount on long runs of the same bit.

-- glen

ure

the

of

ll

sure

ent,

hat

get

ur

XYZ

PLLs

m.

ntee

am

use

How

rrun

idle

You are running into a fundamental limitation. What you receive is NRZ data, High for 1, Low for 0 (or something similar). You know that a High level of a certain duration means three ones in a row, but the receiver needs a clock to separate the bits. It gets this clock from its own PLL oscillator that is being kept alive and accurate by re- synchronizing itself from any transitions in the data stream. That's why you must have a transition quite often. Maybe you can run for 70 bits without a transition, but after tht, the PLL oscillator will drift and will not partition the incoming data stream properly. Sorry for this basic explanation, maybe everybody understands all this already. Peter Alfke

insure

requirement,

XYZ

PLLs

gaurantee

use

How

overrun

idle

ahhhhh Thanks.. Now I get it.. So in long streams, its unable to partition the data to recover the exact bits.. hmm, I guess one solution is use an external scrambler/encoder on the signal to achieve data balance. then do descrambling/decoding inside the fpga to get the correct data..

Cheers Shakith

m...

com...

nals

a pure

ng in

uracy

in the

lack

good

ber of

s will

t insure

irement,

any

me that

nly get

e your

mon

nt?

This

the PLLs

tream.

aurantee

stream

nnot use

oding

the

ols. How

out a

ave

overrun

of idle

ol

m...

com...

nals

a pure

ng in

uracy

in the

lack

good

ber of

s will

t insure

irement,

any

me that

nly get

e your

mon

nt?

This

the PLLs

tream.

aurantee

stream

nnot use

oding

the

ols. How

out a

ave

overrun

of idle

ol

Thats the way when you cannot use the simplest method, called 8B10B, where 10 bits are used to transmit the content of 8 data bits. Transceivers often include the necessary encoder/decoder, and DC balancing is automatically included. The penalty is a 25% loss in throughput ( e.g. only 2.5 Gbps from a 3,125 Gbps channel. Scrambling is populat with the telephone people. Peter Alfke, Xilinx

For a new design, I would use 8b/10b or similar coding rather than a scrambler, unless I had to interoperate with an existing system that uses a scrambler.

Peter Alfke wrote: (snip)

I wouldn't call 8B10B the simplest.

Manchester code used by many ethernet systems, also known as phase modulation or phase encoding (1600BPI 9 track tapes) is simpler, self clocking, and less efficient in bandwidth.

-- glen

True, though Peter's point may be that it's simpler to turn on the existing

- Brian