10-25-2019 08:39 AM - edited 10-25-2019 08:54 AM
We are trying to develop a customized aurora 8b/10b with working at 12Gbps, which can replace the its equivalent of 64b/66b have found with 'not in table' and 'disparity error' sometimes.
Part Number XCVU440
Mode : DFE
TX Diff ctrl : 730mv
PLL : QPPL1
Cable lengths : 3/5m
Transreciever : generated with 2018.1
The originnal aurora 8b/10b ip is modified to send the recovery sequences intermittently in order to support the hot plug features. Apparently, the robustness of 8b/10b towards error concealing capability has found to be much lower compared to that of 64b/66b, eventhough we use a data scrambling at Lane symbol encoder level!
Is there any intrinsic reason for the poor performance of 8b/10 decoding with DFE ?
10-25-2019 11:14 PM
in ethernet 10g application, the protocol uses 64/66b encoding with scrambler but in 1 g ethernet protocol only uses 8b/10b.
from my point of view, 8b/10b and scrambling have an effect on prohibiting the reciever clock from unlocking.
in an ethernet application, we can see the encoding is related to the data rate. 10/8 =1.25 ethernet 1G rate.
I think scrambling and 8b/10b have the same issue for the receiver's clock.
64b/66 encoding is only for data alignment and in 10G ethernet show, start and end of the frame by its data code part.
as a result, the main part of the benefit of using 64b/66 is for scrambling after that, this thing you have in your protocol after 8b/10b.
10-31-2019 03:15 PM