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



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
> > >|--------------------------------------------------------------------|
> > >
> > >
>
>