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

Re: [BP] how to evaluate signaling method follow up



Hi Graeme,

Could the reason the phase on crosstalk channels does not inherently
extrapolate to 0 at DC, be due to the crosstalk channels being inherently
AC-coupled?

If so, then I don't think we want to do the "shift the whole curve to 0 at
DC" step.

Brian

p.s. getting inverted phase is a real puzzle.



----- Original Message -----
From: "Graeme Boyd" <why@pmc-sierra.com>
To: "Brian Brunn" <Brian.Brunn@xilinx.com>;
<STDS-802-3-BLADE@listserv.ieee.org>
Cc: <why@pmc-sierra.com>
Sent: Wednesday, September 08, 2004 5:44 PM
Subject: RE: [BP] how to evaluate signaling method follow up


> Brian
>
> MAG=1 @ DC is clearly wrong especially for long channels due to non-zero
> resistance of the channel
>
> On the phase front really only have 2 options
> 1) extrapolate linearly (as I indicated) and shifting the entire curve
> 2) extrapolate with DC = 0 and x number of the lower unwrapped phase
> points say with spline curve fitting
>
> Of the two I have found the results appear to make more sense with
> shifting the entire curve. Note that something clearly went wrong with
> the measurements if it does not linearly extrapolated to 0 at DC. For
> most cases I find that if one does a good calibration the amount you
> have to shift the curve is on the order of 0.5 to 1 degree for the
> forward channel. Now the cross talk channels do give rise to more
> problems for some reason.
>
> As for getting inverted phase, I have seen this several times from our
> customers when they send me data. I assume this is happening due to the
> method of calibration and then flipping the cables for the real
> measurement but really don't know for sure.
>
> Graeme
>
> On Wed, 2004-09-08 at 15:08, Brian Brunn wrote:
>> Hi Graeme,
>>
>> Thanks.
>>
>> I agree with the magnitude.  I've seen people use MAG=1 @ DC which is
>> painful.
>>
>> On the phase, it appears to me that phase delay (not group delay) is our
>> quantity of interest so I am leery about shifting the whole phase curve.
>>
>> Do you know how measured s-parameters can result in inverted phase?
>>
>> Brian
>>
>>
>>
>> -----Original Message-----
>> From: Graeme Boyd [mailto:why@pmc-sierra.com]
>> Sent: Wednesday, September 08, 2004 4:29 PM
>> To: Brian Brunn
>> Cc: why@pmc-sierra.com; STDS-802-3-BLADE@listserv.ieee.org
>> Subject: Re: [BP] how to evaluate signaling method follow up
>>
>> Brian
>>
>> How about this.
>>
>> - For magnitude part:
>>   - Extrapolation toward DC linearly based on at least the lowest 5
>> measured points
>>
>> - For phase part:
>>   - Extrapolation toward DC linearly on the unwrapped phase based on at
>> least the lowest 5 measured points
>>   - Shift the entire curve such that the point at DC has 0 degrees
>>   - If required invert the curve so that the unwrapped phase decreases
>> with increasing frequency
>>
>>
>> Also of note if one is going to use S-parameters within Hspice we have
>> found that one needs to have linearly spaced frequency steps starting at
>> DC and going to at least 3x baud rate (for NRZ) to get similar results
>> with ADS or MATLAB.
>>
>> Graeme
>>
>> On Thu, 2004-09-02 at 08:49, Brian Brunn wrote:
>> > All,
>> >
>> > On todays call there were references to the need to "properly"
>> > extrapolate
>> > measured s-parameter data down to DC in order to generate accurate
>> > pulse
>> > responses.  It appears for signalling evaluation, we need to agree on a
>> > common method.
>> >
>> > Is anyone interested in making a proposal?
>> >
>> > Brian Brunn
>> > Xilinx
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: owner-stds-802-3-blade@listserv.ieee.org
>> > [mailto:owner-stds-802-3-blade@listserv.ieee.org]On Behalf Of Ali
>> > Ghiasi
>> > Sent: Thursday, September 02, 2004 10:50 AM
>> > To: STDS-802-3-BLADE@listserv.ieee.org
>> > Subject: Re: [BP] how to evaluate signaling method follow up
>> >
>> >
>> > Mike
>> >
>> > Attach is the pulse response I get for the IEEE thru_rev5 model, I was
>> > referring to the ripple prior to
>> > main pulse.
>> >
>> > Thanks,
>> > Ali
>> >
>> > Mellitz, Richard wrote:
>> >
>> > >I added the shell for package modeling that I've been using for some
>> > >time now. I just call it the spec package models that I use to driver
>> > >real design requirement. I just tuned the models to -10dB for the 5GHz
>> > >and under mark. It's under 100 MB too :-)
>> > >
>> > >Anyhow it's a 3 differential line model and assumes the die resistance
>> > >and capacitance load are parameters in the die model outside of this
>> > >package model.
>> > >
>> > >
>> > >PS, Oh Charles,
>> > >Neat hspice tricks! It addresses channel jitter amplification.
>> > >
>> > >
>> > >-----Original Message-----
>> > >From: owner-stds-802-3-blade@listserv.ieee.org
>> > >[mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of Charles
>> > >Moore
>> > >Sent: Wednesday, September 01, 2004 7:23 PM
>> > >To: STDS-802-3-BLADE@listserv.ieee.org
>> > >Subject: [BP] how to evaluate signaling method follow up
>> > >
>> > >
>> > >guys,
>> > >
>> > >    Here is the next step after the proposal i sent out August 23.
>> > >
>> > >    This includes:
>> > >
>> > >    1.  A simulation file for NRZ simulation.
>> > >
>> > >    2.  A transmitter subcircuit file for NRZ simulation.
>> > >
>> > >    3.  A simulation file for PAM4 simulation.
>> > >
>> > >    4.  A transmitter subcircuit file for PAM4 simulation.
>> > >
>> > >    5.  a zip file with the PRBS pwl files i used.
>> > >
>> > >    You can look at the files to see the structure of the simulation
>> > > or
>> > >use them to do simulations yourself.  If you want to do simulations
>> > >you will need:
>> > >
>> > >    1.  A receiver subcircuit file named "rx.inc".  I am treating
>> > >        receivers as proprietary.
>> > >
>> > >    2.  Package model subcircuit files for the transmitter called:
>> > >        "TxPackage.inc" and for the receiver called: "RxPackage.inc"
>> > >
>> > >    3.  A touchstone file describing the channel.  You may need to
>> > >        change the name of the file in the simulation file.
>> > >
>> > >     You may want to change the parameter values in the simulation
>> > > file.
>> > >The tap values i have included give fairly good EYEs with Steve
>> > >Anderson's thru6 channel and the stresses nearly or just re-close the
>> > >EYE.
>> > >
>> > >    The over all structure of the simulation deck for either is:
>> > >
>> > >    The simulation file includes:
>> > >
>> > >      1.  Parameter values, which are in 3 kinds:
>> > >        A.  Transmitter definition parameter:
>> > >            i.   baud, baud rate:  10.3125G for NRZ or 5.15625G for
>> > > PAM4
>> > >            ii.  Amp, the nominal peak to peak differential amplitude
>> > >            iii. Trf, the trapezoidal rise and fall time in UI
>> > >        B.  Transmitter peaking parameters:
>> > >            i.   1 Precursor and 1 postcursor tap value for NRZ
>> > >            ii.  2 Postcursor tap values for PAM4
>> > >        C.  Stress parameters:
>> > >            i.   XtalkAmp, interference amplitude (half peak to peak)
>> > >            ii.  XtalkFratio, ratio of interference frequency to
>> > >                 baud rate.
>> > >            iii. TJ, total jitter in UI
>> > >            iv.  dutyCycle_over_TJ, fraction of total jitter which is
>> > >                 at half baud rate
>> > >    2.  Transmitter sub circuit.  The transmitter sub circuit
>> > > implements
>> > >        a 3 tap equalizer and includes parameterized jitter.
>> > >    3.  Package models.  I am going to ask that someone else find a
>> > >        suitable model.
>> > >    4.  The channel.
>> > >    5.  Receiver load (the Tx load is included in the subcircuit)
>> > >    6.  Interference injection sources.
>> > >    7.  An instance of the receiver sub circuit.  Someone else should
>> > >        provide the receiver model.  It may be encrypted.  The Out
>> > >        port or the MSB and LSB ports should be considered the
>> > >        final measurement point.
>> > >
>> > >     If we decide to proceed with this approach the following will
>> > > need
>> > >to be done before going too much farther:
>> > >
>> > >     1.  Define standard values for Transmitter definition parameters
>> > >         and targets for Stress parameters.  These may be different
>> > > for
>> > >         the 3 (or more) signaling schemes.
>> > >     2.  Find a  set of channels to simulate over.
>> > >     3.  Write scripts for analyzing the output including finding
>> > >         EYE size if that is relevant and checking for correct data.
>> > >     4.  Write scripts which pre-code PRBS data for duo-binary or
>> > >         write output analysis script to post-decode the data.
>> > >     5.  Generate longer data files for more through testing.  The
>> > >         included scripts should be good enough for finding the right
>> > >         equalizer settings etc. but we will want longer more complex
>> > >         patterns for final evaluation.
>> > >     6.  Separate out all the parts of the simulation file which are
>> > >         design values (like tap values) from the specified parts, and
>> > >         put them in an include file.
>> > >     7.  Fix the various problems which the ad-hoc will discover for
>> > >         me.
>> > >
>> > >                      charles
>> > >
>> > >
>> > >
>> > >|--------------------------------------------------------------------|
>> > >|       Charles Moore
>> > >|       Agilent Technologies
>> > >|       ASIC Products Division
>> > >|       charles_moore@agilent.com
>> > >|       (970) 288-4561
>> > >|--------------------------------------------------------------------|
>> > >
>> > >
>>
>>
>
>