[ibis-macro] Re: feedback on jitter BIRD 123
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'Scott McMorrow'" <scott@xxxxxxxxxxxxx>
- Date: Thu, 14 Apr 2011 16:09:29 -0400 (EDT)
Scott,
What I meant by the Rx have a "system clock", whas that the Rx CDR uses
reference clock from some clock on the Rx.
The following note in the current BIRD describes the usage of Rx jitter
parameters that eliminate double counting:
Note:
The "Clock Jitter Parameters" (Rx_Clock_PDF, Rx_Clock_Recovery_Mean,
Rx_Clock_Recovery_Rj, Rx_Clock_Recovery_Sj, Rx_Clock_Recovery_DCD , should
be used by the simulator when analyzing the output of Rx AMI_Init or Rx
AMI_GetWave when Rx AMI_GetWave does not return clock_times. When Rx
AMI_GetWave returns clock_times, the simulator should not use the "Clock
Jitter Parameters". An Rx AMI_GetWave function should return clock_times,
unless it is a Repeater, in which case the AMI_GetWave function may or may
not return clock_times.
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Thursday, April 14, 2011 4:06 PM
To: wkatz@xxxxxxxxxx
Cc: kwillis@xxxxxxxxxxx; 'IBIS-ATM'
Subject: Re: [ibis-macro] Re: feedback on jitter BIRD 123
- Rx_Clock_Recovery_Rj > Don't understand why we can't simply use
your "Rx_Rj" for this instead of creating a new parameter. Would like to
see this parameter dropped.
WMK Again you do not understand that an Rx contains two clock, a reference
clock that drives the CDR and the CDR itself, both have jitter
Walter, please be specific on how Rx_Rj, and Rx_Clock_Recovery_Rj are to
be applied by the Model and EDA tool in a statistical and a GetWave flow.
Otherwise there is the potential for double counting.
Scott McMorrow
Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
(401) 284-1827 Business
(401) 284-1840 Fax
http://www.teraspeed.com
TeraspeedR is the registered service mark of
Teraspeed Consulting Group LLC
On 4/14/2011 3:45 PM, Walter Katz wrote:
Ken,
Comments below.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Thursday, April 14, 2011 3:20 PM
To: 'Walter Katz'
Cc: 'IBIS-ATM'
Subject: [ibis-macro] feedback on jitter BIRD 123
Hi Walter,
Apologies for the late feedback on your jitter BIRD. This is important
work and we support your efforts there. We have some feedback that I noted
during our internal review. I am including some feedback on the
pre-existing IBIS 5.0 jitter-related items as well, so we have the whole
"jitter" picture together:
Tx_Jitter > I believe you already mentioned that this was to be
deprecated, which we agree with. We would like to see this explicitly
mentioned someplace (although I admit I am not sure where - Bob Ross
please advise?).
WMK Separate BIRD on how to hand Tx_Jitter.
Tx_Sj and Tx_Sj_frequency > These go together. It would be more convenient
if this could just be defined in a single parameter instead of in 2.
WMK No
Rx_Receiver_Sensitivity > This defines requirements for the eye height. We
would like the requirements for the eye width to also be included in this
reserved parameter.
WMK Separate BIRD
Rx_Sj > This appears to be more general than just sinusoidal phase noise.
Recommend that it be re-named "Rx_Dj" (deterministic jitter) for clarity.
WMK Dj stands for Deterministic Jitter (i.e. pattern dependent). The EDA
tool needs to deal with Dj
Rx_DCD > We think this effect should simply be returned with the clock
ticks from Rx's AMI_GetWave. We would like to see this parameter dropped.
WMK Rx_DCD describe the DCD in the system clock not the clock recovery
loop
Rx_External_Reference_Clock > This is an important one, but is bigger and
has more implications than to just be tacked on in this jitter BIRD. We
request that this one be broken out into its own separate BIRD for
discussion.
WMK No
Rx_Clock_PDF > This is a pre-exisiting one. I believe the intent was to
deprecate this one as well. Is that correct? We would support than, in
light of all the other jitter-related parameters being brought in. Again,
not sure where to express this in the spec.
WMK Separate BIRD
Rx_Clock_Recovery_Sj > Don't understand why we can't simply use your
"Rx_Sj" for this instead of creating a new parameter. Would like to see
this parameter dropped.
Rx_Clock_Recovery_DCD > Following up from the feedback above on "Rx_Sj",
we are thinking this could be sufficiently covered with the more generic
"Rx_Dj" parameter. Would like to see this parameter dropped.
Rx_Noise_Pad > We have multiple questions on this one. Is this to be
applied directly to the impulse response? Where is this value supposed to
come from? What is its purpose? Not sure about the value of having this
parameter. I realize there is ongoing discussion on this one.
WMK It is being removed to a separate BIRD.
A couple of other editorial things that came up:
Why do we need the following statement at all? Model makers can put
whatever they want in the Model_Specific parameter section. This could all
be deleted:
Note that all of the parameters defined in this BIRD may be declared in
the Model_Specific section of the .ami file to allow the use of some
legacy models .
WMK Removed
In the Rx_Sj example, it seems like "0.4" should be changed to "0.04",
Typo?
WM Typo, changed to .04
There are flow implications when these parameters are "Usage Out" that
still need discussion, will not get into that yet.
Ran across a typo in IBIS 5.0 that should be cleaned up while we are
making changes to this section, where "Rx_Clock_PDF" should be
"Rx_Receiver_Sensitivity":
WMK Separate BIRD
| signal is sampled correctly. Examples of Rx_Clock_PDF
| declarations are:
|
| (Rx_Receiver_Sensitivity (Usage Info)(Type Float)
| (Format Value <value>))
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
Other related posts:
