RE: [802.3ae] 10GBASE-X PCS; status register definition?
Gareth,
I do not agree with Rich on this one. According to 48.3.1.2, the PMA
deserializes the data so the PMA would have PLLs to capture the clock.
It may have the ability to tell whether these PLLs are in lock though
it is not required to have that ability. This is the same as the
situation for 10GBASE-R.
If a 10GBASE-X PMA has that ability, it would be valid for it to
set receive link status to 0 when it is not in lock. There are a
number of status bits that allow for a device to report a problem
where the detection is implementation dependent such as transmit
fault on PMDs. This is another of those bits.
Regards,
Pat
-----Original Message-----
From: Gareth Edwards [mailto:Gareth.Edwards@xxxxxxxxxx]
Sent: Friday, January 25, 2002 1:39 AM
To: rtaborek@xxxxxxxxxxxxx
Cc: IEEE HSSG
Subject: 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