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@xxxxxxxxxxxx>
To: "Devendra Tripathi" <tripathi@xxxxxxxxxxx>
Cc: "Edward Turner" <Edward_Turner@xxxxxxxxxxxx>; <stds-802-3-hssg@xxxxxxxx>
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@xxxxxxxxxxx> on 03/11/2000 17:53:47
>
> Sent by: Devendra Tripathi <tripathi@xxxxxxxxxxx>
>
>
> To: Edward Turner/GB/3Com@3Com, "'stds-802-3-hssg @ieee.org'"
> <stds-802-3-hssg@xxxxxxxx>
> 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@xxxxxxxxxxxx> on 02/11/2000 22:18:44
> >
> >Sent by: "Jeff Porter (rgbn10)" <j.porter@xxxxxxxxxxxx>
> >
> >
> >To:
> >cc: "'stds-802-3-hssg @ieee.org'" <stds-802-3-hssg@xxxxxxxx> (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
>
>
>
>
>
>
>