[ibis-macro] Re: Absence of clock times
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <scott@xxxxxxxxxxxxx>, <Arpad_Muranyi@xxxxxxxxxx>
- Date: Fri, 1 Apr 2011 19:17:03 -0400 (EDT)
Scott,
You are very seriously misrepresenting the "prime directive". It says that
when an AMI model is given as input the same impulse response, AMI model
conditions (i.e. AMI_parameters_out), and the same input stimulus, that
the output of that AMI model will be the same on all EDA platforms. So in
the case of an Rx AMI_GetWave that does not return clock_times, the same
AMI model must not return clock_times in all EDA tool, and on all hardware
platforms and operating systems.
The "prime directive" also explicitly says that each EDA platform may
choose the inputs and analyzes the outputs differently.
The Fundamental Principle of
AMI Modeling
The fundamental principle of AMI modeling is that every EDA
platform (both software and hardware) will give the same results
when presented with the same Analog-Channel impulse response,
the same AMI model conditions, and the same input stimulus
pattern.
Each EDA platform may differ on how it chooses the inputs to the
AMI model: Tx and Rx AMI model conditions, stimulus pattern, and
the Analog-Channel impulse response. Each EDA platform may
differ on how it processes the resulting outputs.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Friday, April 01, 2011 4:21 PM
To: Arpad_Muranyi@xxxxxxxxxx
Cc: IBIS-ATM
Subject: [ibis-macro] Re: Absence of clock times
Arpad
In short ... yes.
Clock input to a Tx or Rx model is currently undefined. This needs to
change, otherwise the IBIS-AMI prime directive (all EDA tools create
identical results with the same model) cannot be achieved.
Scott McMorrow
President
Teraspeed Consulting Group LLC
(401) 284-1827
On Mar 31, 2011 2:20 PM, "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
wrote:
> 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:
