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

[802.3ae_Serial] FW: DJ in fiber




I am forwarding this discussion to the reflector because this seems to be
relevant to all. 

The discussion was between Russ Patterson of Picolight and Peter Öhlén of
Optillion, concerning the 10GBASE-S transversal filter used for TDP
measurement, but has general applicability to jitter measurements in the
entire standard.

Please review and comment to the reflector.

Cheers,
Dave

------
David Kabal
Sr. Technology Planner
Picolight

e-mail: david.kabal@xxxxxxxxxxxxx
Main: 303-530-3189 x7498
Direct: 303-527-7498
Fax: 303-527-4961


-----Original Message-----
From: Peter Öhlén [mailto:Peter.Ohlen@xxxxxxxxxxxxx] 
Sent: Thursday, February 28, 2002 1:17 AM
To: Russ Patterson
Cc: David Kabal
Subject: RE: DJ in fiber

Russ,

I agree with Dave, that this is a great discussion for the reflector,
but I will just give a quick answer:

It is correct that there is no explicit allocation for jitter from the
fiber. Now, the rationale for the transversal filter may not be quite
clear from the text (which has not really changed in intention). Still,
the intention was that that filter would simulate a worst case channel.

Regards,
		Peter

> -----Original Message-----
> From: Russ Patterson [mailto:Russ.Patterson@xxxxxxxxxxxxx]
> Sent: den 28 februari 2002 00:40
> To: Peter Öhlén
> Cc: David Kabal
> Subject: RE: DJ in fiber
> 
> 
> I thought some more about what you said about jitter. I looked in some
> earlier versions of clause 52 (D3.1 with the bathtubs)  and 
> it looks like
> there is no Deterministic jitter what so ever allocated to 
> the fiber for
> base SR.  
> 
> 
> In D3.1,  the receiver  needed to meet the same waterfall 
> mask (figure 52-6)
> as the transmitter (outside for TX, middle for RX).  The transmitter
> waterfall was to be tested with < 5 meters of fiber. 
> Therefore no allocation
> for fiber jitter. 
> 
> 
> So it looks to me as it there was no deterministic jitter originally
> intended for the fiber , only ISI was allocated.
> 
> 
> Has this requirement changed in D4.1?  If so, sounds like it 
> clearly needs
> to be quantized somewhere in the clause.  ie "the worse case 
> fiber will be
> assumed to add  TBD  UI of deterministic jitter".   And then 
> we would need
> to construct a filter to generate the desired amount of 
> closure and jitter. 
> 
> 
> Russ P
> 
>   
> 
> -----Original Message-----
> From: Peter Öhlén [mailto:Peter.Ohlen@xxxxxxxxxxxxx]
> Sent: Wednesday, February 27, 2002 4:38 AM
> To: Russ Patterson
> Cc: David Kabal
> Subject: RE: Need for Transversal filter
> 
> 
> Russ,
> 
> I see your point, and this is important input. To me it seems like the
> transversal filter does not do the job it is supposed to, which is bad
> news. It is clear that something else is needed.
> 
> Many think that jitter is quite important to control, and to use a
> filter optimized for flat group delay (low jitter) as an 
> artefact for a
> fiber which would introduce jitter would probably require _very_ solid
> arguments. As far as I understand, there is no such thing as a
> worst-case multi-mode fiber as the actual bandwidth depends on the
> coupling between the TX and the fiber, which is the reason for the
> electrical filter.
> 
> /Peter
> 
> > -----Original Message-----
> > From: Russ Patterson [mailto:Russ.Patterson@xxxxxxxxxxxxx]
> > Sent: den 26 februari 2002 16:52
> > To: Peter Öhlén
> > Cc: David Kabal
> > Subject: RE: Need for Transversal filter
> > 
> > 
> > Here is a result of a sim I did on the filter. Although the 
> > eye does not
> > appear  symmetrical in the time domain I do not see any 
> > significant amount
> > of added deterministic jitter at the average level . So  
> > where is the added
> > jitter  that you speak of?
> > 
> > 
> > 
> > Thanks
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Peter Öhlén [mailto:Peter.Ohlen@xxxxxxxxxxxxx]
> > Sent: Tuesday, February 26, 2002 7:49 AM
> > To: Russ Patterson
> > Cc: David Kabal
> > Subject: RE: Need for Transversal filter
> > 
> > 
> > Russ,
> > 
> > The Bessel-type filters or similar (like the Picosecond ones) 
> > are really
> > designed to have very low jitter, and the purpose of the test is to
> > simulate worst-case fiber, including addition of jitter. Therefore I
> > don't think it is a good idea to replace the transversal 
> filter with a
> > Bessel filter.
> > 
> > Best regards,
> > 			Peter
> > 
> > > -----Original Message-----
> > > From: Russ Patterson [mailto:Russ.Patterson@xxxxxxxxxxxxx]
> > > Sent: den 22 februari 2002 01:17
> > > To: Peter Öhlén
> > > Cc: David Kabal
> > > Subject: Need for Transversal filter
> > > 
> > > 
> > > 
> > > Peter:
> > > 
> > > re 52.9.12.3   
> > > 
> > > 
> > > is it really necessary that we construct a transversal type 
> > filter to
> > > simulate eye closure?  A simulation of the filter shows I can 
> > > accomplish
> > > much the same ISI effect using a linear phase nth order roll 
> > > off filter.  
> > > 
> > >  The Transversal delay line filter repeats in the frequency 
> > > domain with a
> > > period close to 10 GHz  , however the 7.45 GHz cutoff of 
> > the receiver
> > > essentially removes all but the baseband  response.  
> > > 
> > > 
> > > For production test purposes  I feel it is simpler to have a 
> > > picosecond
> > > pulse labs type filter rather than try and construct a 
> > > transversal filter
> > > from splitters and combiners, line  stretchers etc. 
> > > 
> > > 
> > > Could we modify the text in 52.9.12.3 to say
> > > 
> > >  "transversal filter or equivalent lumped element filter to 
> > > simulate the ISI
> > > created by two equal amplitude paths with a differential 
> > > delay of xx psec
> > > where xx is adjusted to obtain the desired amount of ISI"
> > > 
> > > 
> > > 
> > > 
> > > thanks
> > > 
> > > 
> > > 
> > > Russ Patterson
> > > Opto Electronic Design Engineer
> > > Phone:  303-530-3189 ext 7447
> > > FAX      303-527-4968
> > > 
> > > Picolight Inc
> > > 4665 Nautilus Court
> > > Boulder, Colorado
> > > 80301
> > > russ.patterson@xxxxxxxxxxxxx
> > > 
> > > 
> > 
> > 
>