11-06-2019 07:42 AM
Hi Team ,
we are using kcu105 xilinx board and generated 32bit plain serdes with bitrate 6gpbs.
we generated 32bit incremented data with data gen module . It increments data every cycle by one .
At TX side :
Generated 32bit data was passed through 32bit to 40bit encoder ( used four 8b10b encoders ) . Encoder output passed through 40bit to 32bit convertor . That 32bit is feed to serdes .i.e.,
Initially after reset we are transmitting 24'FFFFFF cycles D10.2 characters for proper bit lock , 24'FFFFFF cycles of COMMA's (data = BCBCBCBC and k= 1 ) for symbol lock.
32bit data_gen ==> Encoder ==> 40bit to 32bit convertor ==> serdes
At RX side :
serdes ==> 32bit 40bit convertor ==> comma_alignment logic ==> Decoder ==> data_checker .
=> In comma_alignment logic we are finding 40bit exact boundary (encoded comma_value ) and drops all comma's inside comma_alignment . and passes remaining data to Decoder and data_checker .
Observations in lab :
1) we are receving frequently errors in data_checker module because we are not receiving Incremented at same time becasue at that time data gets corrupted or flips .
For debugging we tested logic in two modes to find it's serdes issue or RTL issue .
1st mode : BYPASS serdes
Tx side :
data_generation ==> encoder ==> 40bit to 32bit convertor
At RX side : output of transmitted data is connected at Rx path (40bit to 32bit convertor output was connected to 32bit to 40bit convertor ).
32bit to 40bit convertor ==> comma_alignment ==> Decoder ==> data checker .
data checker was working properly with no errors .
2nd mode :
Tx side :
data generation ==> Encoder ==> 40bit to 32bit convertor ==> serdes
At Rx side :
serdes ==> 32bit to 40bit convertor ==> comma_alignment ==> decoder ==> data_checker .
data checker was receving errors frequently.
With this I understood that error was introduced in serdes itself .
one important thing is , when data gen module generated 16bit data and MSB 16bits tied to zero. i.e., ( data[31:16] = 0 and only incrementing data[15:0] ) .
with same logic i validated in fpga board at this time i am not receiving errors .
simillarly lower 16bits tied to zero and upper 16bits only incrementing also we are not receiving errors .
But when we generated 32bit data , we are receiving contiuosly errors at data checker .
can you say why serdes was misbehaving like that ??
no timing issues .
11-11-2019 02:01 AM
your observation may have occurred because of your link if you use fiber optics check connectivity, clear your fiber and advanced part of GT wizard. insertion loss, equalization mode, link coupling and so on.
11-11-2019 02:43 AM
We used SMA cables there was no issue in connection because when 16 bit data was generated i.e., (MSB 48bits tied to zero and remainig 16 bits were incremented by one in every cycle at that time there was no issue , Data was receiving from serdes as we expected .
When we generated 64 bit incremented pattern we are facing issue .
We generated 32 bit raw serdes With no internal encoding or decoding . NO internal PRBS pattern generation .
11-11-2019 02:53 AM
11-11-2019 03:19 AM
Before going to test logic i am doing simulations . If simulations were good then only i am going to validate the code in FPGA board .
With above setup simulations were passed . But in fpga board serdes itself flips random bits .
If i am missing any setup or someother .
we used board sys_clk (125 MHz ) and programming si570 clk (120 mhz ) using tera software .
Other than these 32 bit serdes required any other programmings ??
11-11-2019 03:59 AM
Similarly when we generated 64 bit fixed pattern ( random data ) in these case also there was no error .
In simualtions we generated 64 bit randomised data even though there was no issue in simulation.
But when we generating 64 bit incremented pattern then only errors were received in another board .
Serdes bitrate 6 Gbps and generated Tx_outclk = 187.5 Mhz using CPLL as parameter .
Is it necessary to use parameter Txbuffer* while generating serdes IP . ?? because we used Rx buffer only while generating serdes IP.
( or )Serdes may cannot operate at 187.5 Mhz ??
11-11-2019 08:51 AM
You seem to be sending multiple comma characters in a row. If this is the case and you are trying to align to a particular boundary you will trigger alignments that you don't want. Check the byte is aligned and byte realign ports. If this is the problem you might need to rearrange your signal or turn off alignment once alignment is acheived.
11-11-2019 08:13 PM
While generating serdes IP itself I disabled internal comma_alignment .
Still i need to turn_off byte_aligned and byte_realigned ports ?? (I don't have control on byte_aligned or byte_realigned ports because those ports are output ports to serdes ) .
If above above was the issue then why it can't recreate same issue while we generated 64bit fixed pattern or 64 bit incremental pattern (i.e., data[63:16]=0 , data[15:0] incremented every cycle ) ??
Can anyone suggest how to generate 32bit plain serdes with data_width 32 and data rate 6Gbps . What are the parameters or primitives i have to use while generating ??
I used CPLL , sys_clk 125 mhz , SI570 clk 120MHZ . And all internal comma_alignments , encoders/decoders disabled . Other than these still i need to some other parameters related to serdes ??
11-14-2019 02:59 AM
hi @vishnu_123 ,
First, I am wondering why you create a 32 bit user data width core, when you have 40 bits of data. You could create a transceiver core with raw data and a user data width of 40. You would save yourself the converters.
That, of course, does not explain the errors you see. It might be that this is coming from the initial bursts you are sending, D10.2 and K28.5. D10.2 is a clear clock signal and K28.5 in long sequences shows low frequency components. Maybe you can break this up a bit when you do not send a full block of K28.5. For alignment on a 40bit boundary one K28.5 in the upper or lower byte would suffice. You could fill the other 3 bytes with random data. Would that be possible with your alignment block?
11-18-2019 08:05 PM
In ASIC we already have 32 bit serdes . so we went over all that conversion s.
I re_generated serdes with some extra input and output debug ports (tx_data_path_reset_in* , rx_data_path_reset_in *, txbuff_bypass enable ports , some other reset done outputs like txpcs_reset_done ,rx_pcs_reset_done, tx_pma_reset_done ,rx_pma_reset_done etc ) .
I not used output ports anywhere in logic and I tied to zero for all reset_in input ports .
With newly generated serdes the above issue is resolved and working as expected .
I don't know any reason why it's working with above serdes and why not with previously generated serdes . can anyone know answer ??