Re: [802.3ae] 10GBASE-X PCS; status register definition?
This is precisely what I was hoping someone would say; it's also my
opinion but I was cautiously optimistic that someone would agree with me
before I said so!
Rich Taborek wrote:
>
> All,
>
> My reading is that register bit 1.1.2 is not relevant to 10GBASE-X. The
> relevant corresponding 10GBASE-X register bit is 3.1.2, which is in turn
> set from 3.24.12.
>
> Best Regards,
> Rich
>
> --
>
> Gareth Edwards wrote:
> >
> > "THALER,PAT (A-Roseville,ex1)" wrote:
> > >
> > > Ed,
> > >
> > > Comment 126 requested that such a mapping be added to Clause 48 and my
> > > recollection is that the comment was accepted. Therefore, there should be no
> > > need for a recirculation comment.
> > >
> > > For Clause 51 and for the PMA functions in Clause 48, there are no state
> > > machines and the ability to detect synchronization is an implementation
> > > dependent function which is why there is not a mapping. Possibly one could
> > > add a statement that if the optional sync_err signal is implemented, the
> > > state of the management bit should be the dependent on the state of
> > > sync_err, though it is not clear to me that it is necessary to do so.
> >
> > sync_err is not even optional for clause 48/53; it just doesn't exist
> > (except in implementor's heads :)). Even if no reference is necessary,
> > the net effect appears to be that of a mandatory management bit that
> > doesn't have to go anywhere; the ability to detect synchronisation is
> > not mentioned at all in C48. PMA_SIGNAL.indicate is only mentioned in
> > C49. What if I get sync on lanes 0-2 but not lane 3? What should the bit
> > value be?
> >
> > >
> > > Regards,
> > > Pat
> > >
> >
> > Gareth
> >
> > > -----Original Message-----
> > > From: Ed Turner [mailto:ed.turner@xxxxxxxxxxxxxxxxxxxxxx]
> > > Sent: Wednesday, January 23, 2002 5:30 AM
> > > To: IEEE HSSG
> > > Subject: Re: [802.3ae] 10GBASE-X PCS; status register definition?
> > >
> > > Gareth,
> > >
> > > You are correct to highlight this and are not failing to spot a reference,
> > > the definition of receive link status has not been mapped explicitly to any
> > > primitives (or variables).
> > > Management is pervasive throughout the PHY and the MDIO register bits do not
> > > necessarily have to map directly to any primitives or variables.
> > > In earlier versions of the draft, there was an additional register with
> > > lane-by-lane bits for synchronization and a global bit when all lanes were
> > > synchronized. The receive link status bit was defined as a latching
> > > reflection of this global sync bit. This lane-by-lane register was
> > > (correctly) removed since the synchronization function is part of the PCS
> > > for 10GBASE-X rather than the PMA.
> > > There would be less ambiguity if we were to map this bit directly to some
> > > primitive or variable and reference out to Clauses 51 and 48. The question
> > > is how we do it. As Pat said in her e-mail yesterday, this would have to be
> > > a re-circ comment, but there's no change against which to comment. It may be
> > > stretching the definition of an editorial comment to make this change to
> > > Clauses 45 and 48.
> > > I would also be interested in hearing the views of the Clause 51 and 48
> > > people.
> > >
> > > Regards
> > > Ed
> > > (Clause 45 editor)
> > >
> > > Gareth Edwards wrote:
> > >
> > > > All,
> > > >
> > > > I'm looking for clarification on how the PMA/PMD management register
> > > > 1.1.2, "Receive Link Status" should behave when the PHY instance is a
> > > > 10GBASE-X PCS/PMA. The specification describes it thus:
> > > >
> > > > \begin{quote}
> > > > 45.2.1.2.2 Receive link status (1.1.2)
> > > > When read as a one, bit 1.1.2 indicates that the PMA is locked to the
> > > > received signal. When read as a zero, bit 1.1.2 indicates that the PMA
> > > > is not locked to the received signal. The receive link status bit shall
> > > > be implemented with latching low behavior as defined in the introductory
> > > > text of 45.2.
> > > > \end{quote}
> > > >
> > > > which I guess is aimed at the optional sync_err signal on the XSBI for
> > > > the clause 49 PCS and clause 51 PMA. Thing is, it's not explicitly
> > > > mapped to any similar signal (or should I say primitive) on the
> > > > 10GBASE-X PCS/PMA boundary, nor is it stated how it should relate to the
> > > > state of PMA lock of each and any of the 4 PMA lanes.
> > > >
> > > > Does the draft need to be refined at this point? Or am I just failing to
> > > > spot the reference?
> > > >
> > > > Cheers
> > > > Gareth
> > > >
> > > > --
> > > > / /\/\ Gareth Edwards mailto:gareth.edwards@xxxxxxxxxx
> > > > \ \ / Design Engineer
> > > > / / \ System Logic & Networking Phone: +44 131 666 2600 x234
> > > > \_\/\/ Xilinx Scotland Fax: +44 131 666 0222
>
> ---------------------------------------------------------
> Richard Taborek Sr. Intel Corporation
> XAUI Sherpa Intel Communications Group
> 3101 Jay Street, Suite 110 Optical Strategic Marketing
> Santa Clara, CA 95054 Santa Clara Design Center
> 408-496-3423 JAY1-101
> Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
> Fax: 408-486-9783 http://www.intel.com