Re: [BP] how to evaluate signaling method follow up
Hi Greame,
I would agree 90 degrees, except for the low-SNR issue you point out. So I
think any shift is suspect.
Brian
-----Original Message-----
From: owner-stds-802-3-blade@listserv.ieee.org
[mailto:owner-stds-802-3-blade@listserv.ieee.org] On Behalf Of Graeme Boyd
Sent: Friday, September 10, 2004 9:04 AM
To: STDS-802-3-BLADE@listserv.ieee.org
Subject: Re: [BP] how to evaluate signaling method follow up
Brian
I always though it was related to the SNR of the VNA and very low amount
of coupling for that connection. However your statement about
AC-coupling sounds better. If so then shifting the curve to 90 degrees
would be correct thing to do would it not?
I will look at some data to see if this makes sense.
Graeme
On Fri, 2004-09-10 at 03:17, Brian Brunn wrote:
> 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
> >> >
>|--------------------------------------------------------------------|
> >> > >
> >> > >
> >>
> >>
> >
> >