cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
452 Views
Registered: ‎07-31-2019

GTX transceiver Wizard Configuration

Jump to solution

Hi all,

I'm trying to use GTX as PHY to implement a in-house HDMI IP. After went throught all the related documents I still have questions:

1. 8B/10B encoder/decoder is not needed in my case, but still I want features like byte/word comma alignment, channel bonding, Clock correction.

It seems these features are not availabe (except clock correction) when 8B/10B is disabled. How should I enable these features?

2. In what scenario, Tx/Rx buffer should be bypassed? What's the advantage/disadvange of each way (enabling vs. disabling)?

3. How to choose the Tx/Rx OUT clock source? REF clock or Recovered clock? I'd prefer to use Recovered clock, but want to know more of the trade-off.

4. How to choose the clock correction sequence?

5. If the byte/word/lane alignment is done using FPGA user logic, what settings should be chosen for "channel bonding" and "comma alignment" on Wiard GUI?

Thanks in advance,

Chris

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
434 Views
Registered: ‎07-30-2007

Re: GTX transceiver Wizard Configuration

Jump to solution

The problem that you run into with trying to use comma alignment without 8B10B encoding is that you need to keep the comma character unique.  Consider for a 15 wide setup you choose 0x0010 for the comma character.  Then if you send 0x8001 0x0AAA  the 0010 portion would look like an out of place comma and trigger a realignment as would 0x8002 0x0AAA.  8B10B allows you to set a completely unique comma character.  Clock correction and channel bonding would have the same issue.  You need unique characters to use for the channel bonding or Correction character.  The alternative you could use is 64B/66B encoding which has a separate mechanism for block lock which would also lend itself to channel bonding.  64B66B protocols use the recovered clock to driver the RXUSRCLK's and FPGA logic so that clock correction would not be needed.

Bypassing the buffers is used to reduce latency on the RX side and reduce TX skew on the transmit.  The latency you gain is small so you should avoid buffer bypass if you can to reduce the complexity and make more robust designs.

If you choose the recovered clock the advantage is you don't need clock correction.  The disadvantage is that this takes more clocking resources and the TX and RX domains will be running at slightly different speeds.

If you do the channel bonding in the fabric you leave the checkboxes blank for correction and channel bonding so as not to enable them.

 

 

 

 




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


View solution in original post

4 Replies
Highlighted
Moderator
Moderator
435 Views
Registered: ‎07-30-2007

Re: GTX transceiver Wizard Configuration

Jump to solution

The problem that you run into with trying to use comma alignment without 8B10B encoding is that you need to keep the comma character unique.  Consider for a 15 wide setup you choose 0x0010 for the comma character.  Then if you send 0x8001 0x0AAA  the 0010 portion would look like an out of place comma and trigger a realignment as would 0x8002 0x0AAA.  8B10B allows you to set a completely unique comma character.  Clock correction and channel bonding would have the same issue.  You need unique characters to use for the channel bonding or Correction character.  The alternative you could use is 64B/66B encoding which has a separate mechanism for block lock which would also lend itself to channel bonding.  64B66B protocols use the recovered clock to driver the RXUSRCLK's and FPGA logic so that clock correction would not be needed.

Bypassing the buffers is used to reduce latency on the RX side and reduce TX skew on the transmit.  The latency you gain is small so you should avoid buffer bypass if you can to reduce the complexity and make more robust designs.

If you choose the recovered clock the advantage is you don't need clock correction.  The disadvantage is that this takes more clocking resources and the TX and RX domains will be running at slightly different speeds.

If you do the channel bonding in the fabric you leave the checkboxes blank for correction and channel bonding so as not to enable them.

 

 

 

 




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


View solution in original post

Highlighted
Explorer
Explorer
347 Views
Registered: ‎08-04-2016

Re: GTX transceiver Wizard Configuration

Jump to solution

Hi @cdu 

 

Were you able to figure out the settings required in wizard?

Can you share your findings?

 

Thanks.

0 Kudos
Highlighted
Observer
Observer
335 Views
Registered: ‎07-31-2019

Re: GTX transceiver Wizard Configuration

Jump to solution

I plan to write down a list of findings in the near future, after IP been implemented and verified.

Highlighted
Observer
Observer
299 Views
Registered: ‎07-31-2019

Re: GTX transceiver Wizard Configuration

Jump to solution

Before working down my in-house HDMI way, some of the findings are listed as below:

1. Since GTX internal 8B/10B encoder/decoder is not needed, not only because it'll decrease the bandwidth efficiency for a further 20%, but also not a recommended approach. The GTX internal byte/word comma alignment, channel bonding logic tightly coupled with 8B/10B can not be used for it's own purpose. FPGA logic will be used to implement same functionalities, cause for almost all features could be done in such a way for PCS portion.

2. The recovered clock will be used to drive the RXUSRCLK2 so clock correction is not needed as well.

3. There are a number of alternative way to choose the synchronization character for TMDS coding, depending the specific video format. In my case the CTRL was chosen as byte alignment character.

Chris

0 Kudos