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