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

RE: [10GBASE-CX4] SIGNAL_DETECT - A picture is worth ~245 words



I agree with Shawn that the signal detect function should be close to that for the ||LF|| indication. The relative amplitudes of the high frequency and low frequency signals may indeed be substantial; at least some current XAUI parts have the signal detector function looking at the signal before receive equalization is performed, so the full HF channel loss a.c.w the LF loss is quite relevant. Particularily in a 'closed eye' situation, the main purpose of the SIGNAL DETECT function is to detect a broken or missing connection, not to declare any particular quality information about the incoming signal. The latter comes from a higher level (such as error characters in the XGMII or equivalent stream, CRC errors etc at the MAC level, and so on). The SIGNAL DETECT mostly says to the CDR 'don't bother to look for bit sync, let alone byte sync, there's no intelligent data here', and to the installer 'you haven't plugged in both ends yet'.
 
Peter Bradshaw
 

	-----Original Message----- 
	From: DOVE,DANIEL J (HP-Roseville,ex1) [mailto:dan.dove@hp.com] 
	Sent: Tue 1/28/2003 8:18 AM 
	To: 'Howard A. Baumer' 
	Cc: '10GBCX4' 
	Subject: RE: [10GBASE-CX4] SIGNAL_DETECT - A picture is worth ~245 words
	
	

	Hi Howard,
	
	Actually, I think we want a spec there. However, perhaps we should
	loosen it up so that it is easy to measure. I have revised the
	section to also point out that the specs apply to all four channels.
	
	Dan
	
	
	-----Original Message-----
	From: Howard A. Baumer [mailto:hbaumer@broadcom.com]
	Sent: Monday, January 27, 2003 5:34 PM
	To: DOVE,DANIEL J (HP-Roseville,ex1)
	Cc: '10GBCX4'
	Subject: Re: [10GBASE-CX4] SIGNAL_DETECT - A picture is worth ~245 words
	
	
	Dan,
	    First off, I like this.  Second, there is no usage of SDAT in the text
	but
	you have it in the table and the timing diagram.  Do you think we can delete
	that one parameter?
	
	Howard
	
	
	"DOVE,DANIEL J (HP-Roseville,ex1)" wrote:
	
	> Last one bounced. Too Large. New try.
	>
	> -----Original Message-----
	> From: DOVE,DANIEL J (HP-Roseville,ex1)
	> Sent: Monday, January 27, 2003 3:45 PM
	> To: 'Howard A. Baumer'
	> Cc: Rogers, Shawn; 10GBCX4
	> Subject: RE: [10GBASE-CX4] SIGNAL_DETECT - A picture is worth ~245 words
	>
	> I am attaching a PDF shot at this.
	>
	> Dan
	>
	> -----Original Message-----
	> From: Howard A. Baumer [mailto:hbaumer@broadcom.com]
	> Sent: Monday, January 27, 2003 1:35 PM
	> To: DOVE,DANIEL J (HP-Roseville,ex1)
	> Cc: Rogers, Shawn; 10GBCX4
	> Subject: Re: [10GBASE-CX4] SIGNAL_DETECT
	>
	> Dan,
	>     If we use the low freq. content of the IPG then the loss at those freq
	> is
	> going to be around 12-15db (for 312.5MHz los components are: ~6db from Tx
	> eq.,
	> ~6-9db from the channel).  The Hf & Lf levels are within ~5dB (Rx eq takes
	> up
	> this slack) so the sig det thresholds would then be withn a factor of 2
	(or
	> less) of each other. The IPG will guarantee us that we will have some low
	> frequency content so there will be something to check.  If we look at the
	> max
	> packet size of 1600 Bytes (rounding to make it easy) then there is 400
	bytes
	> per lane which equates to 4000 symbols.  Since thse could conceivably be
	the
	> "1010.." pattern (valid 8B10B coded output) we would need to wait that
	time.
	> 4000*0.32ns =1280ns.
	>     It becomes a trade off of the time used to get hysterisus to indicate
	> signal loss versus the level we use to get signal on.  The level to detect
	> Hf
	> will more than likely end up close to a noise threshold.  Waiting a longer
	> time
	> (more like 4us to allow non-standard jumbo packets) is not that bad a
	> compromise to get a bit more robust signal detect threshold.
	>
	> Howard
	>
	> "DOVE,DANIEL J (HP-Roseville,ex1)" wrote:
	>
	> > Howard,
	> >
	> > Your approach is similar to mine except you assume a worst
	> > case "010101" pattern and I was willing to take advantage of
	> > the fact that the IDLE pattern will contain more low-frequency
	> > content and thus we could increase the amplitude of the
	> > squelch. Your approach allows a shorter time-frame for
	> > detection of the OFF state though.
	> >
	> > Dan
	> >
	> > -----Original Message-----
	> > From: Howard A. Baumer [mailto:hbaumer@broadcom.com]
	> > Sent: Monday, January 27, 2003 11:37 AM
	> > To: Rogers, Shawn
	> > Cc: 10GBCX4
	> > Subject: Re: [10GBASE-CX4] SIGNAL_DETECT
	> >
	> > My $0.02,
	> >     I think Shawn has a good point here.  The resultant receivers'
	> > sensitivity
	> > could end up quite low and therefore random noise could trigure a
	> > SIGNAL_DETECT.  If we were to use the CL 48 state machine fault sections
	> > then
	> > we presuppose there will always be a PMD and a PCS in the same Si.
	> >     Another way to look at the problem would be to look at what the
	> > amplitude
	> > of the high frequency signal would be (the "1010...", the transition
	> > ..,0,1,...).  Allowing for a loss of 16-20dB from transmit mdi to
	receive
	> > mdi
	> > then we could specify if the receive signal goes above -20dB of the
	> > transmitted
	> > signal SIGNAL_DETECT goes on and if it doesn't for 32ns after that it
	goes
	> > off.
	> >
	> > Howard
	> >
	> > "Rogers, Shawn" wrote:
	> >
	> > > My $0.02:
	> > >
	> > > I do not see how SIGNAL_DETECT can be specified in terms of a receiver
	> > > sensitivity threshold when, based on data presented, the receive eye
	> will
	> > > likely be completely closed.
	> > >
	> > > Even if not completely closed, there is a high likelihood that the
	> > receiver
	> > > min threshold will be so low that, even after EQ, you will not be able
	> to
	> > > accurately apply a level test to determine whether there is adequate
	> > signal
	> > > to make a decision.
	> > >
	> > > I believe the right approach lies in using the state machines provided
	> in
	> > > Clause 48 to declare a Local Fault condition.
	> > >
	> > > Shawn
	> > >
	> > > ____________________________________________
	> > > Shawn Rogers,   PMP               s-rogers@ti.com
	> > > High Speed Serial Link Marketing
	> > > Texas Instruments
	> > > 12500 TI Boulevard / M/S 8732/ Dallas, Texas 75243
	> > > Office: 214.480.2678                        Cell: 214.549.4868
	> > > ______________________________________
	> > >
	> > >
	> > > -----Original Message-----
	> > > From: Petre Popescu [mailto:popescu@mail.quaketech.com]
	> > > Sent: Monday, January 27, 2003 12:16 PM
	> > > To: 10GBCX4
	> > > Subject: [10GBASE-CX4] SIGNAL_DETECT
	> > >
	> > > Howard,
	> > > Please find attached the text proposed for SIGNAL_DETECT.
	> > > I found the most appropriate text for our applications in clause
	> > > 39 (1000BASE-CX).
	> > > Regards, Petre
	> > >
	> > > --
	> > > Petre Popescu
	> > > Quake Technologies
	> > > 613.270.8113.x2229
	> > > 613.220.8982 (cell)
	>
	>   ------------------------------------------------------------------------
	>                         Name: SIGNAL_DETECT.pdf
	>    SIGNAL_DETECT.pdf    Type: Adobe Acrobat Document (application\pdf)
	>                     Encoding: base64