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

RE: [802.3ae] RE: Clause 45: MDIO Electrical Specifications



Ed,

I’m afraid some of my remarks on the MDIO electrical specifications
weren't as explicit as they should have been. Since positive currents
are defined to flow into the circuit, IOH currents are normally
negative. The IOH specification in table 45-62 on line 46 at page 238
should have a MAXIMUM value of –4mA.

Likewise, the IOL specification on line 48 should have a minimum value
of +4mA. (At 0.2V for consistency with the VOL specification range.)

The EC7 and EC8 values in table 45.5.5.14 should be adjusted
accordingly.

The specifications on VI, VIH and VIL in table 45-62 on lines 36 - 40 at
page 238 are all in the format normally found in device specifications,
where requirements are put on the input signals to the device. In table
45-62 however the object is to have specifications on MDIO receivers,
not the input signals to them. That can be changed in several ways. The
smallest departure from the present specifications would probably be to
remove the VI spec and reword the definitions of VIH and VIL: 

 

VIH   Range of input voltages that                  0.84V        1.5V
      must be interpreted as a logic 1.

 

VIL   Range of input voltages that                  -0.3V        0.36V
      must be interpreted as a logic 0.

 

 

Best regards
Tord

 

	-----Original Message----- 
	From: Ed Turner 
	Sent: Mon 9/3/2001 11:32 AM 
	To: stds-802-3-hssg@ieee.org 
	Cc: 
	Subject: Re: [802.3ae] RE: Clause 45: MDIO Electrical
Specifications
	
	


	Tord,
	
	The PICS should be viewed as a 'tick box' list of conformance
rather than a set of
	conformance tests.  They are not intended to give much detail,
instead they reference
	out to the main text of the standard where the details are
located. However, the points
	you raise are still valid since they highlight some shortfalls
in the spec.
	
	One by one :
	EC8 IOL : Sounds OK to me, I'll use my editor's licence to raise
a comment for this
	round to add this requirement to table 45-62.
	EC8 IOH : Again, this sounds OK and I'll raise a comment to add
this to table 45-62.
	For the open drain driver case, this measurement is not
applicable.
	EC6 Bus loading : You are correct.  This is not a component
level specification but is
	a system level specification for the capacitance of all the
devices and PCB routing
	combined together.
	EC5 Input capacitance : I agree that 10pF may be challenging,
but the vallue was agreed
	by the committee and at the time no objections were raised.
Keeping this value as low
	as possible is important since it allows as many devices as
possible to share the bus.
	However, if you feel that this number is too low then please
submit a comment at
	sponsor ballot with an alternative value and some supporting
data to justify the
	change.
	
	Regards,
	Ed
	
	Tord Haulin wrote:
	
	>  Edward Turner:
	>
	> I have a few questions concerning the MDIO Electrical
Specifications.
	>
	> The table 45.5.5.14 in the PICS proforma section isn't all
that explicit
	> on measurement conditions. As long as the measurements are
taken by
	> humans we can quite easily understand the underlying meaning
of the
	> specifications and overlook inconsistent current direction
	> specifications and trouble with inequalities and mins and
maxes for
	> negative numbers etc., but there are a few aspects beyond that
which are
	> trickier.
	>
	>
	>
	> Spec points:
	>
	> EC8 IOL
	> The best guess for a voltage to use for this measurement would
be the
	> highest allowed VOL voltage 0.3V (EC2)
	>
	> EC7 IOH
	> For push pull drivers, the corresponding choice for an IOH
measurement
	> voltage would be the lowest allowed VOH voltage 1.0V (EC1)
	>
	> For the option with open drain drivers and a resistive pull-up
however
	> the same test condition would dictate a resistance that would
overload a
	> driver trying to pull it low.
	>
	> EC6 Bus Loading
	> interoperability but for ensuring a performance level of a
collection of
	> units with MDIO interfaces joined with some network. Therefore
I assume
	> it is not mandatory or even applicable to components.
	>
	> EC5 Input capacitance for MDIO
	> The 10pF limit can be difficult to support both for MDC and
