Hi Arpad, Yes, this exists in the current spec, but we feel this was ill-advised and should be re-considered when we work on the 5.0 clean-up effort. This is just Sigrity's opinion of course, but in a nutshell we think it should work like this: (a) If a particular filtering capability can be accurately represented with Init_Returns_Impulse, then that should be the end of it. You don't need GetWave in this case. (b) If the filtering has some kind of advanced signal processing and complex algorithms that require GetWave, then the model should use GetWave. That is what it is for. If it doesn't require this added complexity and effort, see (a). So having both in the same model doesn't seem necessary. And cases where multiple answers can be derived from the same model seems problematic for both model and tool developers, and we think it will add confusion in the user base. There is some historical precedent where users are accustomed to using transistor-level Spice IO models for some applications, and behavioral IBIS IO models for others. Both are useful, but users are very well aware of which one they are using for what, and why they are doing so. We see no need to change the existing historical mindset specifically for serial links. Init_Returns_Filter clouds this picture even further (more different answers from the same model), which is why we asked that it be put into its own BIRD to be discussed separately. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, March 31, 2010 1:35 AM To: IBIS-ATM Subject: [ibis-macro] Comment on Sigrity's presentation Ken, I would like to make a comment on slide 3 of the presentation you gave us in the ATM teleconference a week ago and the discussion that followed. http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20100323/kenwillis/S igrity%20AMI%20BIRD%20Feedback/Sigrity_AMI_BIRD_fback.pdf If I understood the discussion correctly, you and Kumar are concerned that one model could produce different results when only its Init functions are used vs. when its GetWave functions are also used. The discussion between you and Todd ended in a disagreement. However, it just occurred to me that the AMI portion of the IBIS 5.0 specification already talks about the possibility of having two types of analysis paths, one that only uses the Init functions (for LTI systems), and another that also involves the GetWave function when non-LTI effects are present. This is found in Section 10, 2.1 and 2.2 in the specification. Doesn't this close the discussion we had in the meeting when you were presenting in a sense that you are challenging an intent that is already clearly spelled out in the specification? Thanks, Arpad ================================================================= --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe --------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe