Re: Short Reply to Note by R. Taborek `Hari Byte vs. Word Striping'dated 26 Nov. 1999.
Hi Al,
Thanks for your frank comments on my note comparing Hari Byte vs. Word Striping. I look
forward to your long reply which hopefully addresses all of the evaluation criteria
which I amassed. Please also feel free to add/or remove any evaluation criteria you feel
relevant to the resolution of this issue. I believe that I have done my best to provide
a balanced system perspective on all criteria presented to date.
widmer@xxxxxxxxxx wrote:
> Thank you for sharing your views on some issues related to the Hari
> interface. From your referenced treatise and prior statements, I get the
> impression that you are utterly confused about some fundamental as well as
> the detailed features of our proposal and you have seriously
> misrepresented, probably inadvertently, some aspects of it. Also, with
> respect to implementation and circuit questions, your evaluation criteria,
> preferences and value scales appear to be in conflict with what I think
> experienced designers in this area would normally judge as appropriate. So
> it is no surprise that some of your conclusions strike me as outlandish.
Al,
As we attempt to resolve the issue before us, I'd like to bed your indulgence in, as
Jonathan Thatcher has so eloquently put it, "respectful, dignified, technical
discussions, which have been an earmark of previous 802.3 communications". My
proficiency at architecting optimal solutions for communications links, originally
nurtured at IBM, is well known in the industry. I have a very thorough understanding of
the word striping proposal authored by Mr. Jenkins, Mr. Ritter and yourself and disagree
with it as a striping methodology for Hari based on its lack of technical merit. I urge
you to please keep our very public discussions on a professional level.
> Far more disturbing is the fact that you seem to be unable to arrive at a
> fair conclusion even where the differences are trivial and simple to
> understand. Just as an example, I cite your handling of item 9) Running
> Disparity Processing: I think, I am well qualified to evaluate this
> function, since for over 2 decades I have been involved with various codec
> designs and many individuals inside and outside my company have asked me
> for help . Quite recently, I have designed an 8B/10B codec for 12.5 Gbaud
> operation. So I know for sure, there is no significant difference in the
> coding area for byte or word striping, but there is a slight performance
> advantage for a word based codec because disparity prediction can be
> applied more effectively. With current technologies available to anyone,
> just four codecs are required for either case, the only difference is how
> they are ganged together which is utterly trivial. As you correctly point
> out, at the receiving end of each lane, the bit pattern must be checked for
> invalid characters and disparity violations and these circuits are
> identical to what is needed for disparity adjustment which requires just
> about 50 additional gates and the whole thing is less than a decoder with
> checks. It is also obvious that either a byte striped or word striped Hari
> can be connected to a scrambled or a 64B/66B coded link with comparable
> ease or difficulty. An 8B/10B coded 12.5 Gbaud link is also a viable option
> and both Hari versions have to adjust the disparity, but the byte striped
> version as currently defined has a known disadvantage because its Idle
> structure is ill suited for byte and word alignment at high speeds (It
> requires more complex pattern detection circuits with added delay in a
> critical area.) My recommendation would be to simply translate the current
> Hari Idle for transmission over the 12.5 Gbaud single lane to an Idle word
> resembling the Fibre Channel Idle . Based on these verifiable facts, it
> is hard to understand how you can justify the attribution of a bonus point
> for the current Hari version.
I believe that you are missing the point of my Running Disparity Processing argument.
Using the example of a Serial PMD, there are two separate Running Disparity Processes
which must occur:
a) The processing of running disparity on each Hari lane at the receive to insure the
integrity of the received data.
b) Post processing of the running disparity to correct for the disruptive effects of
multiplexing multiple unsynchronized encoded 8B/10B code streams into a single stream
for retransmission at the multiple rate.
(a) can clearly be implemented at the same rate regardless of striping granularity.
This is a wash as you and I agree.
(b) is a solution in search of a problem. The key goal of P802.3ae is to develop cost
effective PHY(s). A strong contender for this PHY is the Serial PMD. The Serial PMD must
support the transport, at most, 10 Gbps of data, not 12.5 Gbps. The Opto-Electronics
industry has developed a plethora of 10 Gbps components, primarily in support of SONET
OC-192 equipment, some of these capable of operating at 12.5 Gbps as was presented to
the HSSG in Kauai. I applaud these latter components but my gut tells me that it's
better to keep the line rate down as low as possible to ease a number of factors
including cost, EMI, packaging, etc. What a boom it is to already have 10 Gbps
components in hand!
Sorry about the above tangent. My point is that Running Disparity post processing in
support of Serial 12.5 Gbps PMDs is NOT a benefit from a communications link perspective
in view of the available alternatives. Running Disparity post processing is not required
for Serial 10.3125 Gbps PMDs, those employing 64B/66B encoding since all 8B/10B lanes
must be decoded prior to 64B/66B. I am glad that you also agree with this point.
Byte-Striping does not require nor condone (b) in support of Serial Fiber-Optic
Communications Links architected to support data rates of 10 Gbps. Therefore, my
conclusion is that Byte-Striping gets this bonus point.
As for your statement "but there is a slight performance advantage for a word based
codec because disparity prediction can be applied more effectively", I'm not sure if I
understand this issue or its relevance. My understanding is that there is no way to
"predict" disparity in a stream of data in which the individual data words have random
disparity characteristics. Disparity prediction may be employed within an Idle stream.
However, since no data is being transported, and in light of the fact that most 8B/10B
code-group streams consist of Idles interspersed with data, this attribute is
irrelevant.
> We will reply soon with details and attempt to present a more balanced
> perspective on other issues as well.
>
> Albert Widmer
> Phone: 914 945-2047 email: widmer@xxxxxxxxxx
> IBM T.J. Watson Research Center
> P.O. Box 218
> Yorktown Heights, New York, 10598-0218
--
Best regards,
Rich
----------------------------------------------------------
Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
Tel: 408-330-0488 or 408-370-9233 Cell: 408-832-3957
Email: rtaborek@xxxxxxxxxx or rtaborek@xxxxxxxxxxxxx