Re: Hari
It would seem that if you wanted to "standardize" an L1 translator that the
source should be as close to serial as possible, making the interface the
most generic. Just to throw in some additional information, I've talked to
two reputable semiconductor manufacturers that have proposed 10 Gbps
differential interfaces (for other applications).
JR
At 12:08 PM 11/22/99 -0800, Paul Bottorff wrote:
>
>Rich:
>
>I agree that Hari was clearly presented. I also question whether the
>architectural model in use for Hari is rational.
>
>Another way to look at Hari is as a PMD for the LAN PHY. It is basically a
>20 inch medium dependent interface. With this outlook the Hari PMD is then
>mapped to other PMDs using something I we might call an L1 translator. The
>resulting systems using this model are just like the ones presented for
>Hari, but give a much better understanding of how the architecture is
>mapping to the layers.
>
>Using this model we see that Hari as presented relies on an 8b/10b PCS
>associated with the MAC. This means Hari connects to an 8b/10b PCS (perhaps
>the LAN PHY) on the MAC side. The L1 translator on the other side converts
>the Hari PMD + LAN PHY to an alternate PMD + PHY. The transform required at
>the translator depends on which PMD/PHY we are mapping Hari into.
>
>When the translation between PMDs is within the same PHY family (LAN PHY to
>LAN PHY) then no code translation is required, even though the translator
>still needs deskew, reclocking, and rate matching buffer.
>
>When the translation between PMDs is between a LAN PHY and a WAN PHY, then
>there needs to be a method to slow down the data rate delivered over Hari
>so the L1 translator will not require an entire switch buffer (like 16
>Mbytes) for the rate match. Both WORD HOLD and IPG stretch techniques could
>be used here. The WORD HOLD could be implemented using the same scheme we
>suggested for the XGMII by adding a HOLD signal to Hari and by finding a
>control code to represent the NULL.
>
>Overall the Hari interface adds the L1 translator logic to a design. Though
>this may be useful for some designs it is a lot of baggage to carry when it
>is not necessary. For many switches the MAC/PHY/PMD are co-located on the
>board and an Ethernet backplane extension just adds complexity.
>
>The biggest issue with Hari is that it does not provide a universal
>interface for PMDs. A PMD for the WAN PHY using Hari will be different from
>a PMD for the LAN PHY using Hari.
>
>Cheers,
>
>Paul
>
>At 12:46 AM 11/19/99 -0800, Rich Taborek wrote:
>>
>>Roy,
>>
>>I thought that Hari was clearly presented in at least half a dozen
>presentations by at
>>least the same number of presenters who all explained it in the same way
>in Kauai. I'll
>>try one more time here.
>>
>>Hari is the same as the Serial interface of the 10 GMII as presented to
>the HSSG by
>>Howard Frazier of Cisco in Montreal, York and Kauai. A group of Ethernet,
>Fibre Channel,
>>InfiniBand and even OIF folks have gotten together over the past several
>months to try
>>and arrive at a common interface for passing 10 Gbps of data continuously
>in each
>>direction between a PCS/PMA element (which may be integrated with the MAC
>and the PMD
>>(i.e. transceiver module).
>>
>>Note that a typical Ethernet PHY, like 1000BASE-X contains the PCS, PMA
>and PMD
>>sublayers. Hari is NOT a PHY nor is it a PHY sublayer. Hari is an
>interface between
>>sublayers and is very similar in nature to the Ten-Bit Interface (TBI) of
>1000BASE-X,
>>which is fully described in Clause 36 of that standard.
>>
>>Hari has nothing at all to do with WWDM although it clearly may be used to
>attach a WWDM
>>PMD to its MAC/PCS/PMA.
>>
>>Hari may be used to attach a Parallel Optical PMD to its MAC/PCS/PMA in
>much the same
>>fashion as for WWDM
>>
>>Hari usage to attach a MAS PMD to its MAC/PCS/PMA has been described in
>all my MAS
>>proposals to the HSSG including the latest update presented in Kauai:
>>http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_2_1199.
>pdf
>>
>>Hari usage to attach a Serial PMD to its MAC/PCS/PMA along with a proposed
>coding to
>>maintain a line rate of ~10 Gbaud has been described in the Kauai proposal
>by Rick
>>Walker and Richard Dugan of Agilent:
>>http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/walker_1_1199.pdf
>>
>>Therefore, Hari provides a common interface for all major classes of PMDs
>proposed to
>>the HSSG to date in addition to being strongly considered as a common
>interface for
>>other ~10 Gbps standard and industry interfaces.
>>
>>The principal strengths of Hari are:
>>1) Low pin count
>>2) Self-timed (doesn't need a clock with data)
>>3) Supports reasonable distances over inexpensive medium (e.g. 20" of FR4
>traces)
>>4) Good synergy with traditional Ethernet MAC/PHY framing
>>5) Sufficient robustness to not compromise a 10E-12 link BER
>>
>>8B/10B encoding has been proposed for Hari since it has been proven time
>and time again
>>in multiple forums that 8B/10B is a very robust serial link transmission
>code. However,
>>Hari is not a PCS and an alternate code could have been proposed for Hari.
>I consider
>>the Hari usage of 8B/10B to be analogous to a parity bit for a traditional
>parallel
>>interface. The "parity bit" can be generated at the source and discarded
>after checking
>>at the destination. The MAS and Serial PMD proposals referenced above use
>Hari in
>>exactly this fashion and result in the lower line rate possible for those
>respective
>>interfaces when compared to a PMD coding which would carry forward the
>8B/10B overhead.
>>
>>Hari is being proposed for inclusion into the 802.3ae standard as an
>interface as
>>described above. However, Hari does not dictate the encoding of data
>transported over
>>the Medium. Hari simply enables the transport of that data over the medium
>in a manner
>>commensurate with the 5 criteria of 802.3ae.
>>
>>As such, I would also recommend that Hari be considered for the WAN PHY.
>>
>>Best regards,
>>Rich
>>
>>--
>>
>>Roy Bynum wrote:
>>
>>> Rich,
>>>
>>> I am confused here. Is Hari being proposed as a PHY for the LAN
>compatible PHY of
>>> 10GbE? I have recognized that Hari only needs the WWDM optical
>interface to be a 4
>>> wavelength parallel short reach PHY. When it was first presented, the
>way that it
>>> was presented reminded me of a "solution looking for a problem". It
>certainly looks
>>> like there are a lot of people have been working on this for some time.
>All of the
>>> conversations on the reflector are starting to treat Hari as a PHY, not
>a device
>>> interconnect. I am confused why an interconnect suitable to be a full
>LAN PHY would
>>> be proposed first as a device interconnect. As a 500m and less LAN
>PHY, I am
>>> neutral on Hari. As something else, I confused by the way it was
>presented and have
>>> my doubts as to the overall impact of Hari as a device interconnect and the
>>> limitations that it inherently makes on the PCS/PMD relationship.
>>>
>>> Hari as a device interconnect requires specific functionality. It
>forces the
>>> physical coding functionality of non parallel PHYs to exist at the PMD,
>not the
>>> PCS. I have been told by a Hari supporter that the PCS/PMA/PMD
>relationship is
>>> purely for the standard and has little relationship to how protocols are
>implemented
>>> and devices are actually designed. If device and protocol
>implementation has little
>>> to do with the standard, why have the standard? If the protocol
>implementation is
>>> specific to the standard, then Hari is a PCS specific to a particular
>PHY and is
>>> exclusive of other PCS definitions for other PHY definitions.
>>>
>>> If Hari is a PCS, let us recognize it as such and move on with other PHY
>>> definitions. If it is not a PCS then let us recognize that it will
>alter the nature
>>> of the relationships of the PHY functionalities for the non-WWDM PHYs
>dramatically.
>>> A silicon designer can best determine if the increase in complexity of
>the PMD is
>>> countered by the pin count benefits of Hari as something other than a
>PCS. Hari as
>>> a device interconnect needs to be removed from the table. Hari as a
>PCS, with minor
>>> modifications can be evaluated as such.
>>>
>>> Thank you,
>>> Roy Bynum
>>>
>>> Rich Taborek wrote:
>>>
>>> > The purpose of this note is to clear up confusion regarding Hari, a
>>> > proposed 4-lane serial interface for 10 GbE and train-up sequences.
>>> >
>>> > It should be clear that NO TRAINING SEQUENCES are proposed for Hari.
>>> > Both the "Hari Coding Objectives" presentation
>>> >
>(http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/taborek_1_1199.
>pdf)
>>> > and "Word Striping on Multiple Serial Lanes"
>>> >
>http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/ritter_1_1199.pdf)
>>> > make a point of noting that no train-up is required Hari to deskew.
>>> >
>>> > The Hari Coding Objectives proposal uses the standard Idle sequence
>>> > proposed by Howard Frazier of Cisco to deskew multiple parallel lanes
>>> > while simultaneously acquiring code-group synchronization on all lanes.
>>
>> ----------------------------------------------------------
>>
>>Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
>>Tel: 408-370-9233 Cell: 408-832-3957 Fax: 408-374-3645
>>Email: rtaborek@xxxxxxxxxxxxx
>>
>>
>>
>Paul A. Bottorff, Director Switching Architecture
>Enterprise Solutions Technology Center
>Nortel Networks, Inc.
>4401 Great America Parkway
>Santa Clara, CA 95052-8185
>Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
>email: pbottorf@xxxxxxxxxxxxxxxxxx
>