[ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile Issues

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <fangyi_rao@xxxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 02 Dec 2011 12:17:52 -0500 (EST)

Fangyi,

 

Let me explain the derivation methods that the model maker needs to use,
based on the proposed Jitter BIRD.

 

First, the model maker understands the implementation of his CDR, and
knows which Jitter components are accounted for and which are not in the
clock times vector. The model make communicates to the EDA tool which
components are not accounted for using the parameters Rx_Rj, Rx_DCD, and
Rx_Sj. There has been a request to add a new parameter Rx_Dj. For
Statistical analysis the model maker characterizes the Rj, DCD, Sj, and
Offset of the clock times vector that would have been introduced by the
CDR. These parameters are communicated to the EDA tool using the
parameters Rx_Clock_Recovery_Rj, Rx_Clock_Recovery_DCD,
Rx_Clock_Recovery_Sj, (Rx_Clock_Recovery_Dj TBD), and
Rx_Clock_Recovery_Mean. Rx_Clock_Recovery_Mean is the offset of the center
of the clock distribution that would have come from the CDR (clock times)
and the Center of the Statistical Eye generated from the Impulse Response
output of Rx AMI_Init. The Center of the Statistic Eye is defined as half
way between the median value of the PDF of the statistical eye crossing
V=0 on either side of the eye.

 

The above derivation method is clear, both to the model maker who needs to
make the .ami file, and the EDA tool that needs to apply Jitter to the AMI
output. 

 

Does any disagree that:

1.       Derivation method is clear.

2.       EDA tool application is clear.

3.       Satisfies the need of the model maker to insure that analysis
results correctly account for Jitter.

 

Walter

 

From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] 
Sent: Friday, December 02, 2011 11:39 AM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

Typo of "clock times". Sorry for the confusion.

 

Fangyi

 

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Thursday, December 01, 2011 7:06 PM
To: RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

Fangyi,

 

What is a "clock timer"?

 

Walter

 

From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] 
Sent: Thursday, December 01, 2011 9:40 PM
To: fangyi_rao@xxxxxxxxxxx; wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

Correcting order:

 

"My main concern is that it's inconsistent for clock timers to include
Rx_Clock_PDF, Rx_Clock_Recovery_Rj, Rx_Clock_Recovery _DCD, and
Rx_Clock_Recovery _Sj but not Rx_Rj, Rx_DCD, or Rx_Sj."

 

Fangyi

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Thursday, December 01, 2011 5:58 PM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile Issues

 

Walter;

 

Thanks for the clarification. My main concern is that it's inconsistent
for clock timers to include Rx_Rj, Rx_DCD, and Rx_Sj but not Rx_Clock_PDF,
Rx_Clock_Recovery_Rj, Rx_Clock_Recovery _DCD, or Rx_Clock_Recovery _Sj.

 

Fangyi

 

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Thursday, December 01, 2011 5:29 PM
To: RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Jitter BIRD issues, and Buffer Tstonefile Issues

 

Fangyi,

 

Comments below in line.

 

Walter

 

From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx] 
Sent: Thursday, December 01, 2011 7:19 PM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Jitter BIRD issues, and Buffer Tstonefile Issues

 

Hi, Walter;

 

To simplify the discussion, I think there is only one fundamental question
we need to answer regarding Rx_Rj, Rx_DCD, and Rx_Sj:

 

If a Rx model generates clock times, should clock time values include
contributions from Rx_Rj, Rx_DCD, and Rx_Sj?

 

WMK> The clock time values output from Rx AMI_GetWave do not include
contributions from Rx_Rj, Rx_DCD, and Rx_Sj. The BIRD says they need to be
"accounted for in both Statistical and Time-Domain simulations". It is up
to the EDA tool on how it "accounted for". One way is for the EDA tool to
modify the clock time values. There are other ways that are more
statistically accurate.

 

Your #4 raise a new question: are Rx_Rj, Rx_DCD, and Rx_Sj included in
Rx_Clock_PDF, Rx_Clock_Recovery_Rj, Rx_Clock_Recovery _DCD, and
Rx_Clock_Recovery _Sj? The current BIRD suggests no.

 

WMK> You are correct. In the current BIRD is states:

