cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
1,471 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
Highlighted
Moderator
Moderator
1,417 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.




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


View solution in original post

0 Kudos
4 Replies
Highlighted
Explorer
Explorer
1,439 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

Highlighted
Visitor
Visitor
1,427 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
Highlighted
Moderator
Moderator
1,418 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.




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


View solution in original post

0 Kudos
Highlighted
Advisor
Advisor
1,404 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)