for the MDIO
	> wire of MDIO in particular, given the wide variety the wide
variety of
	> mechanical design and subassemblies possible, sometimes with
several
	> devices connected to MDIO.
	>
	>  I would appreciate some comments and guidance on how to
interpret the
	> specifications.
	>
	>
	>
	> Best regards Tord Haulin
	>
	>         -----Original Message-----
	>         From: Edward Turner
	>         Sent: Thu 3/1/2001 4:23 PM
	>         To: stds-802-3-hssg@ieee.org
	>         Cc:
	>         Subject: Re: Clause 45: MDIO Electrical Specifications
	>
	>
	>
	>         Jeff,
	>
	>         As you correctly point out, the conclusion of the MDIO
	> Electrical ad-hoc was to
	>         recommend to IEEE P802.3ae that JEDEC JESD8-11 be
adopted as the
	> MDIO electrical
	>         interface. This is what I reported at the opening IEEE
P802.3ae
	> Task Force
	>         meeting in January and, as you point out, is recorded
in the
	> meeting minutes in
	>         the General Presentations section
	>         (
http://www.ieee802.org/3/ae/public/jan01/minutes_0101.pdf -
	> pages 15/16).
	>
	>         Please note however that this was a report of the
recommendation
	> of the Ad-Hoc
	>         given at the start of the meeting. When the Clause 45
track met
	> later in the
	>         week to resolve comments, the track discussed the
ad-hoc's
	> recommendation in
	>         relation to D2.0 comment #1115 and the conclusion of
this
	> discussion was a
	>         decision to use electricals based on JEDEC JESD8-11.
These
	> electricals are a
	>         1.2v instance of JEDEC JESD8-11 with some additional
parameters.
	> This is
	>         documented in the comment resolution database against
comment
	> #1115
	>         (
http://www.ieee802.org/3/ae/comments/d2.0/D2-0-Comments.pdf -
	> Page 76) and was
	>         also reported by Ben Brown in his Logic Track report
at the
	> close of the IEEE
	>         P802.3ae Task Force meeting
	>         (
http://www.ieee802.org/3/ae/public/jan01/brown_1_0101.pdf -
	> Page 5).
	>
	>         In conclusion, while the ad-hoc made a recommendation,
during
	> comment resolution
	>         this recommendation was modified and I am bound by the
results
	> on the comment
	>         resolution process, which were approved by the Task
Force, when
	> preparing the
	>         draft. You are therefore correct in saying that the
changes that
	> I made to the
	>         draft do not match the report I gave of the Ad-hoc's
	> recommendation at the start
	>         of the meeting. This however is all part of the
comment
	> resolution process. Note
	>         however, this is not to say that the work of the
Ad-Hoc was
	> ignored, it is the
	>         basis of what appears in the draft today.
	>
	>         In relation to your new comment, I feel I have to put
a
	> 'proposed reject'
	>         against it, citing comment #1115 from D2.0 - please
don't take
	> the reject
	>         personally! I feel I have to do this as I believe that
the
	> current draft is
	>         aligned to the consensus of the group. However, as
with all
	> comments, the actual
	>         response will be discussed and decided at the upcoming
meeting,
	> in this case
	>         during the Clause 45 track.
	>
	>         I do believe that the selection of a electrical
specification
	> for Clause 45 is a
	>         most difficult task in particular in relation to
selecting an
	> approach that is
	>         acceptable today, but will not become a burden to
future
	> implementations. I want
	>         to thank you, and everybody else that has taken part
in this,
	> for the
	>         contributions so far. As you will no doubt have noted
there was
	> another
	>         suggestion for the Clause 45 electrical interface
yesterday and
	> I hope that now
	>         there is wider interest we can all work together to
come to a
	> acceptable
	>         consensus.
	>
	>         Respectfully,
	>         Ed
	>
	>         "Jeff Porter (rgbn10)" <j.porter@motorola.com> on
01/03/2001
	> 03:55:27
	>
	>         Sent by:  "Jeff Porter (rgbn10)"
