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