Serial Transmission w/o 8B/10B encoding

Hi,

We have developed a High Speed on FPGA using the MGT/RocketIO to
generate high speed signals. Also we receive the high speed signals
using the MGT. Due to the nature of the application, we require a pure
signal without encoding (We have switched off the 8B/10B encoding in
the MGT). The problem is that it effects the clock recovery accuracy
in the received signal as there might not be  good DC balance in the
signal. Which in turn effects the data received. And MGT is a black
box to us.

Two options-
1.	Another encoding mechanism such that we have pure signal and good
clock recovery.
2.	Or is there a parameter in MGT to improve the clock recovery.

We are looking for some solution around this problem.

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

Best Regards
Shakith

<shakith.fernando@gmail.com> wrote in message 
news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com...
> Hi,
>
> We have developed a High Speed on FPGA using the MGT/RocketIO to
> generate high speed signals. Also we receive the high speed signals
> using the MGT. Due to the nature of the application, we require a pure
> signal without encoding (We have switched off the 8B/10B encoding in
> the MGT). The problem is that it effects the clock recovery accuracy
> in the received signal as there might not be  good DC balance in the
> signal. Which in turn effects the data received. And MGT is a black
> box to us.
>
> Two options-
> 1. Another encoding mechanism such that we have pure signal and good
> clock recovery.
> 2. Or is there a parameter in MGT to improve the clock recovery.
>
> We are looking for some solution around this problem.
>
> Our setup:
> FPGA - Xilinx Virtex II Pro
> Board - Xilinx XUP Virtex(tm)-II Pro Development System
> Software - ISE 9.1i
>
> Best Regards
> Shakith


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

On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
> <shakith.ferna...@gmail.com> wrote in message
>
> news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com...
>
>
>
> > Hi,
>
> > We have developed a High Speed on FPGA using the MGT/RocketIO to
> > generate high speed signals. Also we receive the high speed signals
> > using the MGT. Due to the nature of the application, we require a pure
> > signal without encoding (We have switched off the 8B/10B encoding in
> > the MGT). The problem is that it effects the clock recovery accuracy
> > in the received signal as there might not be  good DC balance in the
> > signal. Which in turn effects the data received. And MGT is a black
> > box to us.
>
> > Two options-
> > 1. Another encoding mechanism such that we have pure signal and good
> > clock recovery.
> > 2. Or is there a parameter in MGT to improve the clock recovery.
>
> > We are looking for some solution around this problem.
>
> > Our setup:
> > FPGA - Xilinx Virtex II Pro
> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > Software - ISE 9.1i
>
> > Best Regards
> > Shakith
>
> 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.

What are the failure cases that you experience?  I did something like
this a few years ago w/ a V2Pro-X @ 3.x Gbps and had to do a lot of
playing around with the settings in the megawizard in order to turn
off all of the layers of encoding and get everything working properly
as a "vanilla" SERDES.  One thing that I would look at is whether or
not you need to do manual bit-slipping in order to actually frame the
data properly.  Otherwise, you might not have the 8-bit / 16-bit words
aligned properly.

I would also recommend a scrambling algorithm, in order to balance 1's
and 0's.  I believe the spec for those parts is up to ~71 consecutive
1's or 0's before losing CDR.

Jeff

On Mar 26, 3:27 am, shakith.ferna...@gmail.com wrote:
> Hi,
>
> We have developed a High Speed on FPGA using the MGT/RocketIO to
> generate high speed signals. Also we receive the high speed signals
> using the MGT. Due to the nature of the application, we require a pure
> signal without encoding (We have switched off the 8B/10B encoding in
> the MGT). The problem is that it effects the clock recovery accuracy
> in the received signal as there might not be  good DC balance in the
> signal. Which in turn effects the data received. And MGT is a black
> box to us.
>
> Two options-
> 1.      Another encoding mechanism such that we have pure signal and good
> clock recovery.
> 2.      Or is there a parameter in MGT to improve the clock recovery.
>
> We are looking for some solution around this problem.
>
> Our setup:
> FPGA - Xilinx Virtex II Pro
> Board - Xilinx XUP Virtex(tm)-II Pro Development System
> Software - ISE 9.1i
>
> Best Regards
> Shakith