<j.porter@motorola.com>
	>
	>         To:   Edward Turner/GB/3Com@3Com
	>         cc:   stds-802-3-hssg@ieee.org
	>         Subject:  Re: Clause 45: MDIO Electrical
Specifications
	>
	>         Ed,
	>
	>         I submitted a comment to D2.1 on this issue, included
again at
	> the bottom
	>         of this note.  The comment is that D2.1 does not
reflect the ad
	> hoc
	>         decision that was reported in Irvine, namely to adopt
JEDEC
	> JESD8-11
	>         for MDC/MDIO. The suggested remedy is that we simply
reference
	>         JESD8-11 (www.jedec.org, "Free Standards") as the MDIO
	> interface.
	>
	>         For D2.2 (Friday?) and D3.0 (March meeting) I suggest
leaving
	> text as is,
	>         "complete" in some sense, or accepting my comment and
resetting
	> to the
	>         ad hoc recommendation and referencing JESD8-11
directly.
	> Additional
	>         tweaks can wait for D3.0 comments.
	>
	>         FYI, my recollection of why JESD8-11 is proposed:
	>
	>         -- In earlier meetings, the consensus was that the
Clause 22
	> electrical
	>            interface was no longer practical (voltages too
high).
	>
	>         -- In earlier meetings, the consensus was that 10G did
not want
	> to
	>            spend energy defining new "logic families", that
is,
	> non-standard
	>            interfaces, for XGMII and MDIO, since there seem to
be plenty
	> of
	>            digital interface standards to reference. (We seem
to be
	> spending
	>            energy now). An ad hoc was formed to report a
recommendation
	> at Irvine.
	>
	>         -- Many comments were made that the new interface
should last
	> for
	>            many years, not just a solution for 10G only.
(since MDIO
	>            may need to connect to phy's of different
generations.
	> Changing
	>            addressing and electrical now, but not again for a
long while
	> since three generations of MDIO in one box is unthinkable.)
	>
	>         -- HSTL was repeatedly adopted/affirmed for XGMII
interface.  As
	> a practical
	>            matter, systems with XGMII interface will have a
1.5V supply
	> available.
	>            No other P802.3ae interfaces infer a supply
voltage.
	>            (OK, as a practical, practical matter, it seems
that at least
	> for 0.18um
	>            parts, the "HSTL" XGMII interface can be designed
to be
	> powered at
	>            either 1.5 or 1.8V, even though standard only says
1.5V.  In
	> non-standard
	>            systems using 1.8V "HSTL", perhaps only 1.8V supply
would be
	> available,
	>            but then I would expect those systems to design
MDIO to
	> operate at
	>            either 1.5 or 1.8V, also outside standard.)
	>
	>         -- JESD8-11 provides two approaches for future
proofing:
	>
	>            ** If P802.3ae says nothing about "Normal Range"
(Vdd 1.5+/-
	> 0.1V)
	>               versus "Wide Range" (Vdd 0.9-1.6V), then every
Clause 45
	> MDIO
	>               must support operation at interface Vdd=1.5V,
insuring
	> compatibility.
	>               Part vendors could choose to support wide range,
and
	> system
	>               implementers could select wide range parts, and
operate
	> the interface
	>               on any supply between 0.9 and 1.6V.
	>
	>            ** If P802.3ae requires, in addition to JESD8-11,
	> specifically
	>              "Wide Range" support, then compatibility is also
assured,
	> since every
	>               Clause 45 MDIO interface would operate with an
interface
	> supply between
	>               0.9 and 1.6V. (i.e. 1.5V+/-0.1V, down to
1.0V+/-0.1V).
	>
	>         -- XGMII spec came from JEDEC (JESD8-6), JESD8-11 was
available
	> and seemed to
	>         meet
	>            the consensus goals, it was proposed in ad hoc, and
despite
	> prodding from Ed,
	>         no
	>            alternatives were proposed, recommendation (by
default) was
	> reported
	>            at Irvine.
	>
	>         From (unapproved) Irvine minutes, I only find:
	>         "Mr. Turner gave a quick ad-hoc MDIO report. A number
