Re: MDIO clock rate
Roger,
The points you make are all important. I had heard different opinions from various
people on whether the interface should retain the same timing as in Clause 22 or
run faster. For such a technical issue I obviously couldn't make the decision about
what to include in the draft without TF discussion and authorization.
To resolve this, one of the many MDIO motions I subjected the committee to in Tampa
was : 'Move that the IEEE802.3ae Task Force adopt the timing specified in Clause 22
for the MDIO interface.' This was passed (Y:51, N:1, A:44).
I believe this motion has closed the timing issue. The Clause 22 MDIO timing will
be used in Clause 45 (the Clause previously known as 33).
My thanks to the committee for bearing with me whilst we sorted out the MDIO issues
for D2.0.
Regards
Ed
>
>
> "Roger Ronald" <rronald@pmr.com> on 14/11/2000 19:16:15
>
> Sent by: "Roger Ronald" <rronald@pmr.com>
>
> To: "HSSG" <stds-802-3-hssg@ieee.org>
> cc: (Edward Turner/GB/3Com)
> Subject: MDIO clock rate
>
> Why should the clock run faster?
>
> Has anyone, anywhere, EVER complained that their ability to use
> MDIO/MDC was adversely impacted by the clocking rate specified?
> I doubt it. I have never seen a complaint about slow MDIO interface
> operation.
>
> Backward compatibility is FAR more important than going faster
> just because it is possible.
>
> RR
>
> ----- Original Message -----
> From: "David Law" <David_Law@eur.3com.com>
> To: "Devendra Tripathi" <tripathi@vitesse.com>
> Cc: "Edward Turner" <Edward_Turner@eur.3com.com>; <stds-802-3-hssg@ieee.org>
> Sent: Friday, November 03, 2000 12:36 PM
> Subject: Re: XGMII electricals -> MDIO electricals
>
> >
> >
> >
> > Hi Tripathi,
> >
> > When you say keep the current electrical specification I assume you are
> > referring to the Clause 22 specification and I guess that the reason for this
> is
> > to allow the 10Gb/s devices, with the new Clause 33 MDC/MDIO bus, to co-exist
> on
> > the same MDC/MDIO bus as the existing 10/100/1000Mb/s parts that have the
> Clause
> > 22 MDC/MDIO bus. You however then go on to say multiply the clock frequency by
> > 10. Now I may be missing something but unfortunately I believe that increasing
> > the maximum clock frequency by 10 will mean that the new Clause 33 MDC/MDIO
> > devices will no longer be able to exist on the same MDC/MDIO bus a exiting
> > (Clause 22) parts. The reason for this is the existing parts may not be
> designed
> > to operate at any MDC speed any higher than that specified in Clause 22.
> > Exposing these devices to this higher speed clock may make them operate
> > incorrectly which in turn may corrupt the operation of the entire MDC/MDIO
> bus.
> > I therefore believe that if you wish to maintain backward compatibility with
> the
> > voltage, you have to also maintain backward compatibility with the timing
> > specification.
> >
> > Now I suppose one option would be to specify a higher speed clock for the
> Clause
> > 33 MDC/MDIO but require that at startup a MDC/MDIO master (STA) poll all the
> > devices on the bus to see if they are all Clause 33 devices. If they all are
> > then the bus can operate at the higher speed, if they are not then the bus
> would
> > have to operate at the Clause 22 speed. Is that what you were proposing ?
> >
> > Regards,
> > David Law
> >
> >
> >
> >
> >
> >
> >
> >
> > Devendra Tripathi <tripathi@vitesse.com> on 03/11/2000 17:53:47
> >
> > Sent by: Devendra Tripathi <tripathi@vitesse.com>
> >
> >
> > To: Edward Turner/GB/3Com@3Com, "'stds-802-3-hssg @ieee.org'"
> > <stds-802-3-hssg@ieee.org>
> > cc: (David Law/GB/3Com)
> > Subject: Re: XGMII electricals -> MDIO electricals
> >
> >
> >
> >
> >
> > I would retain the current MDC/MDIO electrical specification. Timing wise,
> > the clock
> > frequency could be multiplied by a factor of 10.
> >
> > Tripathi.
> >
> > At 01:48 PM 11/3/00 +0000, Edward Turner wrote:
> >
> >
> >
> > >Jeff,
> > >
> > >I'd like to pick up your last point : "...what about MDC/MDIO levels?".
> > >For D1.1 I inserted an editors note under an "Electrical interface"
> > >section as a
> > >place holder for an interface to be approved by the Task Force. At the Tampa
> > >meeting I intend to propose that we just adopt the logic family that the
> XGMII
> > >uses (we might have to put a note in about termination schemes as the MDIO is
> > >multi-drop).
> > >If anyone has any specific concerns with this I encourage them to voice
> > >them and
> > >bring bring forward an alternative proposal to the meeting.
> > >
> > >Regards
> > >Ed
> > >
> > >
> > >
> > >
> > >
> > >"Jeff Porter (rgbn10)" <j.porter@motorola.com> on 02/11/2000 22:18:44
> > >
> > >Sent by: "Jeff Porter (rgbn10)" <j.porter@motorola.com>
> > >
> > >
> > >To:
> > >cc: "'stds-802-3-hssg @ieee.org'" <stds-802-3-hssg@ieee.org> (Edward
> > > Turner/GB/3Com)
> > >Subject: Re: XGMII electricals
> > >
> > >
> > >
> > >
> > >
> > >
> > >In an effort to get us all on the same page, here are links to
> > >the standard XGMII interface proposals, SSTL-2 and HSTL Class 1
> > >on the JEDEC site under "Free Standards":
> > >
> > >HSTL Class 1
> > > http://www.jedec.org/download/search/jesd8-6.pdf
> > >
> > >SSTL_2 Class 1 (per page 9,
> > >http://grouper.ieee.org/groups/802/3/ae/public/jul00/frazier_1_0700.pdf)
> > > http://www.jedec.org/download/search/jesd8-9.pdf
> > >
> > >First, I also discourage the development of a new 1.8V interface definition
> > >for XGMII for many of the reasons already on the reflector.
> > >
> > >I regret not making a larger issue in New Orleans about the fact
> > >that HSTL is a 1.5V specification. I thought there was consensus on
> > >the idea of saving power by going to HSTL, and was (too) willing to
> > >go along with voting on HSTL and 1.8V at the same time based on
> > >claims that there was another standard out there, and assuming that
> > >lacking a standard, we would still go to real (1.5V) HSTL.
> > >
> > >The very valid point has been made that interface variations outside
> > >of the IEEE standard often become popular, and that may also
> > >become true with XGMII. So the question is where the standard
> > >should point, what guidance should we give implementers? Since HSTL is
> > >available, standardized, and lower power, this makes a better *standard*
> > >interface than SSTL_2 (similar attributes, but higher power).
> > >That is, guide implementers toward a lower power solution.
> > >
> > >It has been stated that 2.5V SSTL_2 interfaces are implemented on
> > >early XGMII interfaces. There was discussion at New Orleans that at
> > >least some of these interfaces also work down to 1.8V. Even if we select HSTL
> > >(i.e. 1.5V), as a practical matter, many 0.18um HSTL interfaces may also work
> > >up to 1.8V, which may be more convenient in systems at first than a 1.5V
> > >supply.
> > >If XGMII lives long enough for some reason, the market might go to even lower
> > >"1.5V tolerant" interface (e.g. 0.9-1.6V range specified in jesd8-11.pdf,
> > >October 2000, but with 50 ohm drive level).
> > >
> > >Perhaps a bigger question is, what about MDC/MDIO levels?
> > >Jeff
> > >
> > >
> > >
> > >
> > >"Grow, Bob" wrote:
> > > >
> > > > Implementing the XGMII concensus of the Task Force expressed through straw
> > > > polls in New Orleans is a problem. In fact, I would characterize the
> > > actions
> > > > we took in New Orleans to be an example of group think gone wild. We had
> a
> > > > comprehensive SSTL specification in the draft, but made the straw poll
> > > votes
> > > > to change on concepts, not proposed specifications.
> > > >
> > > > There is no standard for HSTL at 1.8 volts (the preferred voltage per
> straw
> > > > poll), nor did the TF select any other parameters of the electrical
> > > > specifications. (Class I, 1.5 volt HSTL as specified in EIA/JESD8-6
> > > is the
> > > > closest standardized alternative that the team working on clause 46 could
> > > > find). Because we couldn't find a standard to reference and the Task
> Force
> > > > didn't endorse a complete set of 1.8 volt specifications, there was no way
> > > > an HSTL electrical specification could be inserted into the draft without
> > > > adding a lot of technical material that hadn't been endorsed by the
> > > > committee. Therefore, all you will find in Draft 1.1 on HSTL is an
> > > editor's
> > > > note describing the situation.
> > > >
> > > > Most discussion supports the idea that the XGMII electrical interface
> > > is for
> > > > near term usage (with continued use as an module to module logic interface
> > > > within a chip). Implemeters expect the electrical interface to be
> supported
> > > > by I/O devices in quick turn silicon libraries. Some participants in the
> > > > editorial session thought ASIC vendors might have a 1.8 volt HSTL derived
> > > > from the above referenced specification, but weren't sure of any vendors
> > > > supporting it (for inclusion in the standard it should be supported by
> many
> > > > vendors).
> > > >
> > > > We have a similar problem with the clock alignment were the straw poll
> > > > endorsed a change without any specifications to implement the change
> (e.g.,
> > > > skew specifications).
> > > >
> > > > As it now stands, I would vote against going to Task Force ballot. It
> > > would
> > > > be a shame for TF ballot to be delayed because of the absence of XGMII
> > > > electricals. I see three alternatives that would allow us to go forward
> to
> > > > TF ballot.
> > > >
> > > > 1. Return to the SSTL specifications of Draft 1.0
> > > > 2. Reference HSTL at 1.5 volts per EIA/JESD8-6 and select from the
> options
> > > > within that specification.
> > > > 3. Someone presents a detailed proposal including all appropriate
> > > > specifications (timing, thresholds, AC and DC characteristics,
> termination,
> > > > etc.)
> > > >
> > > > As the clause editor, I will be proposing alternative 1 in Tampa unless
> > > > participants come through with presentations (sufficiently detailed to
> > > go to
> > > > TF ballot), and the Task Force endorses the specifications presented.
> > > >
> > > > Bob Grow
> > > > Editor Clause 46
> > >
> > >
> > >
> > >
> >
> > Best Regards,
> >
> > Devendra Tripathi
> > Vitesse Semoconductor Corporation
> > 3100 De La Cruz Boulevard
> > Santa Clara, CA 95054
> > Phone: (408) 986-4380 Ext 103
> > Fax: (408) 986-6050
> >
> >
Roger,
"Roger Ronald" <rronald@pmr.com> on 14/11/2000 19:16:15
Sent by: "Roger Ronald" <rronald@pmr.com>
To: "HSSG" <stds-802-3-hssg@ieee.org>
cc: (Edward Turner/GB/3Com)
Subject: MDIO clock rate
Why should the clock run faster?
Has anyone, anywhere, EVER complained that their ability to use
MDIO/MDC was adversely impacted by the clocking rate specified?
I doubt it. I have never seen a complaint about slow MDIO interface
operation.
Backward compatibility is FAR more important than going faster
just because it is possible.
RR
----- Original Message -----
From: "David Law" <David_Law@eur.3com.com>
To: "Devendra Tripathi" <tripathi@vitesse.com>
Cc: "Edward Turner" <Edward_Turner@eur.3com.com>; <stds-802-3-hssg@ieee.org>
Sent: Friday, November 03, 2000 12:36 PM
Subject: Re: XGMII electricals -> MDIO electricals
>
>
>
> Hi Tripathi,
>
> When you say keep the current electrical specification I assume you are
> referring to the Clause 22 specification and I guess that the reason for this
is
> to allow the 10Gb/s devices, with the new Clause 33 MDC/MDIO bus, to co-exist
on
> the same MDC/MDIO bus as the existing 10/100/1000Mb/s parts that have the
Clause
> 22 MDC/MDIO bus. You however then go on to say multiply the clock frequency by
> 10. Now I may be missing something but unfortunately I believe that increasing
> the maximum clock frequency by 10 will mean that the new Clause 33 MDC/MDIO
> devices will no longer be able to exist on the same MDC/MDIO bus a exiting
> (Clause 22) parts. The reason for this is the existing parts may not be
designed
> to operate at any MDC speed any higher than that specified in Clause 22.
> Exposing these devices to this higher speed clock may make them operate
> incorrectly which in turn may corrupt the operation of the entire MDC/MDIO
bus.
> I therefore believe that if you wish to maintain backward compatibility with
the
> voltage, you have to also maintain backward compatibility with the timing
> specification.
>
> Now I suppose one option would be to specify a higher speed clock for the
Clause
> 33 MDC/MDIO but require that at startup a MDC/MDIO master (STA) poll all the
> devices on the bus to see if they are all Clause 33 devices. If they all are
> then the bus can operate at the higher speed, if they are not then the bus
would
> have to operate at the Clause 22 speed. Is that what you were proposing ?
>
> Regards,
> David Law
>
>
>
>
>
>
>
>
> Devendra Tripathi <tripathi@vitesse.com> on 03/11/2000 17:53:47
>
> Sent by: Devendra Tripathi <tripathi@vitesse.com>
>
>
> To: Edward Turner/GB/3Com@3Com, "'stds-802-3-hssg @ieee.org'"
> <stds-802-3-hssg@ieee.org>
> cc: (David Law/GB/3Com)
> Subject: Re: XGMII electricals -> MDIO electricals
>
>
>
>
>
> I would retain the current MDC/MDIO electrical specification. Timing wise,
> the clock
> frequency could be multiplied by a factor of 10.
>
> Tripathi.
>
> At 01:48 PM 11/3/00 +0000, Edward Turner wrote:
>
>
>
> >Jeff,
> >
> >I'd like to pick up your last point : "...what about MDC/MDIO levels?".
> >For D1.1 I inserted an editors note under an "Electrical interface"
> >section as a
> >place holder for an interface to be approved by the Task Force. At the Tampa
> >meeting I intend to propose that we just adopt the logic family that the
XGMII
> >uses (we might have to put a note in about termination schemes as the MDIO is
> >multi-drop).
> >If anyone has any specific concerns with this I encourage them to voice
> >them and
> >bring bring forward an alternative proposal to the meeting.
> >
> >Regards
> >Ed
> >
> >
> >
> >
> >
> >"Jeff Porter (rgbn10)" <j.porter@motorola.com> on 02/11/2000 22:18:44
> >
> >Sent by: "Jeff Porter (rgbn10)" <j.porter@motorola.com>
> >
> >
> >To:
> >cc: "'stds-802-3-hssg @ieee.org'" <stds-802-3-hssg@ieee.org> (Edward
> > Turner/GB/3Com)
> >Subject: Re: XGMII electricals
> >
> >
> >
> >
> >
> >
> >In an effort to get us all on the same page, here are links to
> >the standard XGMII interface proposals, SSTL-2 and HSTL Class 1
> >on the JEDEC site under "Free Standards":
> >
> >HSTL Class 1
> > http://www.jedec.org/download/search/jesd8-6.pdf
> >
> >SSTL_2 Class 1 (per page 9,
> >http://grouper.ieee.org/groups/802/3/ae/public/jul00/frazier_1_0700.pdf)
> > http://www.jedec.org/download/search/jesd8-9.pdf
> >
> >First, I also discourage the development of a new 1.8V interface definition
> >for XGMII for many of the reasons already on the reflector.
> >
> >I regret not making a larger issue in New Orleans about the fact
> >that HSTL is a 1.5V specification. I thought there was consensus on
> >the idea of saving power by going to HSTL, and was (too) willing to
> >go along with voting on HSTL and 1.8V at the same time based on
> >claims that there was another standard out there, and assuming that
> >lacking a standard, we would still go to real (1.5V) HSTL.
> >
> >The very valid point has been made that interface variations outside
> >of the IEEE standard often become popular, and that may also
> >become true with XGMII. So the question is where the standard
> >should point, what guidance should we give implementers? Since HSTL is
> >available, standardized, and lower power, this makes a better *standard*
> >interface than SSTL_2 (similar attributes, but higher power).
> >That is, guide implementers toward a lower power solution.
> >
> >It has been stated that 2.5V SSTL_2 interfaces are implemented on
> >early XGMII interfaces. There was discussion at New Orleans that at
> >least some of these interfaces also work down to 1.8V. Even if we select HSTL
> >(i.e. 1.5V), as a practical matter, many 0.18um HSTL interfaces may also work
> >up to 1.8V, which may be more convenient in systems at first than a 1.5V
> >supply.
> >If XGMII lives long enough for some reason, the market might go to even lower
> >"1.5V tolerant" interface (e.g. 0.9-1.6V range specified in jesd8-11.pdf,
> >October 2000, but with 50 ohm drive level).
> >
> >Perhaps a bigger question is, what about MDC/MDIO levels?
> >Jeff
> >
> >
> >
> >
> >"Grow, Bob" wrote:
> > >
> > > Implementing the XGMII concensus of the Task Force expressed through straw
> > > polls in New Orleans is a problem. In fact, I would characterize the
> > actions
> > > we took in New Orleans to be an example of group think gone wild. We had
a
> > > comprehensive SSTL specification in the draft, but made the straw poll
> > votes
> > > to change on concepts, not proposed specifications.
> > >
> > > There is no standard for HSTL at 1.8 volts (the preferred voltage per
straw
> > > poll), nor did the TF select any other parameters of the electrical
> > > specifications. (Class I, 1.5 volt HSTL as specified in EIA/JESD8-6
> > is the
> > > closest standardized alternative that the team working on clause 46 could
> > > find). Because we couldn't find a standard to reference and the Task
Force
> > > didn't endorse a complete set of 1.8 volt specifications, there was no way
> > > an HSTL electrical specification could be inserted into the draft without
> > > adding a lot of technical material that hadn't been endorsed by the
> > > committee. Therefore, all you will find in Draft 1.1 on HSTL is an
> > editor's
> > > note describing the situation.
> > >
> > > Most discussion supports the idea that the XGMII electrical interface
> > is for
> > > near term usage (with continued use as an module to module logic interface
> > > within a chip). Implemeters expect the electrical interface to be
supported
> > > by I/O devices in quick turn silicon libraries. Some participants in the
> > > editorial session thought ASIC vendors might have a 1.8 volt HSTL derived
> > > from the above referenced specification, but weren't sure of any vendors
> > > supporting it (for inclusion in the standard it should be supported by
many
> > > vendors).
> > >
> > > We have a similar problem with the clock alignment were the straw poll
> > > endorsed a change without any specifications to implement the change
(e.g.,
> > > skew specifications).
> > >
> > > As it now stands, I would vote against going to Task Force ballot. It
> > would
> > > be a shame for TF ballot to be delayed because of the absence of XGMII
> > > electricals. I see three alternatives that would allow us to go forward
to
> > > TF ballot.
> > >
> > > 1. Return to the SSTL specifications of Draft 1.0
> > > 2. Reference HSTL at 1.5 volts per EIA/JESD8-6 and select from the
options
> > > within that specification.
> > > 3. Someone presents a detailed proposal including all appropriate
> > > specifications (timing, thresholds, AC and DC characteristics,
termination,
> > > etc.)
> > >
> > > As the clause editor, I will be proposing alternative 1 in Tampa unless
> > > participants come through with presentations (sufficiently detailed to
> > go to
> > > TF ballot), and the Task Force endorses the specifications presented.
> > >
> > > Bob Grow
> > > Editor Clause 46
> >
> >
> >
> >
>
> Best Regards,
>
> Devendra Tripathi
> Vitesse Semoconductor Corporation
> 3100 De La Cruz Boulevard
> Santa Clara, CA 95054
> Phone: (408) 986-4380 Ext 103
> Fax: (408) 986-6050
>
>
>
>
>
>
>
PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com