"Rx_DCD" is an AMI parameter of Type either Float or UI and Usage either
Info or Out which defines half the peak to peak variation, in seconds or
UI, of a clock duty cycle distortion driven by impairments external to the
receiver. This phase noise is to be accounted for in both Statistical and
Time-Domain simulations.

 

"Rx_Rj" is an AMI parameter of Type either Float or UI and Usage either
Info or Out which defines the standard deviation, in seconds or UI, of a
Gaussian phase noise driven by impairments external to the receiver that
are input to the RX CDR, but are not included in the CDR clock_times
output. This phase noise is to be accounted for in both Statistical and
Time-Domain simulations. 

 

"Rx_Sj" is an AMI parameter of Type either Float or UI and Usage either
Info or Out which defines half the peak to peak variation, in seconds or
UI, of a sinusoidal phase noise driven by impairments external to the
receiver that are input to the RX CDR, but are not included in the CDR
clock_times output.

 

 

Regards,

Fangyi

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, November 29, 2011 2:31 PM
To: IBIS-ATM
Subject: [ibis-macro] Jitter BIRD issues, and Buffer Tstonefile Issues

 

All,

 

The remaining major issue is the handling of Rx_Rj, Rx_DCD, and Rx_Sj.

1.       It has been requested that Rx_Dj be added.

2.       First a discussion on how the Rx clock is handled in the
following two cases

a.       Time Domain

                                                               i.      Rx
AMI_GetWave returns clock ticks in *clock_times.

b.      Statistical

                                                               i.      Rx
AMI_GetWave does not return clock ticks in *clock_times.

                                                             ii.
Using Rx AMI_Init

3.       The current BIRD 123 states that Rx_Rj, Rx_DCD, and Rx_Sj shall
be applied to both Time Domain and Statistical methods.

a.       In Time Domain, Rx_Rj, Rx_DCD, and Rx_Sj can be applied to times
in clock_times, statistically to the clock_times PDF, or statistically to
the persistent eye.

b.      In Statistical, Rx_Rj, Rx_DCD, and Rx_Sj are combined
statistically along with Rx_Clock_PDF, Rx_Clock_Recovery_Rj,
Rx_Clock_Recovery_DCD, and Rx_Clock_Recovery_Sj.

4.       It has been suggested that Rx_Rj, Rx_DCD, and Rx_Sj shall apply
to just Time Domain.

a.       In Time Domain, Rx_Rj, Rx_DCD, and Rx_Sj can be applied to times
in clock_times, statistically to the clock_times PDF, or statistically to
the persistent eye.

b.      In Statistical, only Rx_Clock_PDF, Rx_Clock_Recovery_Rj,
Rx_Clock_Recovery_DCD, and Rx_Clock_Recovery_Sj are applied.

 

Regarding Tstonefile.

1.       Fangyi and I agreed the there is no requirement that S12=S21, and
that S21 can be small or zero.

2.       Fangyi and I agreed that the input to the Tx, and the output of
the Rx S element be isolated with a unit gain amplifier (E element) as in
the following example of a Tx Tstonefile wrapped in an ISS subckt:

a.  .subckt Intrinsic_Tstonefile_Tx DieP PadP DieN PadN file='NA'

b.  * Port order of Touchstone file is DieP PadP DieN PadN

c.  E_H EDieP 0 VCVS DieP 0 1.

d.  E_L EdieM 0 VCVS DieN 0 1.

e.  S1 EDieP PadP EDieN PadN 0 mname=A 

f.  .model A TSTONEFILE=file 

g.  .ends Intrinsic_Tstonefile_Tx

3.       There are now three proposals to implement Tstonefile in .ibs
and/or .ami files.

a.       BIRD 120 proposes the following example, where  (Voh-Vol) = Peak
to Peak voltage swing:

 
i.      (Tstonefile (List "xwc.s4p" "wc.s4p" "nc.s4p" "bc.s4p" "xwc.s4p") 

 
ii.      (Usage Info) (Type String) 

 
iii.      (Description "Extreme Worst, Worst, Nominal, Best, Extreme
Best"))

 
iv.      (Vol  (Value 0.) (Usage Info)(Type Float))

 
v.      (Voh (Range 1 .3 1.2) (Usage Info)(Type Float))

b.      There are a number of BIRDs submitted by Arpad and Ambrish. I have
requested that the above example be implemented using the syntax proposed
in these alternative BIRDs.

 

Walter

 

 

Walter Katz

wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 720.333-1107

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2011