Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [BP] how to evaluate signaling method

Joe, Charles,
 
This has been our finding as well.  Not to be unfair to Hspice, but the analog simulation environment uses very small timesteps (order of fs~ps) and this limits the overall time that can be simulated.
 
Adaptive simulations will clearly need to simulate for milllions of bits.
 
.../Mike

From: owner-stds-802-3-blade@LISTSERV.IEEE.ORG [mailto:owner-stds-802-3-blade@LISTSERV.IEEE.ORG] On Behalf Of Joe M Abler
Sent: Wednesday, August 25, 2004 3:04 PM
To: STDS-802-3-BLADE@LISTSERV.IEEE.ORG
Subject: Re: [BP] how to evaluate signaling method


Building on the points here and adding to my last comments, we find that we need to simulate millions of bit times (actually 10M) to get any reasonable view of xtalk effects.  All the more reason Hspice becomes intractable.

Thanks,        Joe


Joe Abler                                                             abler@us.ibm.com
IBM Microelectronics Division                          919-254-0573
Technical Marketing & HSS Applications    919-254-9616 (fax)
3039 Cornwallis Road                                                                
Research Triangle Park, NC  27709


Charles Moore <charles_moore@AGILENT.COM>
Sent by: owner-stds-802-3-blade@LISTSERV.IEEE.ORG

08/24/2004 05:15 PM
Please respond to Charles Moore

       
        To:        STDS-802-3-BLADE@LISTSERV.IEEE.ORG
        cc:        
        Subject:        Re: [BP] how to evaluate signaling method



john,

   1.  a.  In measurement we pick one frequency and sweep the amplitude
           of interference.  By plotting BER vs interference amplitude
           at the we can find the Rx noise.  Knowing Rx noise we can
           compute an adder to the speced Xtalk tolerance to extrapolate
           from a measurable BER to the BER we want.  This really should
           only need to be done at one frequency.

       b.  The xtalk to use is the upper bound of the Xtalk which the
           system specs allow.  The amount of Xtalk will depend on the
           channel, the Tx low pass characteristics, Tx equalization,
           and signaling type.  All these need to be taken into account
           but some things like Tx equalization may be hard to know
           a-priori and worst case values need to be used.

       c.  We do not have much comparison.

    2  Hspice allows elements which are defined in terms of S-parameters
       in touchstone (s4p) files.  You measure them, we will use them in
       simulation, and that will be real data.

    3.  The number of bits used a trace off between simulation time and
        confidence.  Maybe we should hunt for the interference tolerance
        limit using a small number of bits, then use a larger number to
        confirm it.  Also, by worst-casing the interfering signal we
        enormously reduce the amount of simulation needed.

    4.  The PWL will be complex but manageable i think.  I should have a
        start at it to show by next meeting.

                          charles
> Charles,
> Some questions for you.
> 1. I have gone back and reviewed your presentation, and it looks to me for
> crosstalk that you are proposing for a given frequency doing an amplitude
> sweep then plotting the BER versus the Interference amplitude.
>       a. I assume for multiple frequencies this process has to be
> repeated?
>       b. This process seems to look at the xtalk performance of the
> channel
>          only, rather than the product of the Tx spectrum and channel.
> Can
>          you comment?
>       c. Have you compared the summation of signal and proposed xtalk
>          procedure against signal and broadband xtalk generation to see
> how
>          they compare?  Can you share results?
>
> 2. You are proposing modeling the channel in HSPICE?  Why would we do this
>    as opposed to use of real data?
>
> 3. The number of bits being proposed to run is 127 * 4 = 508 plus some
> offset bits.  This seems like a very small number of bits to consider,
> especially in light of the BER we are trying to achieve.
>
> 4. Won't the PWL become complex pending the Tx solution being proposed?
>
> John
>
>
>
> -----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: Monday, August 23, 2004 6:11 PM
> To: STDS-802-3-BLADE@listserv.ieee.org
> Subject: [BP] how to evaluate signaling method
>
> guys,
>
>     What i propose for signaling evaluation is an extension of
> ideas i presented at the July meeting in Portland in the talk
> "Receiver Testing Using Interference Tolerance Measurements".
>
>     The basic idea is to do a time domain simulation of the Tx,
> channel, and Rx using a standard, generally available simulator.
> To provide a simple and reproducible model of cross talk, a
> sinusoidal interfering signal will be added at the input to the
> receiver.  The amplitude of the interfering signal will be
> increased until the signal at the output of the Rx is deemed to
> be no longer usable.  The highest level of interference at which
> the Rx provides a usable output will be called the interference
> tolerance.  If the interference tolerance is below a specified
> (and perhaps signaling method dependent) value the simulated data
> path is non-compliant.  If the interference tolerance is above
> the specified value, it is compliant and has a margin which is
> equal to the difference between the simulated tolerance and the
> spec.  In general more margin is better.
>
>     This is the basic idea.  Details which i suggest be adopted as
> part of the method but which can be changed without altering the
> basic idea include:
>
> 1.  Use hspice as the simulator.
>
> 2.  Model the transmitter as:
>      a.  1 or 2 piecewise linear (PWL) current sources:
>          i.   1 current source with NRZ encoded data for NRZ signaling.
>          ii.  1 current source with precoded data for duo-binary
>               signaling.
>          iii. 2 current sources with 1/3 and 2/3 NRZ amplitude with LSB
>               and MSB data respectively, for PAM4 signaling.
>      b.  Rise times of PWL current sources set at about 30ps for NRX or
>          duo-binary or 60ps for PAM4
>      c.  R,L,C network between current source and Tx pins to provide
>          reasonable return loss vs frequency
>
> 3.  Include signaling method dependent Tx equalization in PWL current
>      source model.  Control equalization with hspice parameters.
>
> 4.  Include some modeled Tx Jitter in PWL current sources.
>
> 5.  Use hspice S-parameter network modeling capabilities to model
>      channel.
>
> 6.  Allow proprietary Rx models by Encryption.
>
> 7.  Add interference signal at Rx with sinusoidal current source.
>
> 8.  Allow for Rx input noise in the minimum interference tolerance spec.
>
> 9.  Determine that the Rx provides a usable output by:
>      a.  showing that data out of Rx gives the correct bits.
>      b.  If Rx does not include re-clocking, show that output eye is
>          wide enough
>      c.  If Rx does not include a limiting stage, show that the output
>          eye has enough amplitude.
>
> 10. Use 127 bit long PRBS pattern for data.  Offset a few bits between
>      pattern for MSB and LSB to give PAM4 pattern or use shorter PRBS
>      pattern for LSB.  Repeat PRBS pattern at least 4 times to allow
>      interference to "walk through" the data.
>
> 11. Test with more than one interfering rate.  Interesting rates
>      should include:
>      a.  For NRZ or PAM4, (1+.2/127)*(baud rate)/2
>      b.  For duo-binary, (1+.2/127)*(baud rate)/4
>
>                   charles
>
> --
> |--------------------------------------------------------------------|
> |       Charles Moore
> |       Agilent Technologies
> |       ASIC Products Division
> |       charles_moore@agilent.com
> |       (970) 288-4561
> |--------------------------------------------------------------------|


--
|--------------------------------------------------------------------|
|       Charles Moore
|       Agilent Technologies
|       ASIC Products Division
|       charles_moore@agilent.com
|       (970) 288-4561
|--------------------------------------------------------------------|