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

David,

 

The point that Ken was making is that an EDA tool can convolve the impulse
response output of Rx Init to a stimulus input (same as what would be
input to Tx GetWave) to generate a waveform that is equivalent to what
would come out of Rx GetWave. The processing of this waveform is identical
to the processing of an Rx GetWave output (waveform with no clock_times).

 

Walter

 

From: David Banas [mailto:DBanas@xxxxxxxxxx] 
Sent: Friday, December 09, 2011 1:11 PM
To: 'wkatz@xxxxxxxxxx'; 'Ken Willis';
'vladimir_dmitriev-zdorov@xxxxxxxxxx'; 'fangyi_rao@xxxxxxxxxxx';
'ibis-macro@xxxxxxxxxxxxx'
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

Hi Walter,

 

I disagree. I don't believe the two are necessarily equivalent, since Init
is confined to return only an impulse response, while GetWave is free to
return an actual result vector, which can include some non-linear effects
that can't be included in the impulse response returned by Init.

 

-db

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Friday, December 09, 2011 9:10 AM
To: 'Ken Willis'; vladimir_dmitriev-zdorov@xxxxxxxxxx;
fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile Issues

 

Ken,

 

You are correct. Time domain using Init only is equivalent to GetWave with
no clock_times returned.

 

Walter

 

From: Ken Willis [mailto:kwillis@xxxxxxxxxxx] 
Sent: Friday, December 09, 2011 11:40 AM
To: vladimir_dmitriev-zdorov@xxxxxxxxxx; 'Walter Katz';
fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

Hi Vladimir,

 

I think we need to be careful on your item #2:

 

Our convention is that 'statistical' analysis means simulation without
GetWave calls, while time domain simulation is a relatively long analysis
with multiple GetWave calls.

 

There is no reason why you can't perform time domain simulation where both
Tx and Rx AMI models are init-based, and don't use GetWave, correct? In
that case the user has a choice to do either statistical analysis or time
domain simulation. We shouldn't make the general association that AMI_Init
= statistical and AMI_GetWave = time domain.

 

Thanks,

 

Ken Willis

Sigrity, Inc.

860-871-7070

kwillis@xxxxxxxxxxx

 

  _____  

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov,
Vladimir
Sent: Tuesday, December 06, 2011 5:20 PM
To: Walter Katz; fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile Issues

 

Walter,

 

OK, that's sounds correct.

 

Vladimir

 

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Tuesday, December 06, 2011 3:14 PM
To: Dmitriev-Zdorov, Vladimir; fangyi_rao@xxxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

Vladimir,

 

I generally agree with your points 1 and 2.

 

3.2 is incorrect:

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

I believe I said that in statistical Rx_Clock_PDF, Rx_Clock_Recovery_Rj,
Rx_Clock_Recovery_DCD, Rx_Clock_Recovery_Sj, Rx_Rj, Rx_Sj and Rx_DCD are
applied.

 

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

 

Walter

 

From: Dmitriev-Zdorov, Vladimir
[mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx] 
Sent: Tuesday, December 06, 2011 5:08 PM
To: wkatz@xxxxxxxxxx; fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile
Issues

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
<mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d>  On Behalf Of Walter
Katz
Sent: Thursday, December 01, 2011 8:05 PM
To: fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: Jitter BIRD issues, and Buffer Tstonefile Issues

 

Fangyi,

 

 

Walter,

 

I generally support your jitter proposal. We maybe we should add some
explanations to the usage of these parameters.

 

1.       Possible redundancy was mentioned today, because practically the
effect from Rx clock jitter and Rx CDR jitter could be summed up by EDA
tool or Rx model and represented in either Rx or Clock Recovery groups, or
even produced by the output clocks from GW model. I agree however that it
makes sense to list these parameters separately, to simplify their
handling and understanding by user. It is not difficult for EDA tool to
collect the effects from different jitter parameters together if needed.

2.        We need to avoid possible confusion when using the words
'statistical' and 'time domain' methods. Our convention is that
'statistical' analysis means simulation without GetWave calls, while time
domain simulation is a relatively long analysis with multiple GetWave
calls. With respect to Rx_XX and Rx_Clock_Recovery_XX groups, there is an
additional choice for EDA platform in time domain flow, to apply either
straightforward time domain implementation of such jitter, for example, by
calling the rand() functions, once every bit, or by accounting for the
same amount of jitter statistically, on the post processing stage (after
time domain simulation is completed). The choice should be up to EDA tool,
since both approaches have their advantages and limitations. In other
words, in statistical flow, all jitter parameters are applied
statistically, but in time domain flow, some could be applied in time
domain and some statistically (if possible).

3.       It's not quite clear for me the following from your previous
email:

 

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

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

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

 

We understand Rx_Clock_Recovery_XX parameters are substitute for clock
ticks that we can use either in statistical flow or in time domain when
clocks are not returned. It seems logical to have Rx_XX type parameters
for statistical flow, too, since they correspond to a different source of
jitter. This is what the existing spec says. What is a motivation for this
change?

Vladimir

 

 

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
<mailto:%5bmailto:ibis-macro-bounce@xxxxxxxxxxxxx%5d>  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

 

 

  _____  

Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If
you have received this message in error, please advise the sender by reply
e-mail, and delete the message and any attachments. Thank you.

Other related posts: