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

RE: delay constraints from XGMII to XAUI




Pat,
The longest delay may occur in the system:
MAC-xgmii-XGXS-xaui-XGXS-PCS-WIS-xsbi-PMA-PMD-optics-PMD... and vice versa.
The MAC to MAC flow control mechanism has to support it. If you spec delay
segments, you may impose an un necessary delay constraint in simpler systems
like 10GBASE-X for instance.

> -----Original Message-----
> From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
> Sent: Thursday, December 14, 2000 9:28 PM
> To: Boaz Shahar; HSSG
> Subject: RE: delay constraints from XGMII to XAUI
> 
> 
> 
> Boaz,
> 
> If there is a compatibility interface such as XAUI, then one 
> needs to define
> how much delay is on either side of it. Therefore one needs 
> to spec at least
> the following:
>   XGMII to XGMII (MAC reaction time to the flow control).
>   XGMII to XAUI
>   XAUI to XBSI
>   XBSI to MDI
> 
> The point of compatibility interfaces is to define an interface where
> components independently designed can be compatible when mated at that
> interface. Therefore, a budget can't be specified for the 
> total without
> providing a breakdown with respect to the compatibility 
> interfaces. If a
> compatibility interface is not physically instantiated then 
> the device has
> to meet the total but it is up to the device how to allocate 
> that total.
> 
> For instance, if a device had an XGMII and an MDI, then it 
> would have to
> meet the sum of the three delays: XGMII to XAUI, XAUI to XBSI 
> and XBSI to
> MDI.
> 
> One way to specify this is to specify the delay for each 
> sublayer and say
> that the total between compatibility interfaces need to meet 
> the total for
> the sublayers between them. 
> 
> Since this delay is only important for the flow control, I 
> recommend we
> choose values that are easy to meet and specify them per 
> sublayer. No matter
> what we do, our delays will be long in bit times compared to the lower
> speeds because our paths so wide. There is no reason to tweak 
> the delays to
> shave a few byte times. 
> 
> Regards,
> Pat
> 
> -----Original Message-----
> From: Boaz Shahar [mailto:boazs@mysticom.com]
> Sent: Thursday, December 14, 2000 12:43 AM
> To: HSSG
> Subject: RE: delay constraints from XGMII to XAUI
> 
> 
> 
> Hi,
> I think that the standard should constraint only the total 
> delay from the
> MDI to the XGMII, and leave internal partitioning to implementation.
> Boaz
> 
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@earthlink.net]
> > Sent: Thursday, December 14, 2000 12:18 AM
> > To: HSSG
> > Subject: Re: delay constraints from XGMII to XAUI
> > 
> > 
> > 
> > Bob,
> > 
> > Agreed.
> > 
> > Steven,
> > 
> > Just to carify, the MDI to XGMII delay includes the XAUI to 
> > XGMII delay.
> > 
> > Best Regards,
> > Rich
> >      
> > --
> > 
> > "Grow, Bob" wrote:
> > > 
> > > The only MAC requirement I can think of for bounding the 
> > lower layer delay
> > > is for buffer sizing for 802.3x flow control.  That has 
> > been the factor for
> > > keeping the delay tables in various clauses.
> > > 
> > > --Bob Grow
> > > 
> > > -----Original Message-----
> > > From: Steven Shen [mailto:ss_shen@siliconbridge.com]
> > > Sent: Wednesday, December 13, 2000 11:58 AM
> > > To: stds-802-3-hssg@ieee.org
> > > Subject: delay constraints from XGMII to XAUI
> > > 
> > > Hi all:
> > > 
> > > In D2.0 table 48.5 defines the MDI to XGMII delay 
> > constraints to be 272
> > > UI. I wonder that "is there any delay constraints on XAUI to XGMII
> > > (PCS+PMA)"?
> > > 
> > > thanks
> > > 
> > > best regards
> > > 
> > > Steven Shen
> > > Silicon Bridge Inc.
> >                                  
> > ------------------------------------------------------- 
> > Richard Taborek Sr.                 Phone: 408-845-6102       
> > Chief Technology Officer             Cell: 408-832-3957
> > nSerial Corporation                   Fax: 408-845-6114
> > 2500-5 Augustine Dr.        mailto:rtaborek@nSerial.com
> > Santa Clara, CA 95054            http://www.nSerial.com
> > 
>