By: Jonathan Kang (johnbk.delete@this.gmail.com), September 26, 2007 6:24 am
Room: Moderated Discussions
Michael S (already5chosen@yahoo.com) on 9/25/07 wrote:
---------------------------
>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.
>
From what I've read of the various Rambus patents that seem to relate to this (7271623 and 7269706 are interesting in particular), it seems that they've been able to cut power consumption by improving upon just about every component in a transmission link in an iterative fashion. For instance, they've made a very sensitive receiver that does selective amplification based on a reference clock to cut on transmission pre-emphasis power, etc.
This does not, however, get around the fundamental issue of the link having to be active at all times. Remember that whatever power figures given for parallel links such as CSI are only the active power figures. When comparing it to a serialized link, even a low-powered one like the one Rambus has, one has to take into account average power.
---------------------------
>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.
>
From what I've read of the various Rambus patents that seem to relate to this (7271623 and 7269706 are interesting in particular), it seems that they've been able to cut power consumption by improving upon just about every component in a transmission link in an iterative fashion. For instance, they've made a very sensitive receiver that does selective amplification based on a reference clock to cut on transmission pre-emphasis power, etc.
This does not, however, get around the fundamental issue of the link having to be active at all times. Remember that whatever power figures given for parallel links such as CSI are only the active power figures. When comparing it to a serialized link, even a low-powered one like the one Rambus has, one has to take into account average power.
