02-13-2020 12:47 PM
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:
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:
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)
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
02-13-2020 01:02 PM - edited 02-13-2020 03:27 PM
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.
02-13-2020 10:48 PM
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
02-14-2020 12:40 AM
02-14-2020 08:00 AM
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.
02-14-2020 08:34 AM
Thanks a lot for your feedback.
Yes, you are right. Connecting TXP/N and RXP/N with SMA cables would be technically called as channel loopback :).
I guess if reset_all was causing RX input to become unstable, then it should affect the correct data portion ("4567") as well. However, the pattern repeats with the string of correct data ("4567") mixed with incorrect data deterministcally. I am not re-asserting reset_all once the link is operational.
DC balance requirement to avoid capacitor charge build-up can be alleviated by using DC-coupled interface.
Still, it seems likely, as you said, that disparity of 4 may cause CDR lock to drift. However, strangely, this issue didn't show up with a single pattern like "ABCD" with a disparity of 4. That's what made me wonder about the issues showing up only when there are atleast two different 16b words being transmitted.
Thanks and regards
02-14-2020 08:49 AM
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.
02-14-2020 10:09 AM
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