"Dave" <dhschetz@gmail.com> wrote in message 
news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com...
> On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
>> <shakith.ferna...@gmail.com> wrote in message
>>
>> news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com...
>>
>>
>>
>> > Hi,
>>
>> > We have developed a High Speed on FPGA using the MGT/RocketIO to
>> > generate high speed signals. Also we receive the high speed signals
>> > using the MGT. Due to the nature of the application, we require a pure
>> > signal without encoding (We have switched off the 8B/10B encoding in
>> > the MGT). The problem is that it effects the clock recovery accuracy
>> > in the received signal as there might not be  good DC balance in the
>> > signal. Which in turn effects the data received. And MGT is a black
>> > box to us.
>>
>> > Two options-
>> > 1. Another encoding mechanism such that we have pure signal and good
>> > clock recovery.
>> > 2. Or is there a parameter in MGT to improve the clock recovery.
>>
>> > We are looking for some solution around this problem.
>>
>> > Our setup:
>> > FPGA - Xilinx Virtex II Pro
>> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
>> > Software - ISE 9.1i
>>
>> > Best Regards
>> > Shakith
>>
>> 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 

On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
> "Dave" <dhsch...@gmail.com> wrote in message
>
> news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com...
>
>
>
> > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
> >> <shakith.ferna...@gmail.com> wrote in message
>
> >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com...
>
> >> > Hi,
>
> >> > We have developed a High Speed on FPGA using the MGT/RocketIO to
> >> > generate high speed signals. Also we receive the high speed signals
> >> > using the MGT. Due to the nature of the application, we require a pure
> >> > signal without encoding (We have switched off the 8B/10B encoding in
> >> > the MGT). The problem is that it effects the clock recovery accuracy
> >> > in the received signal as there might not be  good DC balance in the
> >> > signal. Which in turn effects the data received. And MGT is a black
> >> > box to us.
>
> >> > Two options-
> >> > 1. Another encoding mechanism such that we have pure signal and good
> >> > clock recovery.
> >> > 2. Or is there a parameter in MGT to improve the clock recovery.
>
> >> > We are looking for some solution around this problem.
>
> >> > Our setup:
> >> > FPGA - Xilinx Virtex II Pro
> >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> >> > Software - ISE 9.1i
>
> >> > Best Regards
> >> >Shakith
>
> >> 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

shakith.fernando@gmail.com wrote:

(snip, someone wrote)

>>>>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.


> 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?

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

On Apr 9, 10:05=A0am, shakith.ferna...@gmail.com wrote:
> On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
>
> > "Dave" <dhsch...@gmail.com> wrote in message
>
> >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com...=

>
> > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
> > >> <shakith.ferna...@gmail.com> wrote in message
>
> > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com.=
..
>
> > >> > Hi,
>
> > >> > We have developed a High Speed on FPGA using the MGT/RocketIO to
> > >> > generate high speed signals. Also we receive the high speed signals=

> > >> > using the MGT. Due to the nature of the application, we require a p=
ure
> > >> > signal without encoding (We have switched off the 8B/10B encoding i=
n
> > >> > the MGT). The problem is that it effects the clock recovery accurac=
y
> > >> > in the received signal as there might not be =A0good DC balance in =
the
> > >> > signal. Which in turn effects the data received. And MGT is a black=

> > >> > box to us.
>
> > >> > Two options-
> > >> > 1. Another encoding mechanism such that we have pure signal and goo=
d
> > >> > clock recovery.
> > >> > 2. Or is there a parameter in MGT to improve the clock recovery.
>
> > >> > We are looking for some solution around this problem.
>
> > >> > Our setup:
> > >> > FPGA - Xilinx Virtex II Pro
> > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > >> > Software - ISE 9.1i
>
> > >> > Best Regards
> > >> >Shakith
>
> > >> The clock recovery circuitry requires that there be a minimum number =
of
> > >> received edges per unit time. Otherwise, the recovered clock edges wi=
ll
> > >> drift with respect to the data stream.
>
> > >> If you don't use some type of encoding (e.g. 8B/10B), or you don't in=
sure
> > >> that your raw data ALWAYS provides this minimum edge density requirem=
ent,
> > >> 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 t=
hat
> > 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 yo=
ur
> > 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. Thi=
s
> > 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 strea=
m.
>
> > Without a coded bit-stream you can't have DC-balance and you can't gaura=
ntee
> > frequent edges for the PLL. So if you really can't have a coded bit-stre=
am
> > 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 codin=
g
> > 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 ove=
rrun
> > 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 =A0inside 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

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

On Apr 10, 5:12 am, Peter Alfke <pe...@xilinx.com> wrote:
> On Apr 9, 10:05 am, shakith.ferna...@gmail.com wrote:
>
>
>
> > On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
>
> > > "Dave" <dhsch...@gmail.com> wrote in message
>
> > >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.com...
>
> > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
> > > >> <shakith.ferna...@gmail.com> wrote in message
>
> > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.com...
>
> > > >> > Hi,
>
> > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO to
> > > >> > generate high speed signals. Also we receive the high speed signals
> > > >> > using the MGT. Due to the nature of the application, we require a pure
> > > >> > signal without encoding (We have switched off the 8B/10B encoding in
> > > >> > the MGT). The problem is that it effects the clock recovery accuracy
> > > >> > in the received signal as there might not be  good DC balance in the
> > > >> > signal. Which in turn effects the data received. And MGT is a black
> > > >> > box to us.
>
> > > >> > Two options-
> > > >> > 1. Another encoding mechanism such that we have pure signal and good
> > > >> > clock recovery.
> > > >> > 2. Or is there a parameter in MGT to improve the clock recovery.
>
> > > >> > We are looking for some solution around this problem.
>
> > > >> > Our setup:
> > > >> > FPGA - Xilinx Virtex II Pro
> > > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > >> > Software - ISE 9.1i
>
> > > >> > Best Regards
> > > >> >Shakith
>
> > > >> 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
>
> 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

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

On Apr 9, 6:28=A0pm, shakith.ferna...@gmail.com wrote:
> On Apr 10, 5:12 am, Peter Alfke <pe...@xilinx.com> wrote:
>
>
>
> > On Apr 9, 10:05 am, shakith.ferna...@gmail.com wrote:
>
> > > On Mar 31, 11:57 am, "TC" <no...@nowhere.com> wrote:
>
> > > > "Dave" <dhsch...@gmail.com> wrote in message
>
> > > >news:940082fb-7675-4407-8c91-fd1300a0ed41@e60g2000hsh.googlegroups.co=
m...
>
> > > > > On Mar 26, 10:25 am, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:=

> > > > >> <shakith.ferna...@gmail.com> wrote in message
>
> > > > >>news:a01b5815-57f0-4f38-bade-fae9d7937826@d4g2000prg.googlegroups.=
com...
>
> > > > >> > Hi,
>
> > > > >> > We have developed a High Speed on FPGA using the MGT/RocketIO t=
o
> > > > >> > generate high speed signals. Also we receive the high speed sig=
nals
> > > > >> > using the MGT. Due to the nature of the application, we require=
 a pure
> > > > >> > signal without encoding (We have switched off the 8B/10B encodi=
ng in
> > > > >> > the MGT). The problem is that it effects the clock recovery acc=
uracy
> > > > >> > in the received signal as there might not be =A0good DC balance=
 in the
> > > > >> > signal. Which in turn effects the data received. And MGT is a b=
lack
> > > > >> > box to us.
>
> > > > >> > Two options-
> > > > >> > 1. Another encoding mechanism such that we have pure signal and=
 good
> > > > >> > clock recovery.
> > > > >> > 2. Or is there a parameter in MGT to improve the clock recovery=
.
>
> > > > >> > We are looking for some solution around this problem.
>
> > > > >> > Our setup:
> > > > >> > FPGA - Xilinx Virtex II Pro
> > > > >> > Board - Xilinx XUP Virtex(tm)-II Pro Development System
> > > > >> > Software - ISE 9.1i
>
> > > > >> > Best Regards
> > > > >> >Shakith
>
> > > > >> The clock recovery circuitry requires that there be a minimum num=
ber of
> > > > >> received edges per unit time. Otherwise, the recovered clock edge=
s 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 requ=
irement,
> > > > >> 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 assu=
me that
> > > > you are trying to eliminate the overhead of coding (with 8b10b you o=
nly get
> > > > an effective data bandwidth of 80%).
>
> > > > You didn't say whether or not you MUST have a DC-balanced signal. Ar=
e 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 com=
mon
> > > > (distributed) reference clock, or are the reference clocks independa=
nt?
>
> > > > 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 s=
tream.
>
> > > > Without a coded bit-stream you can't have DC-balance and you can't g=
aurantee
> > > > 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 ca=
nnot use
> > > > AC-coupling.
>
> > > > If you are trying to minimize the overhead of coding look at other c=
oding
> > > > 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 symb=
ols. How
> > > > are you going to know the boundaries of a byte, a packet, etc., with=
out a
> > > > coded stream and use of non-data symbols (control symbols)? If you h=
ave
> > > > 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 contr=
ol
> > > > 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 =A0inside 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
>
> > 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
>
> 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