Re: [802.3ae] 10GBASE-X PCS; status register definition?
"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