By: Jonathan Kang (johnbk.delete@this.gmail.com), September 25, 2007 7:26 am
Room: Moderated Discussions
Michael S (already5chosen@yahoo.com) on 9/23/07 wrote:
>Why do you say that it is lousy?
>Algorithmic part of the delay imposed by 8b/10b is indeed that short. Implementation
>part of delay shouldn't be very long either - close to zero on xmt side and assuming
>implementation in CPU-class silicon about 1-2ns on the rcv side. Comparatively to
>algorithmic+implementation delay of CRC-protected packet it is lost in noise even for the short (80bit?) NACK packets.
>
>Besides, non-systematic 8b/10b encoding is needed only for AC coupling, not for
>Clock-data recovery itself. When an AC coupling is not desirable CDR could happily
>live with systematic 8b/10b or even 8b/9b encoding schemes that have zero delay.
I wasn't aware there was systematic 8b/10b. I suppose you could count bit-stuffing as an 8b/10b encoding scheme but they wouldn't add zero latency on an implementation level.
>Why do you say that it is lousy?
>Algorithmic part of the delay imposed by 8b/10b is indeed that short. Implementation
>part of delay shouldn't be very long either - close to zero on xmt side and assuming
>implementation in CPU-class silicon about 1-2ns on the rcv side. Comparatively to
>algorithmic+implementation delay of CRC-protected packet it is lost in noise even for the short (80bit?) NACK packets.
>
>Besides, non-systematic 8b/10b encoding is needed only for AC coupling, not for
>Clock-data recovery itself. When an AC coupling is not desirable CDR could happily
>live with systematic 8b/10b or even 8b/9b encoding schemes that have zero delay.
I wasn't aware there was systematic 8b/10b. I suppose you could count bit-stuffing as an 8b/10b encoding scheme but they wouldn't add zero latency on an implementation level.