of
	> individuals from both
	>         the
	>         802.3ae and 802.3af committees worked on the new
electrical
	> interface
	>         specification and
	>         they selected an interface with an expected long life.
This
	> interface will be
	>         compatible
	>         with lower voltage devices that emerge in the future.
They
	> recommended the JEDEC
	>         standard JESD8-11 interface. www.jedec.org The ad-hoc
work is
	> finished, Ed
	>         proposed
	>         these ad-hoc conclusions be added to the next version
of the
	> draft standard."
	>
	>         Do I think JESD8-11 is perfect "as is"?  No - while
Normal Range
	> requires >2mA drive, Wide Range only requires an anemic 100uA
(as does
	> table in
	>         D2.1).
	>         Though 2.5MHz is slow, perhaps we should still say
something
	> about expected
	>         loading,
	>         desired range of edge rates, etc.  But I'm confident
part
	> vendors would make
	>         good
	>         guesses here.  For the standard, I'm just suggesting
that we
	> start back at
	>         JESD8-11, and make any *needed* refinements as D3.0
comments.
	>
	>         Thanks,
	>         Jeff
	>
	>         Edward Turner wrote:
	>         >
	>         > Rick,
	>         >
	>         > I support your effort to bring forward these
potential issues
	> to the group at
	>         > large.  I also encourage further reflector
discussion if
	> people feel there is
	>         > something broken in the draft.  It is important that
we make
	> the correct
	>         > decisions when these items come up for vote at the
meeting.
	>         > I was not sure if you were at the meeting and wanted
to
	> explain some of the
	>         > background thinking that had gone on 'off the
reflector'
	> during the ad-hoc and
	>         > at the Irvine meeting.
	>         > I also encourage any of you who are attending the
meeting and
	> have points to
	>         > raise on the MDIO electrical interface to come along
to the
	> Clause 45 sub
	>         track
	>         > so that we can hear your concerns when we discuss
the
	> electrical interface
	>         > comments.
	>         >
	>         > Regards
	>         > Ed
	>         >
	>
	>         Clause: 45
	>         Subclause: 45.45.4.1
	>         Page: 45.222
	>         Line: 15
	>         CommentType: DISAPPROVE (Technical)
	>         Comment:
	>         Resolution of Draft 2.0 Comment 1115 ""adopt[ed] an
instance of
	> the
	>         JESD8-11 standard with a VDD of 1.2V""  JESD8-11
(www.jedec.org,
	> ""Free
	>         Standards"") was selected by an apathetic ad-hoc.
	>         However, JESD8-11 does not support 1.2v only
operation.  The
	> choices,
	>         Normal and Wide range, are mentioned in the title of
JESD8-11
	>         2.2.1 Normal Range (1.4 to 1.6V Vdd)
	>         2.2.2 Wide Range (0.9 to 1.6V Vdd)
	>         In either case, the sending and receiving Vdd for this
interface
	> must
	>         track within 0.1V (Note 1 in 2.3.1 and 2.3.2)
	>         An MDC/MDIO implmenter could select to support either
Normal or
	> Wide
	>         range since interoprability at 1.5V is maintained.  If
all
	> connected
	>         parts in a system are wide range, a supply lower than
1.5V
	> nominal
	>         could be used.
	>         When an XGMII (HSTL JESD8-6) is present, 1.5V will be
available.
	> CommentEnd:
	>         SuggestedRemedy:
	>         Change 45.4.1 to read
	>         ""The electrical characteristics of the MDIO interface
are
	> defined
	>         in JESD8-11.  Pin input capacitance is limited to 10pF
	> maximum.""
	>         Retain NOTE, change to read ...""Vdd of 1.5V""
	>         Delete Table 45-41.
	>         Annex 45A, change 1.2V Vdd to 1.5V Vdd throughout.
	>         RemedyEnd:
	>
	>
------------------------------------------------------------------------
	>                   Name: winmail.dat
	>    winmail.dat    Type: DAT File
(application/x-unknown-content-type-dat_auto_file)
	>               Encoding: base64
	
	

winmail.dat