Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Hari and train-up sequences

Hello all,

I would like to add a comment: the 1000BASE-T PCS, which is
used in the  "PAM-5 + 4-WDM at 1.25 Gbaud/s" approach (*),
takes care automatically of the link initialization problem and deals
explicitly and solves all the potential problems that you describe
in your email below.

The information about the status of the local and remote receivers
is contained in the transmitted IDLEs . Each  receiver has plenty of
IDLEs for deskewing and both partners in the link know when the
other one has synchronized its receiver, locked its PLL and is ready
to receive frames.  The PCS takes care that no partner will begin
sending frames until both sides of the link have synchronized
completely their receivers and  communicated this information to
the other partner.

And, if during normal frame transmission one of the partners looses
lock, it will automatically communicate this immediately to its partner
on the other side (through info embedded in the IDLEs it transmits).
The partner on the other side will stop sending frames and will begin
sending IDLEs as well until complete synchronization is attained again.

There is no need to declare that the link has failed and go back to

(*) see presentation "300 meters on installed MMF", Kauai meeting


Jaime E. Kardontchik
Micro Linear
San Jose, CA 95131
email: kardontchik.jaime@xxxxxxxxxxx

Linda Cheng wrote:

> Hi all,
> A general comment about link initialization...  Although sending Idles
> is sufficient for deskew given the remote side is receiving them, it
> is not enough to ensure proper link initialization. For example, the
> receiving side may not be "plugged in", or it may have just booted. If
> the receiving side doesn't receive enough idles or any idles, it may
> not be able to deskew properly.
> There should be a link initialization defined so that before a station
> transitions from transmitting its idle sequence to transmitting
> frames, it knows that the station at the far end has synced up (found
> commas, PLLs are locked, finished deskew). This sequence will be
> useful not only during system bootup, but also when loss of sync
> occurs following normal operation.
> I realize that adding Autonegotiation as an PAR objective failed in
> York. I take this as a backlash to complexity involved in using fast
> link pulses to distiguish between 1Gig and 10Gig. Its good to keep
> things sweet and simple, however, we should not throw out useful and
> needed functions served by Autonegotiation. For one, we are going to
> need some form of link init. This is as simple as a two part handshake.
> Going one step further, I think its a minor increment to send PAUSE
> information during link init so that system admins don't have to
> think about how to set up their networks. This is especially useful
> when stations speak asynchronous Pause.
> Linda
> > Delivered-To:
> > X-Received: 15 Nov 1999 04:13:32 GMT
> > Date: Sun, 14 Nov 1999 18:54:28 -0800
> > From: Rich Taborek <rtaborek@xxxxxxxxxxxxx>
> > X-Accept-Language: en
> > MIME-Version: 1.0
> > To: HSSG <stds-802-3-hssg@xxxxxxxx>
> > Subject: Hari and train-up sequences
> > Content-Transfer-Encoding: 7bit
> > X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> > X-Listname: stds-802-3-hssg
> > X-Info: [Un]Subscribe requests to  majordomo@xxxxxxxxxxxxxxxxxx
> > X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
> > X-SMTP-MAIL-FROM: owner-stds-802-3-hssg@xxxxxxxx
> > X-SMAP-Received-From: outside
> >
> >
> > 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
> >
> (
> > and "Word Striping on Multiple Serial Lanes"
> >
> > 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.
> >
> > --
> > Best regards,
> > Rich
> >
> >   ----------------------------------------------------------
> >
> > 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
> >
> >
> >
> ---------------------------------------------------------------
> Linda Cheng                     Cisco Systems
>                                 Desktop Switching Business Unit
> (408) 527-2015 (phone)          170 West Tasman Drive
> (408) 527-4698 (fax)            San Jose, CA 95134-1706
> ---------------------------------------------------------------