cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
429 Views
Registered: ‎08-06-2019

Incorrect data pattern received at GTH transceiver output with known data injected at input

Hi,

I am using ZYNQ ZCU102 board for establishing a GTH link at 2.5 Gbps.

The link is AC coupled, without 8/10b encoding. Following is the snapshot of the GTH specs:GTHspecs_1.PNG

I have enabled Tx/Rx bypass buffers to tolerate phase differences between SIPO side clock and PMA/PCS layer clocks.

My TEST with known data pattern:

Case1: 16-bit constant pattern

I disabled the PRBS stimulus data connected to GTH wrapper i.e, hb0_gtwiz_userdata_tx_int and instead tied it to following:

assign hb0_gtwiz_userdata_tx_int=16'hABCD;

Thus the GTH TX serialises this data to 2.5 Gbps stream and it goes over SMA cable to RX where it is parallelised back to 16 parallel streams running at 156.25 MHz. There I capture this data using ILA and bring it out in CSV file.

The pattern "ABCD" can be easily located in the captured stream repeatedly confirming the link is working fine in this case. I tested with several such 16-bit patterns and all the patterns are recovered exactly.

Case2: 16-bit pattern0->pattern1->pattern0 and so on

Again, I disabled the PRBS stimulus data connected to GTH wrapper i.e, hb0_gtwiz_userdata_tx_int and instead tied it to the following:

assign hb0_gtwiz_userdata_tx_int=(CTR==0?16'h4567:16'hABCD);//CTR updated as below

//CTR update wrt hb0_gtwiz_userclk_tx_usrclk2_int

reg CTR;//init to 1'b0

always @(negedge hb0_gtwiz_userclk_tx_usrclk2_int)
            CTR=~CTR;
end

Thus, the two patterns 16'h4567 & 16'hABCD are repeatedly switched and sent over the channel.

When I capture the final 16-bit RX data over the ILA, I expected to find repeating hex string like "4567-ABCD-4567-ABCD....".

However, I am getting the pattern as follows:

"4567" --(mentioned in HEX for readability) followed by binary string

"100101011110011010"  repeating again and again forever. This does not match the expected pattern.

In this case, the "4567" portion is received correctly but rest of the portion seems to be off.

I am choosing "buffer enable" option to ensure tolerance to phase differences between SIPO clock and RX recovered clock.

Can you please suggest why two repeating patterns result in incorrect data capture while one repeating pattern is captured accurately?

Thanks and regards

Alok Baluni

0 Kudos
7 Replies
Highlighted
Moderator
Moderator
416 Views
Registered: ‎07-30-2007

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

You are sending raw data.  You have no way to align the serial to parallel converter.  See the byte alignment section of the User Guide. Need to see other settings for know for sure what else could be going on.  Did you enable comma alignment?  In loopbackmode you cannot use a reset all or you could lock the CDR to the wrong frequency.  The other problem is that your pattern is not dc balanced and even a small imbalance will build up quickly on the AC coupling cap and cause the data to be corrupted.




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


Highlighted
Observer
Observer
353 Views
Registered: ‎08-06-2019

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

Hi,

Thanks for your reply.

1. Byte Alignment

I am not expecting byte aligned data in the sense that the repeated pattern is ok with some latency

Hence, I am ok to receive "567A-BCD4-567A....."  instead of getting exactly "4567-ABCD-4567......".

My final application requires transmitting serial data @2.5 Gbps (from another board) to be captured within FPGA through RX GTH.

2. LOOPBACK Mode

In this case I am not using loopback mode. I am transmitting data over SMA cable from TXP/TXN to RXP/RXN in ZCU102 board.

3. DC Balance:

The pattern ABCD has a running disparity of 4. Similarly, "4567" has a running disparity of 0. Individually these patterns are received without error.

Combining these patterns result in the same running disparity of 4 for "ABCD-4567".

Hence I was wondering if it is possible that the error may be caused due to the fact that there is an interaction between high speed internal clock @ 2.5 Gbps and parallel clock at 2.5/16=156.25 MHz. Every time the serial data is converted to parallel data, the 16b data is retreived with a slow parallel clock which may cause misalignment. To take precautions, I am using buffer enable option in wizard. Are ther any extra measures to ensure safe data capture across clock domains.

Thanks and regards

Alok Baluni

 

0 Kudos
Highlighted
Observer
Observer
340 Views
Registered: ‎08-06-2019

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

One quick point, I tested the GTH in DC coupled mode.
The double-repeat pattern "4567-ABCD" is captured correctly. Then I tested triple-repeat pattern "4567-ABCD-6AB6" and again the capture is off. Does this rule out DC balance as the potential cause of error? Also the pattern seems to have effective running disparity within 4-5. Is that enough for CDR?
0 Kudos
Highlighted
Moderator
Moderator
301 Views
Registered: ‎07-30-2007

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

I think you are doing a loopback even if the loopback isn't with the loopback command.   You say you are sending the TX through a cable to the RX if I understand it right.  What will happen with a reset_all is that the TX reset will interupt the TX output while the RX is doing it's Clock Data Recovery lock.  This could cause it to lock to the wrong frequency. 

Typically we have a running disparity of 0. I have seen customers have problems with a running disparity of 1. 

The DC balance is the concern for the disparity and the CDR is concerned mostly with having a stable RX input.  The dc balance could affect the CDR but we would mostly be concerned with it corrupting the data.

 




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


0 Kudos
Highlighted
Observer
Observer
292 Views
Registered: ‎08-06-2019

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

Hi  

0 Kudos
Highlighted
Moderator
Moderator
287 Views
Registered: ‎07-30-2007

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

Keep in mind if the CDR frequency is off slightly you can get a situation where the data is periodically correct.  Not sure from the description whether this could be part of the problem. It surprises me that you ever get correct data with a disparity of 4 in an ac coupled system.  I often see unbalanced data causing problems.




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


0 Kudos
Highlighted
Observer
Observer
275 Views
Registered: ‎08-06-2019

Re: Incorrect data pattern received at GTH transceiver output with known data injected at input

Hi roym,

Thanks for reply. I surveyed some ARs to find a solution to this problem.

AR#53107 (7-series) mentions that there is an option to lock CDR to reference which can be achieved by setting RXCDRHOLD=1'b1 && RXCDROVRDEN=1'b0. This can keep CDR stable and set the high speed clock always at desired link rate. Only problem is to align it to the incoming data rate so that it samples in middle of bit interval and not near edges. This can be achieved again in two ways:

1. Control the phase of RX phase interpolator if allowed. I understand this can be achieved through the RXCDR_CFG setting which allows to fine tune RX clock phase. Can you please enlighten on how to do this?

2. For fixed link rate of 2.5 Gbps, I can oversample the data at, say 10 Gbps, and use the redundancy in sampled data to recover the exact incoming bit sequence like in oscilloscope.

Do you think these methods look feasible?

Thanks and regards

Alok Baluni

 

 

0 Kudos