Re: [BP] how to evaluate signaling method follow up
hi all,
On extrapolating S parameters down to DC:
having S parameter = 1.0 exactly at DC can cause instabilities in
simulation.
For physical realizability, at DC the imaginary term has to be 0.
If the phase extrapolates to (around) 90 degrees then the magnitude
at DC has to be zero.
charles
--
|--------------------------------------------------------------------|
| Charles Moore
| Agilent Technologies
| ASIC Products Division
| charles_moore@agilent.com
| (970) 288-4561
|--------------------------------------------------------------------|
> 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
>> >|--------------------------------------------------------------------|
>> >
>> >
>
>