Re: Hari
Jaime,
I think that you have the right idea. There should be a call for interest on
a PCB/Backplane PHY for 10GbE. This would fit in with the response from
Charles Berry. Hari would be an implementation specific PHY for this type of
service.
Thank you,
Roy Bynum
Jaime Kardontchik wrote:
> Paul,
>
> Thank you for your clarifying diagram. It seems that we have
> 3 (three) possible families of 10 GbE PHYs according to the
> medium used to transport the bits:
>
> 1) PHYs over optical fiber
> 2) PHYs over cat-6 UTP or shielded Copper wire
> 3) PHYs over PCBs and backplanes
>
> Each family has its own specific set of objectives and problems
> to solve (for instance: maximum supported distance). Enough to
> thrill and keep busy many good designers.
>
> My feeling is that the proponents of the second and third families of
> PHYs will still have to come with a separate PAR of their own.
>
> Jaime
>
> Jaime E. Kardontchik
> Micro Linear
> San Jose, CA 95131
> email: kardontchik.jaime@xxxxxxxxxxx
>
> Paul Bottorff wrote:
>
> > Rich:
> >
> > We agree that Hari has qualities about it that make it desirable for a
> > section of the market. We disagree that Hari is equivalent to a parallel
> > PMD interface. I believe both these interfaces have their place. They
> > are not mutually exclusive, they are complementary.
> >
> > As far as the architectural model, I'm just applying the 802.3 model
> > exactly, rather than corrupting the layering to fit Hari. To make the
> > model complete Hari can be viewed as performing peer dialog between
> > 802.3 layers as follows. This helps explain the existence of the L1
> > Translator (or Bridge or Relay, choose your words) function which is
> > currently required for Hari implementations. The jitter elimination
> > buffer is part of the L1 Translator while deskew is part of the
> > Hari-PCS. I believe this gives a much better understanding of how Hari
> > behaves with respect to historic Ethernets. The peer model is consistent
> > with all the functions currently presented for Hari. The model is as
> > follows:
> >
> > 802.3 Peer Dialog
> >
> > ----------- ------------
> > | MAC | - - - - - - - - - - - - - - - - - - - - - - - | MAC |
> > |---------| ------------------------ |----------|
> > | Recon | | L1 Trans(Bridge) | | Recon |
> > |---------| |----------------------| |----------|
> > |Hari-PCS | - - - - - | Hari-PCS | Other-PCS | - - - - - |Other-PCS |
> > |---------| |----------|-----------| |----------|
> > |Hari-PMA | - - - - - | Hari-PMA | Other-PMA | - - - - - |Other-PMA |
> > |---------| |----------|-----------| |----------|
> > |Hari-PMD | - - - - - | Hari-PMD | Other-PMD | - - - - - |Other-PMD |
> > |---------| |----------|-----------| -----------|
> > |______________________| |_________________________|
> > 4 Wide Copper - 20" Fiber
> >
> > When this model is applied to a LAN PHY transform the Hari-PCS and
> > Other-PCS are identical and therefore require no transform. When applied
> > to a WAN PHY the Hari-PCS and the Other-PCS are different are require a
> > transform. The model works nicely in both cases. Only the implementation
> > changes.
> >
> > This model also makes it clear that the 16 bit parallel interface is
> > very different architecturally from Hari. Hari is a complete PHY of its
> > own while the 16 bit interface is a N-Layer boundary between PMA and
> > PMD.
> >
> > Cheers,
> >
> > Paul
> >
> > At 12:43 AM 11/23/99 -0800, Rich Taborek wrote:
> > >>>>
> >
> > > Paul,
> > >
> > > I'll intersperse my comments below:
> > >
> > >
> > > 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. Me thinks it best to stick with 802.3 layer
> > > models for 802.3 projects. The resultant layers, including the
> > > position of Hari in the stack can be illustrated as follows. Note that
> > > Hari is not a PMD, rather it is an interface between the PHY's PMA and
> > > PMD sublayers:
> > >
> > > 802.3ae
> > > Full Duplex
> > > Layers
> > >
> > > | Higher Layers |
> > > +-----------------------------------------+
> > > | LLC - Logical Link Control |
> > > +-----------------------------------------+
> > > | MAC Control (Optional) |
> > > +-----------------------------------------+
> > > | MAC - Media Access Control |
> > > +-----------------------------------------+
> > > | Reconciliation |
> > > +-----------------------------------------+
> > > | LLC - Logical Link Control |
> > > +-----------------+---+-------------------+
> > > | | Parallel 10GMII (Optional)
> > > +-----------------+---+-------------------+
> > > | PCS - Physical Coding Sublayer |
> > > +-----------------------------------------+
> > > | PMA - Physical Medium Attachment |
> > > +-----------------+---+-------------------+
> > > (Hari) | | Serial 10GMII (Optional)
> > > +-----------------+---+-------------------+
> > > | PMD - Physical Medium Dependent |
> > > + - - - - - - - - - - - - - - - - - - - - +
> > > | PMDC - PMD Coding Sublayer (Optional) |
> > > + - - - - - - - - - - - - - - - - - - - - +
> > > | PMDA - PMD Signaling Sublayer (Optional)|
> > > +----+---------+-----------+---------+----+
> > > | LX PMD | | SX PMD |
> > > +-+-----+-+ +-+-----+-+
> > > | MDI | | MDI |
> > > +-+-----+-+ +-+-----+-+
> > > | Medium | | Medium |
> > >
> > > +---------+ +---------+ 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. I agree with your description above. For WWDM and Parallel PMDs,
> > > 8B/10B may be passed across the PMD to the medium. Alternatively,
> > > these PMDs as well as Serial and MAS PMDs may strip the 8B/10B code
> > > and recode within the PMD. 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. It
> > > seems to me that your model is starting to get unnecessarily complex.
> > > For example, the optional Hari could instead be an optional 16-bit
> > > parallel interface as is the case for SONET. However, I may be missing
> > > something in your description. Only like PHY's and like PMDs within
> > > the same PHY family can communicate. Otherwise, they must be bridged.
> > > 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. I believe that this
> > > translation between PMDs of a LAN PHY and a WAN PHY is called
> > > bridging. I agree with your direction to use Hari control code to to
> > > this. It is possible that the proposed Insert/Remove code is
> > > sufficient. 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.
> > > Hari addresses the significant distances between MAC/PCS/PMA chips and
> > > PMDs for most multi-port switches/routers which are very difficult to
> > > address with a non-serial interface. Do you have any alternative
> > > suggestions. Hari does add a bit of complexity, but I believe that
> > > this is a good cost-performance tradeoff in light of all the benefits
> > > Hari provides. 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. Hari as an optional interface best
> > > addresses common PMD interface requirements for most, if not all, LAN
> > > PHY PMDs. It may not be the best choice for the WAN PHY, but I believe
> > > it is a workable choice and can't think any better universal PMD
> > > interface. Can you?
> > >
> > > Best regards,
> > > Rich
> > >
> > >
> > > -- Cheers,
> > >
> > >
> > > Paul ----------------------------------------------------------
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > 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