By: Michael S (already5chosen.delete@this.yahoo.com), September 25, 2007 1:57 pm
Room: Moderated Discussions
Jonathan Kang (johnbk@gmail.com) on 9/25/07 wrote:
---------------------------
>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.
Systematic 8b/10b with maximal run length of 5 indeed would add 1-bit latency. But there is very simple zero-delay 4b/5b code:
b0:b1:b2:b3 => b0:b1:b2:b3:~b3
4 bits/lane * 5 lane = 20 bits - big enough for address of packet.
Please, don't take me wrong, I do not think that delay of normal 8b/10b code at CSI data rate could make any difference. I brought systematic codes into discussion just to show to David that his exlanation of the reasons why Intel went with parallel phy doesn't hold water.
I fully agree with you that most likely reason for Intel's decision is related to the power cost of maintaining serial link in "locked" low latency state.
However according to the article linked below RUMBUS has the problem solved.
http://www.eetimes.com/issue/fp/showArticle.jhtml?articleID=197004941
Now I see that they (RAMBUS) demonstrated 6.25 Gbps 2.2 mW/Gbps link at latest IDF.
---------------------------
>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.
Systematic 8b/10b with maximal run length of 5 indeed would add 1-bit latency. But there is very simple zero-delay 4b/5b code:
b0:b1:b2:b3 => b0:b1:b2:b3:~b3
4 bits/lane * 5 lane = 20 bits - big enough for address of packet.
Please, don't take me wrong, I do not think that delay of normal 8b/10b code at CSI data rate could make any difference. I brought systematic codes into discussion just to show to David that his exlanation of the reasons why Intel went with parallel phy doesn't hold water.
I fully agree with you that most likely reason for Intel's decision is related to the power cost of maintaining serial link in "locked" low latency state.
However according to the article linked below RUMBUS has the problem solved.
http://www.eetimes.com/issue/fp/showArticle.jhtml?articleID=197004941
Now I see that they (RAMBUS) demonstrated 6.25 Gbps 2.2 mW/Gbps link at latest IDF.
