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

  • From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
  • To: Ken Willis <kwillis@xxxxxxxxxxx>, 'Walter Katz' <wkatz@xxxxxxxxxx>, "fangyi_rao@xxxxxxxxxxx" <fangyi_rao@xxxxxxxxxxx>, "ibis-macro@xxxxxxxxxxxxx" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 12 Dec 2011 21:42:02 +0000

Hi Ken,

Sorry, I overlooked this email. Yes, of course, with INIT only, we can perform 
time domain analysis, too.
I was only saying that the word 'statistical' can be applied to the analysis 
mode (time domain or statistical), or to the way we account for jitter in time 
domain simulation (by including it directly into stimulus waveform, or later on 
post processing stage). That's why we may want to make the spec's wording more 
clear about the jitter and how it can be applied by EDA tool. I think that EDA 
tool must be able/allowed to choose how to apply jitter.

Vladimir

From: Ken Willis [mailto:kwillis@xxxxxxxxxxx]
Sent: Friday, December 09, 2011 9:40 AM
To: Dmitriev-Zdorov, Vladimir; '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<mailto: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: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<mailto:fangyi_rao@xxxxxxxxxxx>; 
ibis-macro@xxxxxxxxxxxxx<mailto: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: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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 720.333-1107

Other related posts:

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