Re: [BP] how to evaluate signaling method follow up
Richard
I looked at your package model but I did not see input device or ESD
caps. In real implementation
the ESD diode is going to drive the package return loss and well design
package will have
negligible contribution to the overall return loss.
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
>|--------------------------------------------------------------------|
>
>
begin:vcard
fn:Ali Ghiasi
n:Ghiasi;Ali
org:Broadcom
adr;dom:;;3151 Zanker Road;San Jose;CA;95134
email;internet:aghiasi@broadcom.com
title:Chief Architect
tel;work:(408)922-7423
tel;cell:(949)290-8103
url:http://www.broadcom.com
version:2.1
end:vcard