[ibis-macro] Re: Absence of clock times
- From: "Morrison, Casey" <cmorrison@xxxxxx>
- To: "wkatz@xxxxxxxxxx" <wkatz@xxxxxxxxxx>, "scott@xxxxxxxxxxxxx" <scott@xxxxxxxxxxxxx>
- Date: Fri, 1 Apr 2011 23:49:52 -0500
Perhaps Scott is referring to reference clocks (with their inherent jitter,
spectrum spreading, frequency offsets, etc.) rather than recovered clocks (i.e.
clock_ticks).
Casey
-----------------------
Casey T. Morrison
Texas Instruments, Inc.
Desk: 214-567-4250
Email: cmorrison@xxxxxx
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Walter Katz
Sent: Friday, April 01, 2011 9:27 PM
To: scott@xxxxxxxxxxxxx
Cc: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: Absence of clock times
Scott,
From the IBIS 5.0 Rx_Clock_PDF, or the other Opal(tm) Clock Recovery Parameters
that were added to properly account for actual Jitter Transfer Functions for
statistical analysis, or the EDA tool might choose to implement its own clock
recovery circuit and generate its own clock_times.
We do what we need to do to get the job done for our customers, and we will
continue to do so.
I do not think this is a big deal, there are not that many Rx GetWave models
out there that do not output clock_times, so if we want to require that Rx
AMI_GetWave return clock_times it is fine with me.
Regarding your comment that "The entire concept of clocks in AMI_GetWave models
seems to be currently problematic." Seems to fly in the face with the large
number of AMI models being used to design real world systems, and correlating
extremely well will measured BER, Jitter Transfer Functions, Crosstalk, and
other channel metrics.
Walter
From: Scott McMorrow [mailto:scott@xxxxxxxxxxxxx]
Sent: Friday, April 01, 2011 7:32 PM
To: Walter Katz
Cc: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: Re: [ibis-macro] Re: Absence of clock times
Walter
Respectfully, I am not. Where exactly is the external clock inserted in an AMI
receiver model? The entire concept of clocks in AMI_GetWave models seems to be
currently problematic.
Scott
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
Teraspeed(r) is the registered service mark of
Teraspeed Consulting Group LLC
On 4/1/2011 7:17 PM, Walter Katz wrote:
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Friday, April 01, 2011 4:21 PM
To: Arpad_Muranyi@xxxxxxxxxx<mailto: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<mailto: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>
> [mailto: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<mailto: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>
> [mailto: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<mailto:kwillis@xxxxxxxxxxx>
>
>
>
Other related posts:
