UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor newport940
Visitor
1,101 Views
Registered: ‎06-07-2018

7 Series GTX minimum line rate workaround

Jump to solution

I have a COTS FPGA board that uses a Kintex 7 xc7k325tffg900-2 FPGA.  The board has an optical port connected to one of the GTX transceiver pins on the FPGA.  The receiver at the other end is expecting 8b/10b encoded data at a nominal bit rate of 200 Mbits/sec.  However, the GTX transceiver has a minimum line rate of 500 Mbits/sec.

 

I'm currently trying to figure out a workaround so we can still use the board.  I noticed that the Series-5 Rocket IO transceivers had a feature which enabled oversampling by 5 after 8b/10b encoding to achieve line rates under the minimum supported.  A block diagram of the Rocket IO Transceiver TX path is attached.  The Series-7 GTX (block diagram also attached) does not have this feature.

 

I was wondering if I could overcome the GTX lower limit by manually 8b/10b encoding my data, then oversampling my data by a factor of 5.  Only then would I pass the data to the GTX.  In the GTX itself, I would bypass the 8b/10b encoding block.

 

 The oversampling would ideally achieve a line rate of 1000 Mbits/sec.  The receiver sampling at 200 Mbits/sec shouldn't "see" a difference.  Does anybody have any knowledge of whether this would actually work?  Are there any other GTX settings I need to be aware of to make this work?

 

Series-5 Rocket IO Transceiver TX Block Diagram.png
Series-7 GTX Transceiver TX Block Diagram.png
0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
1,047 Views
Registered: ‎07-30-2007

Re: 7 Series GTX minimum line rate workaround

Jump to solution

The app note concentrates on the RX because that is the hard part.  I don't see any reason why your method won't work for the TX side.

Roy


----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


0 Kudos
4 Replies
Explorer
Explorer
1,069 Views
Registered: ‎02-22-2010

Re: 7 Series GTX minimum line rate workaround

Jump to solution

See xapp1240: Clock and Data Recovery Unit based on Deserialized Oversampled Data (NIDRU)

 

Also check this at the forum How can NI-DRU module deal with 8b/10b protocol

 

Regards,

Eze

Visitor newport940
Visitor
1,057 Views
Registered: ‎06-07-2018

Re: 7 Series GTX minimum line rate workaround

Jump to solution

Eze,

 

Thanks for the links.  The xapp1240 unfortunately seems to be focused on the rx side, which I have no control over.  In the forum post you linked, the author asked a follow-up question to the xilinx employee about the tx side.  I've coped it below.  He's asking about exactly what I want to do.  However, there was no further responses in the thread.

 

Can anybody comment on the validity of doing below?

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

One more question. How about the TX end?

16 bits user data ------> stand alone 8b/10b encoder -------> every bit repeat 4 times -------> RAW 1Gbps GTX

Like this?

 

0 Kudos
Moderator
Moderator
1,048 Views
Registered: ‎07-30-2007

Re: 7 Series GTX minimum line rate workaround

Jump to solution

The app note concentrates on the RX because that is the hard part.  I don't see any reason why your method won't work for the TX side.

Roy


----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
----------------------------------------------------------------------------


0 Kudos
Advisor evgenis1
Advisor
1,034 Views
Registered: ‎12-03-2007

Re: 7 Series GTX minimum line rate workaround

Jump to solution

Hi @newport940 , 

 

One potential problem might be related to the fact that Tx side applies preemphasis to the signal before it gets out. Preemphasis (pre- and post-cursors) depend on the bit rate, which is still 5 times higher than receiver is going to recover. If your Tx->Rx channel is good, only little preemphasis would be required, and receive side might properly recover such signal. However, adding lot of preemphasis might be a problem.

 

Thanks,

Evgeni

Tags (2)