By: Michael S (already5chosen.delete@this.yahoo.com), September 24, 2007 12:40 am
Room: Moderated Discussions
David Kanter (dkanter@realworldtech.com) on 9/23/07 wrote:
---------------------------
>Michael S (already5chosen@yahoo.com) on 9/23/07 wrote:
>---------------------------
>>David Kanter (dkanter@realworldtech.com) on 9/23/07 wrote:
>>---------------------------
>>>Michael S (already5chosen@yahoo.com) on 9/23/07 wrote:
>>>
>>>>Nah. Algorithmic delay of 8b/10b decoding is equal to 10T >regardless of the size
>>>>of packet. At CSI data rates 10T=1.5ns=lost in noise.
>>>
>>>No, it's not. At 6.4GT/s that means you have the effective latency of a 0.64GT/s
>>>interface, which is just lousy.
>>
>>Why do you say that it is lousy?
>>Algorithmic part of the delay imposed by 8b/10b is indeed >that short.
>
>I wouldn't call 10 cycles short. Suppose you have a larger IPF system with 64
>processors, arrayed in 4 socket cells...you're going to have at least 3 hops to
>get to remote processors (although perhaps only 2 to hit the remote directory).
>That's a minimum 20-30 cycle delay you are adding.
>
First, I think that larger IPF systems would have directory (or, at least some form of directory cache) 1 hop away. Second, 20-30T (3-5ns) is indeed very short time when compared to directory lookup.
Second, it is unlikely that you can connect such a big box with DC-coupled links. So you would need to ad DC-balancing layer on top of plain CSI. That layer would have its own non-zero delay. Or, more likely, you will run CSI between boards by means of completely different phy.
>>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.
>
>How do you know that CRC calculations are blocking? CRC errors rarely occur, so
>I would design my interconnects to speculate that no CRC errors occur, with a way to replay if they do occur.
>
I don't know whether it is blocking or not, but pass-through routing fall out of favor in high-speed network infrastructure equipment a long time ago. I'd guess there were reasons for preferring store-and-forward implementations over pass-through probably related to corner cases in error recovery. So I expect that at least first few generation of CSI would avoid path-through.
>>Besides, non-systematic 8b/10b encoding is needed only for >AC coupling, not for
>>Clock-data recovery itself.
>
>Hrmm...could you elaborate?
>
>>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.
>
>What exactly do you mean?
>
"In coding theory, a systematic code is one in which the input data are embedded in the encoded output"
http://en.wikipedia.org/wiki/Systematic_code
Examples of systematic code used for error detection/correction are parity, classic ECC and turbo-codes, CRC etc...
More relevant for our discussion is a very popular 1-bit delay 8b/10b systematic code used in an ancient asynchronous transmission protocol:
b0:b1:b2:b3:b4:b5:b6:b7 => 0:b0:b1:b2:b3:b4:b5:b6:b7:1
Some of the simpler Natsemi LVDS serdes products use this simple "code" despite its obvious shortcomings.
You could easily modify it to achieve 0-bit delay:
b0:b1:b2:b3:b4:b5:b6:b7 => b0:b1:b2:b3:b4:b5:b6:b7:1:0
Despite being used in practice that simple code is not as good as Franaszek&Widmer code implemented in PCIe even ignoring DC-balance because it doesn't guarantee the transition density. However you can easily go one step better.
Here is very simple 8b/10b 1-bit delay code that does guarantee the same maximal run length as Franaszek&Widmer:
b0:b1:b2:b3:b4:b5:b6:b7 => b0:b1:b2:b3:~b3:b4:b5:b6:b7:~b7
Now an exercise for you: propose 8b/10b 2-bit delay code that guarantee maximal run length of 5 and provides DC-balance which is not significantly worse (in terms of lowest remaining frequency) than Franaszek&Widmer.
>[snip]
>
>Well it's the average power consumption that matters the most. Maximum only matters
>for power distribution and heatsinks.
>
>DK
Exactly. Power bill depends on average power consumption. Equipment cost depends on maximum. Despite the buzz the later tends to be much bigger than the former.
---------------------------
>Michael S (already5chosen@yahoo.com) on 9/23/07 wrote:
>---------------------------
>>David Kanter (dkanter@realworldtech.com) on 9/23/07 wrote:
>>---------------------------
>>>Michael S (already5chosen@yahoo.com) on 9/23/07 wrote:
>>>
>>>>Nah. Algorithmic delay of 8b/10b decoding is equal to 10T >regardless of the size
>>>>of packet. At CSI data rates 10T=1.5ns=lost in noise.
>>>
>>>No, it's not. At 6.4GT/s that means you have the effective latency of a 0.64GT/s
>>>interface, which is just lousy.
>>
>>Why do you say that it is lousy?
>>Algorithmic part of the delay imposed by 8b/10b is indeed >that short.
>
>I wouldn't call 10 cycles short. Suppose you have a larger IPF system with 64
>processors, arrayed in 4 socket cells...you're going to have at least 3 hops to
>get to remote processors (although perhaps only 2 to hit the remote directory).
>That's a minimum 20-30 cycle delay you are adding.
>
First, I think that larger IPF systems would have directory (or, at least some form of directory cache) 1 hop away. Second, 20-30T (3-5ns) is indeed very short time when compared to directory lookup.
Second, it is unlikely that you can connect such a big box with DC-coupled links. So you would need to ad DC-balancing layer on top of plain CSI. That layer would have its own non-zero delay. Or, more likely, you will run CSI between boards by means of completely different phy.
>>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.
>
>How do you know that CRC calculations are blocking? CRC errors rarely occur, so
>I would design my interconnects to speculate that no CRC errors occur, with a way to replay if they do occur.
>
I don't know whether it is blocking or not, but pass-through routing fall out of favor in high-speed network infrastructure equipment a long time ago. I'd guess there were reasons for preferring store-and-forward implementations over pass-through probably related to corner cases in error recovery. So I expect that at least first few generation of CSI would avoid path-through.
>>Besides, non-systematic 8b/10b encoding is needed only for >AC coupling, not for
>>Clock-data recovery itself.
>
>Hrmm...could you elaborate?
>
>>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.
>
>What exactly do you mean?
>
"In coding theory, a systematic code is one in which the input data are embedded in the encoded output"
http://en.wikipedia.org/wiki/Systematic_code
Examples of systematic code used for error detection/correction are parity, classic ECC and turbo-codes, CRC etc...
More relevant for our discussion is a very popular 1-bit delay 8b/10b systematic code used in an ancient asynchronous transmission protocol:
b0:b1:b2:b3:b4:b5:b6:b7 => 0:b0:b1:b2:b3:b4:b5:b6:b7:1
Some of the simpler Natsemi LVDS serdes products use this simple "code" despite its obvious shortcomings.
You could easily modify it to achieve 0-bit delay:
b0:b1:b2:b3:b4:b5:b6:b7 => b0:b1:b2:b3:b4:b5:b6:b7:1:0
Despite being used in practice that simple code is not as good as Franaszek&Widmer code implemented in PCIe even ignoring DC-balance because it doesn't guarantee the transition density. However you can easily go one step better.
Here is very simple 8b/10b 1-bit delay code that does guarantee the same maximal run length as Franaszek&Widmer:
b0:b1:b2:b3:b4:b5:b6:b7 => b0:b1:b2:b3:~b3:b4:b5:b6:b7:~b7
Now an exercise for you: propose 8b/10b 2-bit delay code that guarantee maximal run length of 5 and provides DC-balance which is not significantly worse (in terms of lowest remaining frequency) than Franaszek&Widmer.
>[snip]
>
>Well it's the average power consumption that matters the most. Maximum only matters
>for power distribution and heatsinks.
>
>DK
Exactly. Power bill depends on average power consumption. Equipment cost depends on maximum. Despite the buzz the later tends to be much bigger than the former.
