[ibis-macro] Absence of clock times
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 31 Mar 2011 11:19:49 -0700
Hello SERDES experts,
I have been wrestling with this question for some time,
but now that it was mentioned in the thread below, I
would like to ask the question openly.
"There are Rx models with no GetWave, and a number of Rx GetWave models
that do not return clock times."
BIRD 112 only says what should be done when we have
clock times:
|* Each valid value in the clock_times vector shall be used to sample
the
|* output waveform by adding to it bit_time/2
but it doesn't say what should be done when there are no
clock times. Considering that building an eye and a BER
plot hinges on the sampling point and the results can be
completely different (or invalid) depending on where that
sampling point is, I wonder whether we should make some
provisions in the specification for the case when clock
times are not returned by the Rx model. With the current
information in the spec tools can only guess which is not
always the best approach...
In addition, there are other clocking schemes out there,
such as Forwarded Clock (QPI, etc...) and Common Clock (PCIe,
etc...) and these technologies may also benefit from using
algorithmic models. I wonder if we need to revisit this
aspect of our specification to fix the missing clock ticks
problem, and include externally generated clock ticks?
Thanks,
Arpad
=============================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Wednesday, March 30, 2011 4:49 PM
To: kwillis@xxxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: [IBIS] BIRD123.1: IBIS-AMI New Reserved
Parameters for Jitter/Noise
Ken,
Comments inserted below.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Ken Willis
Sent: Wednesday, March 30, 2011 3:35 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: [IBIS] BIRD123.1: IBIS-AMI New Reserved
Parameters for Jitter/Noise
Hi,
This BIRD has a number of unresolved questions and clarifications that
need to be made before it is ready for a vote in the Open Forum. Each of
these jitter parameters needs to be clearly spelled out as to its
meaning and implementation in order for EDA vendors to consistently
handle these parameters to the expectations of the AMI model developers.
Some of the initial questions we have:
- There was already a parameter Tx_Jitter in the IBIS 5.0 spec. Is
this superceded by all the Tx-related jitter sub-components spelled out
in this BIRD? Or is it intended to still be used?
<WMK> As I stated when I reviewed BIRD 123 in the IBIS-ATM meeting, I
recommended that all uses of Tx_Jitter and Rx_Clock_PDF should be
deprecated except Table, which would be used to represent Bounded
Uncorrelated Jitter (BUJ).
- There is a whole question of Usage with these parameters. If the
EDA tool is expected to do some well-defined thing with the parameters,
we should probably introduce a new Usage type like (Usage Tool) so that
it is unambiguous as to what is the intent for that parameter.
<WMK> The definition of Info is that it be used by the tool, why do we
need a new Usage.
- Each of these items needs to be spelled out in detail as to what
is to be done with the various parameters. Incorporate into the bit
stream? Add jitter post-simulation in some manner? Post-process
statistically into bathtubs? Needs to be defined for each.
<WMK> This is a decision for the EDA Tool. Fangyi gave a wonderful
presentation at DesignCon 2010 on how Jitter can be rigorously
incorporated into statistical analysis, although the implementation was
proprietary.
- There is a Tx_Sj parameter with a companion Tx_Sj_Frequency
parameter. But there is also an Rx_Sj that does not have a
Rx_Sj_Frequency counterpart. Was this intentional?
<WMK> Yes.
- Can there be multiple Sj's, or can you only have a single one?
<WMK> One Sj.
- Does it even make sense to have all the Rx_ jitter parameters,
if they are all just ignored anyway if an Rx model with AMI_GetWave
returns clock ticks? Don't we expect Rx models that emulate real device
behavior to have their own clock recovery algorithms as part of the
model?
<WMK> There are Rx models with no GetWave, and a number of Rx GetWave
models that do not return clock times.
Our recommendation is treat this BIRD as a starting point, and bring it
back into the IBIS-ATM committee for clarification. There is still work
to be done here.
<WMK> We do not treat this BIRD as a starting point, but I have no
objection to bringing this back to the IBIS-ATM committee.
Thanks,
Ken Willis
Sigrity, Inc.
860-871-7070
kwillis@xxxxxxxxxxx
Other related posts:
